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

[dyer@eagle.sharebase.com (Scot Dyer)]

From: john@linus.mitre.org
/// 
/// Scot Dyer (dyer@eagle.sharebase.com) writes:
/// 
///   I think leaving eval out of the spec was an error,
///   since only those who use it must pay the price...
/// 
/// I think an operator like EVAL might be rather complicated in a
/// language with multiple syntaxes, such as Dylan is intended to be.
/// Must EVAL handle all possible syntaxes, e.g.
/// 
///   (EVAL '(SET! Y (+ X 2)))      ; Lisp-like syntax
///   (EVAL "y = x + 2 ;")          ; Algol-like syntax
///   ...                           ; etc.

Seems like simple 'polymorphism' (overloading) to me.  And only users linking
to the method for eval'ing a string actually need it included (if the type of
the object they're evaling can be deduced by the compiler).  Of course, it
_is_ a rational argument against implementing a feature that it might be hard
to do so...

/// Note that there are almost certainly expressions that are ambiguous,
/// unless the syntax is specified (in a keyword argument?).

..especially if you'd have hygenic problems doing it right:

	(EVAL "y = x + 2 ;")
	==> "y = x + 2 ;"
or	==> {the value of (+ x 2)}

/// Also note that EVAL for non-LISP syntaxes is probably quite
/// complicated, and must include a lexer and all the attendant machinery.
/// Youch.

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.

/// This problem might be simplified by having the EVAL module define
/// object types to represent syntax-independent program-fragments.  These
/// might be necessary anyway, for a multiple-syntax language.  EVAL would
/// be handed such structures, instead of syntactic expressions.  (Is it
/// the Pop language that has these sorts of structures?)

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)

/// 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 ...

It is elegant, at least, to be able to write the read-eval-print loop.

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.

/// John Burger
/// john@mitre.org

	-- Scot