Well, it has to do with the ssyntaxes.arc precedence rules and how they work: basically, split according to the current ssyntax, then go to next ssyntax. Since #\. is listed before #\!, symbols are first split by #\. into (foo! x), so it works properly.
It won't work with a type that ends in ! and if you use the ? ssyntax:
(def my-type! (x)
(annotate 'my-type! x))
(my-type!? my-type!.1) ; will transform to (my-type '?)
I think it's just because many people are used to having the arguments declared separately from the name, since most other languages (including non-Lisps) do that as well.
remember also that Arc autodestructurizes arguments based on the parameter list (example: http://arclanguage.org/item?id=6125.) scheme-style def would would conceptually interfere with that
though maybe scheme autodestructurizes like that also? i don't know
so that args is the list of all arguments, and rest is the list of all arguments after the first two. I suppose the equivalent scheme-ish way would be
(def (foo . args) ...
(def (foo x y . args) ...
I like the fact that arc has no special &rest keyword, that rest args just fall out of the way lists are constructed.
I haven't used scheme so I'm not qualified to comment (but obviously that's not stopping me), but to this n00b it makes sense that the parameter list is distinct from the function name. And as you mention it makes named functions look more similar to anonymous functions. So I have less thinking to do when I'm looking at a parameter list.
This is what I originally had in mind. As far as I can tell, this doesn't work for bytecode-compiled Lisp, correct? (Since it would compile it as a function call, although it's a macro...) So does that mean every implementation of Lisp has to have a single-pass interpreter in it?
Well, every implementation of Lisp does indeed contain an interpreter: eval!
But the way Lisp compilers deal with recursive macros is to not allow them. From the Common Lisp spec:
"All macro and symbol macro calls appearing in the source code being compiled are expanded at compile time in such a way that they will not be expanded again at run time."
That rules out recursive macros. I think they're allowed when Lisp is being interpreted, but you should probably just not use them.
Question:
Could this, perhaps, be solved by making the variable and function namespaces the same?
(I'm probably misusing terminology here, but what I mean is that you can't have a function and a variable named the same yet still stand for different things when used in code)
actually, arc does use the same namespace, that is most of the cause of this problem. if they were in different namespaces, there would be no problem with variables shadowing built-in functions. you still have to worry about variable capture, but it's a much less significant problem.
note: i'm not saying i don't like the same namespace thing. it actually shortens a great deal of code, and eliminates CL's stupid ass #' garbage.
