This seems like a good place to checkpoint my thinking on nil.
aw (http://arclanguage.org/item?id=10798) and waterhouse (http://arclanguage.org/item?id=12650) have spoken out strongly for nil to be a sym. I've chosen to leave it as () and without a type, primarily because that's the convention in the underlying PLT scheme. It just doesn't seem important enough to change (I'm still seeking counter-examples).
I'm starting to view arc not as a language but as a thin membrane over an underlying lisp. A leaky abstraction, one that has yielded for me both a gateway to ease into lisp programming, and a more elaborate vocabulary for thinking about lisp macros (code walkers and so on). But the underlying lisp is still doing 90% of the heavy lifting, and rather than try to hide that fact away I seek now to aggressively embrace the leakiness.
I now try to think of it as programming in PLT scheme or SBCL, rather than arc. I've been growing an SBCL implementation for arc based on waterhouse's code (http://arclanguage.org/item?id=11529) and when I use that version nil is a sym because that's how it is in common lisp. Surprisingly enough both views are equally easy to hold, and also to switch rapidly between.
I'm starting to view arc not as a language but as a thin membrane over an underlying lisp.
When I first read this I thought, "But what about arc on top of other languages beside scheme?" Then I realized I started writing Jarc because I wanted a thin membrane over Java. Interesting way to think about it.
Yeah I started thinking this way after spending some time atop sbcl. I'll release that at some point. It's quite surprising how little code you need to build the arc transformer when you choose the right lisp implementation, when you're not going against the grain of the underlying lisp.
