[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: EVAL-OTHER (Version 2)
- To: Jon L White <jonl@LUCID.COM>
- Subject: Re: Issue: EVAL-OTHER (Version 2)
- From: Brad Miller <miller@CS.ROCHESTER.EDU>
- Date: Mon, 24 Oct 88 21:06 EDT
- Cc: masinter.pa@Xerox.COM, common-lisp-object-system@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU
- In-reply-to: <8810210017.AA06100@bhopal>
- Organization: University of Rochester, Department of Computer Science
- Phone: 716-275-1118
- Postal-address: 610 CS Building, Comp Sci Dept., U. Rochester, Rochester NY 14627
- Reply-to: miller@CS.ROCHESTER.EDU
- Sender: miller@CS.ROCHESTER.EDU
Date: Thu, 20 Oct 88 17:17:51 PDT
From: Jon L White <email@example.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.
Brad Miller U. Rochester Comp Sci Dept.