Re: compiling es

[Paul Haahr <haahr@mv.us.adobe.com>]

> First impressions:  ``let'' and ``local'' are backwards!

hmm, what do people think about this?  we picked let first, with its
current semantics, before we'd even decided that es would have closures.
when we added closures, we knew we'd need a different binding keyword,
and local seemed reasonable.  hadn't realized that perl used it for
what we're calling let.  (the one case of prior art for a language with
both keywords that we knew of was ken brooks' two-view document editor,
and he picked the same usage we did.)

> Surprisingly, es binary is quite a bit bigger than that of rc, even
> though the source isn't much bigger.   Maybe gcc just generated really
> bad code, or something?

it's all the Ref() things for the garbage collector, methinks.  they
push a lot of stuff that should be in registers onto the stack, with
a lot of extra code to manipulate the root list.  perhaps we should
have used a different form of garbage collector.

> Echo is a primative, but not read isn't.  That's rather asymmetrical.

to support a user-written read-eval-print loop, there will be some input
mechanism in the next version, due out in a couple of weeks.  it won't
be read w/sh semantics, though.  what's general opinion on adding a read
primitive?  (i don't want to start a flamefest here, and i know that we
flushed some of that out on the rc list many moons ago, so i ask the
question somewhat gingerly.)

> As in rc, null terminated strings are used.

the main reason is that only null terminated strings can be passed in
the environment or argv vectors.  we had debated this extensively, and
decided strings with nul characters in them weren't important.  were
we wrong?  (the garbage collector uses the fact that strings don't
have nuls in them, but that's minor.)

> Whatis is only for functions, not variables?

for now, yes.  path searching & whatis are changing soon, and before
we start arguing about whatis & variables, whatis & signals, etc.,
wait for that part of the language to settle down.

> Guaranteeing that functions will be properly tail recursive would be
> great.

we know, we know!  that meant throwing away more code & organization from
rc than we were prepared to do for our first version, but we do intend to
do that.

> if someone were interested
> in doing an independent implementation of es,

that deserves a :-).  wait to see if this thing is actually useful before
considering independent implementations.  remember, for now this is just
a collection of unproven ideas.

> start with a small scheme interpreter and give it a new repl loop.

might be reasonable.  we started from rc for the obvious historical reasons.
pending a good model for macros/syntax extension that would support shell
syntax, i'd expect to stay with something based around a c+yacc implementation.