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

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

> There aren't many applications for eval, I'll give you that.  There are
> probably even less with an Algol style grammer...  Perhaps not allowing
> eval with alternate grammers?  Eval is a pretty LISPy idea anyway, and I
> doubt non-LISP nuts would even be able to think of a use for it.

I think the actual situation is almost the opposite.

These days, Lisp programmer know that EVAL should be used only in a
narrow range of cases and they know all the techniques that can be
used instead of EVAL.  It's people new to Lisp who tend to use EVAL,
especially in cases where it's not really needed, and who invent all
kinds of bizarre ways to use it.

Moreover, I think the range of applications is almost independent of
the style of grammar.

> I don't know about Pop, but it seems like the output of the parser would be
> LISP style code, yes?  This would be easiest to implement, I think, although
> I doubt that any internal representation will be part of the spec unless eval
> gets included (which it probably won't)

One of the main alternatives to EVAL is macros, and it helps to be
able to manipluate what are in effect parse trees instead of less
structured representations such as strings.

One of the advantages of Lisp-style code is that it (or a subset of
it) can double as an internal represetnation for other syntaxes.

> /// I'm fairly agnostic about all of this, however.  I never use EVAL in
> /// Lisp, and the only excusable use for it I can see is READ-EVAL-PRINT
> /// loops in certain kinds of user interfaces, such as programming
> /// environments.  Which is what started this discussion ...

I too am fairly agnostic.  I don't mind of some dialects of Lisp omit
EVAL.  I think there's more than one good way to do Lisp.  However, I
will defend EVAL against claims that it should always be excluded from
any good language.

> In a language with dynamic environments and a good ability to manipulate them
> (closures), eval can be a powerful tool for many tasks, like writing meta-
> interpretters and rule-based systems.  These are probably things which most
> Dylan users (converted C programmers in the vast majority, probably) won't
> want to do.

In my experience, meta-interpreters and rule-based systems can usually
get by w/o EVAL.  A typical trick is to take an expression in a macro-call
that might be evaluated and have the macro expand to something that
includes

  #'(lambda () <expr>)

rather than

  (quote <expr>)

-- jd