Re: Dylan rather than CL -- why?

[Jeff Dalton <jeff@aiai.edinburgh.ac.uk>]

> >> fhd@panix.com (Frank Deutschmann) writes:
> >> 
> >> > 3) Why seperate the developmet environment from the language?
> ...
> >> 
> >>       o delivery - you don't want to deliver the environment.  At
> >>       some point you need to deliver an application and make the
> >>       break between environment and language.  Why not specify that
> >>       break up front?
> >
> >You typically don't want to deliver the _language_ either.
> >If you're delivering the language -- ie if users of the application
> >are going to me adding Lisp code -- why deprive them of useful tools?
> 
> There is no attempt at depravation. It is rather the other way around. 
> Unless you draw a clear distinction between the language and the
> development environment, you can never ship without the development
> environment because you don't know what you can seal off.

I would say EVAL is more of a problem than the development env here.
You can't find everything that can ever be called, because the program
might construct an expression that called anything it wants.

However, there are a number of ways to deal with that problem.
For instance, you could add a rule that said nothing could be
called via EVAL that wasn't also called (or referenced) directly;
or the implementation could provide such a facility as an extension.

> Smalltalk-80 was
> notorious for this as you could not just "ship binaries"-- you had to ship
> the development environment.  Languages such as Scheme or Dylan allow you
> to cleanly seal off parts of all of a system.  You can link together an
> application rather than just do image snapshots (much nicer to program your
> car's engine controller with 1/2 8^).

You're right to say that's how CL applications are (usually) built.
You load files into Lisp and save an image.  But Common Lisp could be
implemented in a way that let you build an application by linking
some .o files with a library.

Moreover, you could save images that didn't include the dev env.
You can already do this with Lucid CL.

In short, while I share the concern about applications, and agree
that a clear separation between lang and env is a good idea, I don't
think that separating them in the implementation (as opposed to the
language definition) it's the only good way to do Lisp.  Of course,
it depends in part on what's in the env and what depends on it.
SmallTalk has a greater problem that Common Lisp in this respect.

-- jd