Re: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)

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

> I don't mean to say there aren't 'legitimate' uses of eval.  There
> are.  Unfortunately, eval, like nil, has earned LISP a rotten
> reputation because of the haphazard treatment of the environment eval
> is supposed to use. 

Really?  Lisp has a rotten reputation among people who know so much
about it that they're bothered by a particular semantics for EVAL
rather than by EVAL in general?  And this gives _Lisp_ (rather
than the particular dialects that have this version of EVAL) a rotten
reputation?  

> Without dynamic scope, eval becomes near to
> meaningless unless some way to specify an environment is provided.

Which is way EVAL tends to have such an argument in purely
lexical languages (eg, Scheme implementations and dialects).

> I did list meta-interpretters and rule-based programming as
> applications for eval.

And you can often get by w/o it there too.  (At least I do.)

However, there are times when the alternative to EVAL is to write a
specialized EVAL fo your own, and then you could often save time by
using Lisp's EVAL.  Think of cases where the user enters an expression
and you want to produce a function that evaluates it, for instance.
Or suppose you use Lisp as an "extension language", as in Emacs or
AutoCAD.

>  I don't think they will be of interest to Dylan
> developers because Apple has made quite an effort to emphasize that
> Dylan is for application programming, not AI.  I for one am hard
> pressed to find uses for eval that 'conventional' programmers would
> want.  Eval is simply not conventional.

>   frankly I don't think the people at Apple are that
> interested in fixing all of LISPs problems as much as making Dylan
> palatable to those just being weened from 'C.'

But dynamic languages aren't "conventional".  If the aim is to
appeal to C programmer without departing from the conventional,
then Dylan isn't what you want.

Somewhere in the background of this discussion seems to be the
idea that Lisp is a single language with certain "bad" properties
that someone (but not the designers of Dylan) might want to fix.
But in fact there are a number of different Lisps, some of which
have already fixed these things (even though many of the "bad" 
properties also turn out to be "good" for certian purposes).  

What I'm saying may look contradictory.  Some things have been
fixed, but they're not really bad.  The way this gets resolved
is to say there's more than one good way to do Lisp.  There
can be different kinds of Lisp, aimed perhaps at different tasks,
with different advantages and disadvantages -- just as there
can be different programming languages generally.

Dylan is one way reasonably good way of doing Lisp.  But it isn't
as far from the rest of Lisp as it may seem.  Dylan is very close
to Scheme (+ part of CLOS), to ISO's ISLisp, and to EuLisp Level 0.
Common Lisp isn't the only Lisp to compare it to, and these other
Lisps have already moved Lisp in a direction very similar to Dylan's.

-- jd