[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)
- To: firstname.lastname@example.org
- Subject: Re: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)
- From: cfry@MIT.EDU (Christopher Fry)
- Date: Mon, 07 Dec 92 13:59:53 EST
- Cc: email@example.com
> Return-Path: <firstname.lastname@example.org>
> Posted-Date: Mon, 07 Dec 92 11:18:23 EST
> To: email@example.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: firstname.lastname@example.org
> Scot Dyer (email@example.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.
>I think you have the Lisp EVAL and READ functions confused with each
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
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.