I've been itching for reasons to brag further about wart (http://arclanguage.org/item?id=12814) but sadly I have nothing useful to say here since it's built atop lisp.
I wouldn't build lisp atop a non-lisp (buggy, ad hoc, informally specified, etc. etc.) runtime. Except maybe erlang. There's lisp platforms with decent enough performance that that doesn't seem like a factor, and somehow libraries alone don't seem like a compelling enough reason. Do you have any other reasons I haven't considered?
"I'm mostly interested in the lower level of implementing arc at this point, but if [your design decisions] resulted in an easier implementation, I'm interested about them too."
Hmm, I did describe how using common lisp (rather than scheme/racket) simplified my implementation.
"I wouldn't build lisp atop a non-lisp (buggy, ad hoc, informally specified, etc. etc.) runtime."
Lisp-on-lisp can be just as ad-hoc, informally specified, and buggy. I see no real reason that arc needed to be implemented at all. After all, it's "just scheme" with a few simple aliases right? I'd argue that arc is also pretty informally specified, and sometimes even buggy. Does that prevent us from using it? No. Which tools are used for developing software has little to do with how well it is written. Yes, there is a very high probability that my lisp will be all of the above, but the line you are quoting is specifically about unintentional implementations of lisp, not intentional ones. Unless you're claiming that all other non-lisp platforms are buggy ad-hoc and informally specified, in which case I don't really know what to say.
Really, I'm just taking a long time to say that not all lisps are written in lisp, and that being written in lisp is neither necessary nor sufficient for a good lisp implementation.
"somehow libraries alone don't seem like a compelling enough reason"
Libraries can be a very compelling reason when deciding which language to use. And since I mainly want to write a language that I can use, having good library support is a wonderful feature. Don't get me wrong, I love arc and its easy hackability, but several times I've tried to do something in arc for which the library support just isn't there or is somewhat deficient, and then there's not much I can do about it. Having library support can make a big difference in ease or even possibility of writing a given application. The arc challenge without arc support for web development would be a lot trickier, but an arc challenge without arc support for sockets would be nigh impossible without writing external code.
However, libraries aren't the only reason I'm writing for a non-lisp platform. I also consider it to be an interesting programming exercise, and it puts more of the system under the programmers control. Right now in arc the reader and similar low level pieces are mostly unavailable for hacking, since it's all written in scheme. As such, most of us end up using something like rlwrap for the shell, and overloading ssyntax for all of our reader modification.
As good as those reasons sound, I am not trying to implement arc on .net because I think it will improve arc. Rather, I'm implementing arc on .net because I think it will improve myself as a programmer, and .net as a platform. As far as I know, there are no implementations of lisp on .net that are even remotely usable, while on the JVM there is at least Clojure as well as half a dozen arc implementations. If I want to do any lisp based application development for .net and DirectX in particular, at this point I pretty much have to write it myself.
I am not trying to implement arc on .net because I think it will improve arc. Rather, I'm implementing arc on .net because I think it will improve myself as a programmer, and .net as a platform.
Yeah that makes sense. I certainly didn't mean to discourage you or anything.
I see no real reason that arc needed to be implemented at all. After all, it's "just scheme" with a few simple aliases right?
_Precisely_ the point of wart. I want to maximize the 1-1 correspondence between arc and common lisp to minimize the work I have to do. I'd love to get you to take a look at the code and tell me what you think.
I wasn't claiming lisp implementations should always be atop lisp (clearly impossible), or that lisp implementations can't be buggy. Venturing down the long hard road of dealing with an immature runtime is just not for me, that's all :) (I was a systems programmer in a past life.)
having good library support is a wonderful feature
I find I can often build what I need. Or I can leverage the FFI. Or I can setup a server to provide services from other languages. All those seem relatively painless in lisp, and between them seem to cover all use cases. This is how I stay on easy street where the views are nice and the demons have been banished.
That's true. Any decisions affecting the core and the reasoning behind them would be useful at this point.
In fact, it would be really interesting to hear more from pg explaining some of the cryptic comments in the original source and some of the deviations of the current arc from the designs that he outlined in his earlier essays. If the explanation for most of them turns out to be "it was easier" or "it looked better" that's ok, I just wonder some times whether shortcuts and aesthetics explain the difference, or whether there were some deeper, hard-earned insights involved.
At least for nil vs () and a couple of other issues, I've tramped up and down over the territory and reassured myself that there aren't any huge subtleties. I've also tried to ensure (github, unit tests) that any subtleties I find are exposed to anybody following.
