Another update: I contacted Allan Odgaard to ask about putting in a feature that would allow folding to work nicely. There probably won't be a fix. The workaround that I'm using is this:
(def foo (...)
...))
); unusual - last closing parens of a block on next line
I looked into this some more, and it looks like this is a difference between arc and scheme. I just wanted to put this out there for anyone else looking at Scheme materials through an Arc lens.
For completeness (and in case someone can spot my mistake!) here's the broken Y Combinator version:
(def Y2 (m) ((fn (f) (m (fn (a result) (f f) a result)))
(fn (f) (m (fn (a result) (f f) a result)))))
; broken
(def accumulate (combiner null-value term a next b)
((Y2 (fn (r)
(fn (a result)
(if (> a b) result
(r (next a) (combiner (term a) result))))))
a
null-value))
As a principle to consider, how about: "Any change to anarki should not break any program which runs correctly on the latest arcn, if the program does not exploit bugs in arcn."
I'm not so sure about this. I think changes of the filling-up-namespace sort are reasonable, for the same reason being a Lisp-1 is reasonable: conflicts happen rarely in practice.
A better solution would be to try to ensure that only generally useful macros are added to arc.arc, and that they have names that are unlikely to be used as local variables. Or even better would be to make local variables shadow macros.
Consider this, though: "help" is defined as a macro. Some of the REPL-var code needs macros. The drop-into-scheme operator is a macro. I don't think we want to make people load a library file to use these.
I see the compatibility rule as more of a guideline - try not to break the functionality of stuff that already exists. But I don't think it should limit experimentation and exploration, including exploration of what's useful to have in arc.arc.
OK, I'll backpedal a bit here. The last thing I want is to have to require "lib/help.arc" :). It should be easy to find out what macros have been added though -- as much for curiosity as for compatibility. I'll try and whip up a script tonight, unless someone beats me to it.
Ok. The public_html change I made to srv last week will break anyone expecting to serve files out of the root directory (as they would with arc1). Should I revert this change? Then plead PG to pick it up with arc2...
Actually I could default the docroot to "" instead of "arc/public_html". I think it's ugly but if we want to be compatible with arc1 then this would do it.
I put a note in the subversion repository to this effect --- unless there are any complaints, I'm going to take the code out of the SVN repository and leave only a note. There's no point in spending any time merging back and forth.
For now, anyone who is interested in Arc is smart enough to figure out git.