My bad. In my haste, I simply ssh'd to my Mac and issued 'date -u -r' and didn't take the time to see that it was simply complaining about the fact that I didn't provide an argument for -r. So, I guess it's a problem for Linux, and not for OSX.
In this example it's not the end of the world, but it would cause problems in code that's generated by other code, e.g. by macros.
I experimented for a while with having if just be aif, and it was not good. There are times you want to back off from maximally using anaphoric variants, just as there are times you don't want to use [] or ./! notation even though you could. E.g. when it's nested. And if you don't have the non-anaphoric variants, you never can.
It doesn't seem a good idea to use characters that have special syntactic meaning in the names of things. You can't name a function foo(bar either, but that doesn't seem odd because Lisp hackers are used to ( being different from other characters.
It seems too that special end-of-symbol handling in the core, just because some users might possibly want to use intrasymbol-notation characters at the end of function names, does not go well with Arc's design philosophy:
... avoid having a language designed according to arbitrary rules rather than the actual demands of the task ...
This is potentially an issue if you open up intrasymbol syntax though. It'd be pathologically dumb, but what happens if I set up - to be an intrasymbol macro?
Solution: perhaps user defined intrasymbol macros should be surrounded by colons (:-:) by convention? Do intrasymbol macros support multiple characters?
Off the top of my head, another big one is that Arc has a more library functions. Individual Scheme implementations tend to, but the Scheme standard is pretty small.
Not anymore with R6RS---it has over 650 functions. Besides, I tend to think SRFIs as a part of 'modern' Scheme, as some of them are quite essential for day-to-day programming. (Although the popularity varies a lot---cf. http://practical-scheme.net/wiliki/schemexref.cgi?SRFI )
The '(frst . rest)' signals an error before compilation reaches the ,@.
The problem is, I think, that ac-qq1 doesn't expect to encounter an improper list. So, with arc1 you can't use a dot in a quasiquote to denote an improper list.
However, as vsingh pointed out, an unescaped cons operation will get you an improper list in a quasiquote where a dot doesn't.
This seems like a bug indeed, and it is easy to fix, simply replace this in ac-qq1:
((pair? x)
(map (lambda (x) (ac-qq1 level x env)) x)))
