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

[samp@kurz-ai.com (Sam Pilato)]

   Inter-application communication and EVAL are two separate issues.

   I may have an application that does not have EVAL, but it will connect
   with another application as a client or a server. For example, a help
   server can be contacted to display help on some topic. EVAL is not
   needed.

   Some other application may have IAC and EVAL, and in particular it may
   allow some other application to connect and do "remote evaluation".
   For example, a window system server may allow clients to connect and
   send functions to the server, extending the capabilities of what the
   server is capable of doing without involving the remote client. (Can
   you say NeWS?)

   In both of samp's examples, the server application is apparently a
   language evaluator and the client wants something evaluated. There is
   no demonstration of IAC having anything in common with EVAL.

I think some type of EVAL _is_ implied by inter-application
communication, but we might mean different things by EVAL.

What can be meant by an EVAL in Dylan?  Dylan doesn't define EVAL, nor
does it even define a correspondence between Dylan source-code syntax
and Dylan evaluable objects (in Lisp, forms), historically mediated in
the Lisp family by a READ contract.

To consider introducing EVAL into Dylan, I assume we're defaulting to
a Lisp-like evaluator, so we're talking about advertising a contract
for the interpretation of some currently unspecified classes of Dylan
objects as function calls (or variables or constants -- or
application-interpreted tokens -- to be resolved).

Who constructs these objects?  The constructors might be explicitly
provided in Dylan; they might be implicitly provided by providing only
a READ function interpreting an external syntax (Dylan syntax or
otherwise); an interface may be defined allowing a foreign body of
code to cause the construction of some Dylan object (such as
isomorphic to an Apple event object) needing interpretation by Dylan
as a foreign function being called.  (I.e., Dylan is the "language" of
the foreign function, but the caller need not know Dylan syntax.)

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'm not a computer language implementer, but it seems that the server
aspect of a foreign function interface _could_ get away with not
distinguishing READ from EVAL, and accept only strings (or character
streams) in Dylan syntax.  I guess it depends on whether you want a
foreign _language_ interface as well as or instead of a foreign
_function_ interface.  A foreign _application_ interface implies a
distinction, though, since cooperating applications shouldn't need to
know each other's source-language syntax.)

To me, this topic does seem relevant to Dylan, however small you want
to make it, if Dylan is to be embeddable in larger, foreign,
environments.  I'm asking whether Dylan best provides separate EVAL
and EVALSERVE, or a single eval for both purposes, or neither.