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

[cfry@MIT.EDU (Christopher Fry)]

> Return-Path: <john@linus.mitre.org>
> Posted-Date: Mon, 07 Dec 92 11:18:23 EST
> To: info-dylan@cambridge.apple.com
> Subject: Eval - Pro's and Con's (was Re:  Dylan rather than CL -- why?)
> Date: Mon, 07 Dec 92 11:18:23 EST
> 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...
>
 John Burger writes: 
> 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.

Moon Writes:
>I think you have the Lisp EVAL and READ functions confused with each
> other.
I bet Moon's right here. To handle multiple syntaxes, a READ function should
take an additional arg [probably keyword] which indicates which syntax you're
using ie :lisp  or :infix.
Presumably :lisp would be the default and other language syntaxes would be provided as 
libraries that could be added on.

Moon Also Writes:
> Dylan includes neither. [eval or read]

I knew eval wasn't provided but didn't read the book carefully enough to 
note that READ wasn't. Sometimes I use statements like:
(my-own-eval (read ...))
Implementing READ is pretty complex due to a myriad of nit-picking details.
Its nice to have that functionality built in or at least loadable in a
standard library.

I notice PRINT isn't part of Dylan either so Dylan is "coherent" in not providing
any one of READ, EVAL, PRINT in its core.