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?
> 
> Here are two reasons I feel are important, one of which you
> mentioned.
> 
> 	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?

> 	                 While some Lisp systems provide ways to trim
> 	down a Lisp image, it's not the same as producing a .o file
> 	that can be linked with other languages that follow certain
> 	conventions.

True, but not necessarily relevant.  You can compile a Lisp file to a
.o file and link it with other .o files plus a library.  This is a
possible implementation of CL.  However, the library would be large.
Smaller libraries that do not contain the development env (eg, they
would nto contain the compiler) could also be supplied.  The WCL
implementation is pretty much along these lines.

> 	o flexibility - it's not clear that the same development
> 	environment will work on every machine that one might program
> 	in Dylan. 

It's also not clear that the same I/O will not work...

Of course, Dylan the language doesn't have I/O.  But that doesn't
mean there cannot be an I/O library.

>                   Requiring a certain type of environment might
> 	restrict the spread of the language (sounds like a virus or
> 	something :-).

I agree with that part.

> I would highly recommend the article "Lisp: Good News, Bad News, How
> to Win Big" by Richard Gabriel of Lucid.

A problem with RPG's position is that be puts Common Lisp in the
"right thing" camp whereas it is in fact "worse is better" in many
respects.  For instance, no one thinks packages are the right way
to do "modules", but they're available now and work fairly well
(eg, with CL's "worse is better" macros).

Anyway, I think the main reasons for separating the language and
environment are (a) conceptual modularity and (b) to allow a wider
range of implementations (in particular, ones that include only the
language).

-- jd