Interesting. An arc rebuild that's faster and cleaner while maintaining most compatibility certainly sounds attractive. I'll have to try it out at least a bit.
A slightly unrelated question: Have you ever tried compiling a standalone binary for Nu or anarki, at least for the compiler? I'm pretty sure racket can do that, but I don't think I've heard of anyone doing it.
As for fexprs, I think something can probably be done even in arc to some extent, using a copy of the original code and dynamic recompilation with memoization for speed. It would have the advantage of also enabling the self-documentation features that I added to anarki too, though it might be a bit slow.
"Have you ever tried compiling a standalone binary for Nu or anarki, at least for the compiler? I'm pretty sure racket can do that, but I don't think I've heard of anyone doing it."
No, I haven't, though I suppose it could be done... I don't see much point to it, though. I mean, I guess if you're on Windows, but...
---
"As for fexprs, I think something can probably be done even in arc to some extent, using a copy of the original code and dynamic recompilation with memoization for speed. It would have the advantage of also enabling the self-documentation features that I added to anarki too, though it might be a bit slow."
I've experimented with using fexprs in a compiled environment like Racket, but you really really do want things to be interpreted. At the very least, using fexprs won't blend well with Arc code, because the entire Arc language has been designed around macros, to the point where adding in fexprs just makes things more clunky. If you want fexprs, I'd recommend a language that was designed from the start for fexprs, like Kernel, PicoLisp, or newLISP.
Well, one of the reasons I was interested in compiling at least the standard arc library was for improving startup speed, say for use as a simple cgi script on a shared host, or a basic command line utility. It also might reduce distribution size, instead of making users install all of racket and the arc source, which can be somewhat bothersome.
I suppose its possible that trying to add fexprs to arc would just make things worse, but I was always attracted to the idea of making environments and scope easier to manipulate, and macros fit in better. As it currently is, macros are very separate from the rest of the language and stick out a little bit. I've rarely had a really good reason to need it, but it just bothers me sometimes that they aren't first class citizens.
"Well, one of the reasons I was interested in compiling at least the standard arc library was for improving startup speed, say for use as a simple cgi script on a shared host, or a basic command line utility."
Oh! That's what you're talking about! Sure, I've experimented with that too. I think it's possible, but it would require mucking about with Racket's code loader... still, that's not a bad idea.
---
"I suppose its possible that trying to add fexprs to arc would just make things worse, but I was always attracted to the idea of making environments and scope easier to manipulate, and macros fit in better. As it currently is, macros are very separate from the rest of the language and stick out a little bit. I've rarely had a really good reason to need it, but it just bothers me sometimes that they aren't first class citizens."
Absolutely. I too like the idea of fexprs. I'm just saying that from a purely practical perspective, Arc was not designed around fexprs, so tacking them on after the fact won't work so well. It shouldn't be hard to make a variant of Arc that is built around fexprs. In fact, wart is very Arc-like but has fexprs (or something that's like fexprs anyways).
