[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?)



   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.