[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: john@LINUS.MITRE.ORG
- Subject: Re: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)
- From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
- Date: Mon, 07 Dec 92 11:50:13 EST
- Cc: info-dylan@CAMBRIDGE.APPLE.COM
- In-reply-to: Your message of Mon, 07 Dec 92 11:18:23 -0500. <9212071618.AA11380@thelonius.mitre.org>
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.
This shouldn't be a problem. Eval operates not a text string (surface
syntax) but on the internal representation of a program. This is easily
confused in Lisp because the mapping from surface syntax to internal form
is so simple and direct. In a C-like syntax, the mapping at "read time"
and "print time" would be more complex, but I would hope that the resulting
internal program representation would be common across all surface
syntaxes, so the same EVAL could be used.
I've got no problem with leaving Eval out of the base Dylan spec. It
probably should be standardized as an optional facilty, however, so that
all implmentations that do provide EVAL provide it in a compatible way.
Scott E. Fahlman Internet: email@example.com
Senior Research Scientist Phone: 412 268-2575
School of Computer Science Fax: 412 681-5739
Carnegie Mellon University Latitude: 40:26:33 N
5000 Forbes Avenue Longitude: 79:56:48 W
Pittsburgh, PA 15213