I know this is outrageous nitpicking, but there's a possible comment inaccuracy in ac.scm, in (define (ac s env) ...
; the next two clauses could be removed without changing semantics
((eq? (xcar (xcar s)) 'compose) (ac (decompose (cdar s) (cdr s)) env))
((eq? (xcar (xcar s)) 'complement)
(ac (list 'no (cons (cadar s) (cdr s))) env))
Expanding fn-position compose and complement in ac enable composition of macros. (rev:accum a (a 1) (a 2)) works for example although accum is a macro. I tried removing the removable clauses from ac, and indeed the rev:accum example no longer works.
Er, note that I said stable and official branches, not to the master branch. The master branch is what most people using anarki use. The official branch just tracks pg's released arc tarballs. The stable branch incorporates bugfixes and some simple additions (the arc.sh script). (If you knew all this already, and were just asking whether merging with the stable branch worked, yeah, it should just work.)
Switching over the entire master branch is essentially impossible, as has been discussed before... although there aren't many incompatible changed between arc2 and arc3, there are enough, and moreover, there are enough differences between arc2 and anarki that integrating the changes to arc3 wholesale into anarki is difficult. Anarki simply has so much in it - bugfixes, hacks, additions, libraries, pet projects, and even reimplementations.
The solution to this is for people to port the parts they care about separately. That way, the best parts of anarki will get ported and the cruft that no-one is maintaining will be expunged. I'm working on the help/documentation subsysem at the moment, and after that, the ability to define call behavior for tagged objects, and the many extra functions and macros anarki adds. I'll probably be making a post sometime soon about what I see as the way to move forward, but for now, anarki's master branch is unchanged.
Hmm. Have you started a new branch that is the official target, so that we're all working together instead of separately as we port our favorite things over?
I wouldn't mind helping you with the help/documentation stuff as I wrote some of it (src and the current version of fns), and it's probably my favorite part as well. Right now I'm a bit busy working on a new and improved ppr so that the src function actually returns reasonable looking source code ;)
I have been thinking about a new way to do the source code storage for src. I noticed that every time scheme makes a lambda, it remembers where in the code it was created. That means that the information about where the source is is associated with the lambda object, not the name. What if we modified the way that ac-fn worked, so that it associated each fn with its source code? That way all procedures, macros included, would have their source code available for inspection.
That's the idea, the hard part is making it work, and making it work without leaving the old definitions behind when the lambda no longer exists (temporary code, etc.) Any ideas? Maybe we could use vectors like the tag system? That would make it easy to look them up in a table, but doesn't fix the problem of garbage collection. Also, hacking it on at such a low level means that it probably captures the state of the source code after all of the macro expansions, so it may not be such a good idea after all.
the hard part is making it work, and making it work without leaving the old definitions behind when the lambda no longer exists
I don't know about the first part, but for the second, what you want is a weak hash table (http://download.plt-scheme.org/doc/372/html/mzscheme/mzschem...) with the lambda's stored as the keys. The weak hash table holds the keys "weakly", which means it doesn't prevent the keys (the lambda's) from being garbage collected, and when they are garbage collected, the related value is dropped from the table.
