[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)
- To: info-dylan@cambridge.apple.com, patl@goldfish.mitron.tek.com
- Subject: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)
- From: samp@kurz-ai.com (Sam Pilato)
- Date: Wed, 9 Dec 92 16:08:51 EST
- In-reply-to: Patrick Logan's message of Wed, 9 Dec 92 09:03:01 PST
Date: Wed, 9 Dec 92 09:03:01 PST
From: Patrick Logan <patl@goldfish.mitron.tek.com>
Date: Wed, 9 Dec 92 11:24:32 EST
From: samp@kurz-ai.COM (Sam Pilato)
[...]
I think some type of EVAL _is_ implied by inter-application
communication, but we might mean different things by EVAL.
[...]
In the last case, (let's call it ...?) EVALSERVE interprets an object,
dispatching on operator name, class, and class of (recursively
interpreted) operands, as a function call or token resolution. To me
that counts as evaluation.
I think we are talking about two different things: an evaluator for
the Dylan language that is integrated with, changes, and extends the
same Dylan environment used to implement the application; and an
evaluator for a language that is implemented in the application, which
may be a "meta-circular" implementation of Dylan, but it does not
change or extend the "original" Dylan's environment.
Does that make sense?
Yes, I think I understand your distinction. In the first case you're
talking about a traditional EVAL, and in the second case any other
language using Dylan code for its interpreter.
In particular, the "other" language I'm talking about has code objects
something like Apple event objects, and Dylan (or perhaps more likely
an application written in Dylan) handles some subset of those events,
via a kind of "evaluation".
If it handles an application-defined and perhaps foreign-extensible
variety of events, and if the event objects can be mapped to Dylan
"forms" (currently nonexistent), then the language begins to look like
a nice inter-application interface. I'm wondering whether a native
EVAL in Dylan might serve as a handy, generic, and efficient
implementation of that language.