On the one hand, factor -does- have named variables.
On the other hand, once you start experimenting with stack stuff there's a moment where you go "aha" and it actually starts to make a lot of sense for temporary variables.
There are probably other aha moments further in that I haven't got to yet; I've not spent as much time with factor as I want to.
I dunno if I'll ever use it for "real stuff", but I think it's worth fighting your way through to the aha moments just like lisp and haskell are even if you never expect to use -them- for "real stuff".
It occurs to me that you could get away with most of that just by getting to perl, since perl can already call Python, Java etc. through the Inline:: modules.
And, for bonus points, somebody's already bolted perl into mzscheme -
If you do have a go, mail me at mst -> shadowcat.co.uk, I know a bit about the perl side of things and my first CPAN release was fixups to Guile.pm so I'd be interested to help you.
Hmm, Language::MzScheme isn't compiling against MzScheme v352. The documentation says it works with MzScheme v200 or greater, so I suspect it might not have made the transition to the v300 series.
You can implement this on top of my given axioms. My system isn't meant to be friendly; it's meant to be the simplest possible building blocks for a friendly system.
Looking at clients' deployed applications, the web boxes tend to average over a year's uptime so I can't say it seems like it'd matter that much.
Provided you've got runtime code loading and a useful QA process, I don't really see why you'd need to care - MySQL's lack of transactional DDL causes far more downtime than lack of serialisation would were we using a continuation-based system.
Personally, lisp-2-ness is the thing I most despise about CL - and I'd note that it was originally an implementation detail that seriously consideration was given to changing, stopped primarily by the "but everybody's already implemented it" principle that arc's current refusal of backcompat is designed to avoid.
I do see your point re (with (a nil b nil c nil) but I don't really see why this justifies more than a (with-nil (a b c) macro.
> lisp-2-ness is the thing I most despise about CL
It's conceptually ugly, but that's what makes non-hygienic macros usable.
A macro which uses a global variable is broken when used in a context which shadows this variable; if functions are not "normal" globals, there is much less chances that you'll shadow them accidentally.
Just make sure it's Artistic License v2; there are some doubts over v1 and while most of the perl community doesn't really seem to be worried by them certain distros (notably fedora) dislike it and tend to spam people with software under it asking them to relicense.
Me, I just use the perl5 license and tell the people who don't like AL1 they can use the GPL half of the disjunction if it upsets them so much.
