Although GitHub is really awesome, it's only free now because it's in beta... once they finish the site, it'll have a fee. On the other hand, they have talked about waiving that for open source stuff. Also, the beta is invite-only.
When I first set up a git repo, it was my own read-only one: http://git.nex-3.com/arc.git. Shortly before I announced it, though, ambition had set up the original Subversion version of the wiki. Since that seemed like a cool idea, I set up a parallel Git wiki.
Eventually, I just stopped pulling into my repo. The wiki pretty much had everything I wanted, and more or less nothing I didn't.
However, I could definitely see other folks creating their own repos if they want to do some major experimentation (although using a branch of the wiki might work just as well). In particular, I totally agree that it would be awesome if PG would expose his changes as Git commits, if just to make the arcn.tar merging process easier.
Well the real nice part would be PG himself using git and doing diffs against other repos to see what's festering in the community.
Right now the forum seems to be the only what of contributing patches to arc and this seems ripe for having things lost. (And who wants to bring up the same patch twice if it went unnoticed the first time).
Well, taking arcn.tar and merging it isn't that hard - I did it for arc1 and will probably continue to do so. It would just be nice if we could have more granular official patches.
From the copyright file in arc1.tar: "This software is copyright (c) Paul Graham and Robert Morris. Permission to use it is granted under the Perl Foundations's [sic] Artistic License 2.0."
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.
I understand your points, but I think there's one concern that sort of overrides them: it's very important for users to be able to have access to the documentation without any extra effort. They shouldn't need to load, or God forbid _find_, a documentation file before they can get help.
Now, you could say that we should have a default docfile and move the inline docstrings to that, but I think that in general when you are writing and maintaining documentation, it's much easier to have it right there.
I think adding support for alternative docfiles might be a good idea... geel free to do it in Anarki. But I don't think all documentation should be moved out to them.
I feel like if we have a canonical web repos for docstrings people will be able to find and use it. It works with Java's and Ruby's documentation. Most people probably don't care if the documentation is in the src or not. I don't know how to do it better than put it in the src though.
As the primary developer of Haml, I'm playing with the idea of porting it to Arc at some point (likely not via sexprs, though, because a large portion of Haml's coolness comes from other aspects of its terser syntax).
In fact, both were needed to optimize things. Mzscheme's doc says explicitly (though I can't remeber where exactly) that standalones are a little faster than interpreted code (there are a few more optimisations they can perform during compilation I guess). Running arc1.scm through mzscheme -f is a little slower.
There is an initial overhead for byte-compiling the code
and jitting it -- but that's not something that you'd be
able to measure for such a small piece of code. Once
that's done, it's the same code -- mzscheme (since a good
while ago) on intel and ppc does not interpret code. Ever.
Even on solaris, where the jit is disabled, it's
"interpreting" byte-compiled code, so it is not an
interpreter in any case.
