[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue: EVAL-OTHER (Version 2)

    Date: Thu, 20 Oct 88 17:17:51 PDT
    From: Jon L White <jonl@lucid.com>

    re: w/o generic EVAL or APPLY, CLOS is just a bag on the side of CL. 

    I can't agree with this at all.  CL is an extremely useful programming
    language, and with CLOS added it is incredibly more  useful.  EVAL
    is a boringly obscure operation to apply to any piece of data -- it
    merely decodes the syntatic means by which programs are written.  Writing
    programs encoded as strings rather than lists and symbols, or encoded in 
    *any* other random datatype, is hardly a great step forward.

    While that last sentence might be open to continuing theoretical debate,
    there is the practical observation that MacLisp/NIL *did* make such an
    extension (using the object-oriented system called EXTEND), and there
    were virtually no meaningful uses of it.  [I'm not 100% sure but I think
    Glenn Burke may have used it somehow in the Layered System Building
    project.  Apologies, if that use was "meaningful".]

    In fact, the EVAL-related extension that really has some vocal supporters
    behind it is to *increase* the level on standardization in the coding of 
    EVAL, so that research projects into the likes of debuggers and window 
    systems can put more "hooks" into the interpreter.  See Henry Lieberman's
    "Common Eval" proposal.

    -- JonL --

I plan on writing you a response to this, but I'm currently swamped;
just to let you know that my silence isn't agreement. I suspect the
fault was mostly mine: I only gave a trivial example of such use, and
I can give much better ones from my work on the RHET project.

The short cleanup is that while theoretically a full-blown generic
EVAL is "interesting", I certainly *don't* consider it practical. I'm
simply trying to allow the user to specify an eval-function for user
created types, rather than having them always self-eval. Generating
code for these types as (EVAL-YOURSELF <instance>) rather than
<instance> doesn't seem to be a particularly difficult implementation
problem, nor do I think it has a particular bad effect on debuggers.
Appropriate method combination for EVAL-YOURSELF should allow for a
debugger hook (though I've not thought this through carefully).

Thanks for your response.

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