wow, good catch. Pretty sure it's not on purpose though. That syntax defies everything that dot notation means. Consider it supported for the same reason Arc has UTF-8 at the minute.
I like the idea of number two, but I'm not sure how useful it would be in arc where the language seldom requires X amount of arguments; for example:
(< a)
works just fine and wouldn't be curried. So in order to make currying useful, we'd have to re-write a good chunk of arc code to make some of the optional arguments required.
However, the core arc library commands, by their nature, are very general and hence have few mandatory parameters. However, most functions for any actual application will be far more specific and hence, I believe, will tend to be loaded with mandatory parameters. This is the use for case which function currying would be very valuable.
I'm not sure if I quite understand you, "(A C)" In your Arc code suggests A is a function. Going by your first posted code, you can achieve this in Arc with:
good point, I should have thought that one through. Perhaps we should consider changing the return value of ">" so I'm correct? :P
It seems more useful to have the return value be the greater number if it is true, and since all non-nil values are true, it wont break any existing code. For a > b, consider the following:
Makes sense to me. It's a trivial change in ac.scm for < and >. What about (<= 1 2 3) and (>= 3 2 1)? The easiest way to do the same for those two is to return the last value compared, which would be 3 and 1 respectively. That doesn't exactly jibe with < and > though so I hesitate to make such a change. Thoughts?
It seems logical that <= and >= should also return some meaningful value if < and > do. If we come up with something good I'll push it to the anarki repo (git wiki). Although, we could always just ignore <= and >= for now.
I should have been clearer. I agree the semantics should be the same, I just didn't see an immediately clean way to add that to the current, recursive <= and >= functions. A thin wrapper would work just fine.
Got it.. thanks for introducing me to anaphoric macros :). Now the question is whether writing macros and having several aifs aands awhile aif2s for it is the way to go, or whether it is something that might be core-worthy, in a way that gosub (see post below) suggested.
Excellent, could we get some sort of separate forum to talk about this project though to discuss bugs, recent patches, etc.. I noticed you have a module system up now, but I can't get it to work:
arc> (impas blah spec)
#3(tagged mac #<procedure>)
arc> (blah:do2 nil nil nil)
Error: "reference to undefined identifier: _blah"
And I'm not sure why it doesn't work, but I also have an Idea for a more general impas function:
The import.arc stuff is a sketch. One of it's many shortcomings is that if you define a function blah and then use it from inside the same module/file, it won't be able to find blah, because it's been silently renamed |modulename blah| .
The problem you're having seems to be different, though.
After looking, I realize that my testing process was masking a bug where I didn't change some symbol dereference. It's fixed now on my machine, but I'm new to git, and not sure what I need to do to make it show up in the repository. I did git push, but that doesn't seem to have made it appear in the commit list.
EDIT: okay, nex3 helpfully explained things to me, so this fix is in the arc-wiki repo now. It still doesn't change use points, though, as mentioned above.
Replying to myself because it seems as good a place as any...
We could walk the tree of a module and patch up any symbols we find that were referenced in a def or mac, but that's not a clean solution, since it can't find all actual calls (something could be building up names, for example, which we'd never find by walking the tree).
What this means is that any module system built right now, as far as I can tell, will have to require support from those writing the modules, but since renaming modules is implicit in how import.arc works at the moment, there's no way to know what the call should look like, for the module programmer. I can't see any way around this except to change Arc itself to make function and macro definitions respect lexical boundaries, rather than all being bound at the top level. Until that change is made, all we can do is fake a module system.
I was thinking that _ would be merely _0, ie _1 would be the second argument. But at this point that's not really the question, the question is how will the interpreter know how many arguments the function takes?
Maybe something like:
[[[+ _ _1 _2]]]
Could be shorthand for:
(fn (_ _1 _2) (+ _ _1 _2))
But, then, what if you want to use square bracket notation inside of that? For example, what if you want to create a two paramater function that creates a one paramater function?
(fn (x y) [+ x y _])
would be impossible. Unless you use currying or something on these special ones. Incidentally, a curry function:
EDIT: added some error-checking, changing a step from 0 to 1 probably isn't the right thing to do, but I didn't feel like figuring out how to throw an error.
(def range (default (o end) (o step 1))
(with (st (if end default 0)
en (if end end default))
(if (is step 0) (= step 1) (zap abs step))
(let (stp-fn test) (if (> st en) `(,- ,<) `(,+ ,>))
((afn (i accum)
(if (test i en) (rev accum)
(self (stp-fn i step) (push i accum))))
st nil))))
* Function or Macro (Split them up and alphabetize them)
* Alphabetical (all in one giant alphabetical list.)
* By file (arc.arc, app.arc, etc.)
You're already doing a combination of two of these, but you should give them as separate options; or perhaps keep what you have and just add all these options. Shouldn't be that hard if you keep all the definitions in a database, with the information required to do this.
