Re: Issue: EVAL-OTHER (Version 2)

[Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>]

I'd like to propose an alternative (or rather elaboration) to
EVAL-OTHER:SELF-EVALUATE,  currently...

    Proposal (EVAL-OTHER:SELF-EVALUATE):

      Standard data types (those mentioned by CLtL) other than those for which
      a more explicit evaluation rule exists would be defined to self-evaluate.
      Such data types include, for example, structures, arrays, vectors, and
      pathnames.

      Structure types defined by users using DEFSTRUCT should also self-evaluate
      unless an explicit implementation type for the structure is given in the
      DEFSTRUCT, in which case the rule for evaluation of that type should be
      used. (This is important in the case of type LIST.)

I would suggest that the DEFSTRUCT (or DEFFLAVOR) have an option that
explicitly specifies the eval behavior.

Rational:

When using lisp to build an embedded language, one can already define via a
DEFSTRUCT option what the printer for the object should be. One can also,
via character macros define a specific parse behavior. One cannot, however,
currently define an EVAL behavior.  For example, I can define #\[ and #\] to
denote the beginning and end of information for consing a structure FOO via
character macros which will print the same way.

e.g. [A FOO] may really be internally #S(FOO SLOT1: A SLOT2: FOO SLOT3: NIL)

what I may want to define is that (cons [A FOO] [B FOO]) return (A B)
because the EVAL option on foo returned the value of SLOT1.

In general, one could define that instances and structure objects (the
latter are probably instances given CLOS) all handle an EVAL message which
the user can use to explicitly define the behavior. The default handler
returns the object itself, which is compatible with the
EVAL-OTHER:SELF-EVALUATE proposal already made.

Similar arguments to the above can be made for APPLY. The ultimate idea is
that user created objects can be treated as first class objects, just like
symbols.

Comments?

----
Brad Miller		U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}