elg@usl (Eric Lee Green) (09/14/87)
Values, data, and procedures: Can we building a consistent world view in Lisp-like languages? Overview: We know what data is. Symbols have a value cell. This value cell contains data. The process of evaluation returns this value. But how do we reconcile this with procedures? Procedures are data. They are stored in memory just like any other data. The value-cell of symbols should be able to point to procedure objects, if we are to be consistent, allowing interchangability and not having special classes of symbols. Evaluating a symbol with a procedure-value should, to be consistent with the action of eval upon data objects, return the value of the data cell of the symbol. But wait, how do we actually execute the procedure! Lisp does this with hand-waving and head-nodding, by making programs consist of lists, the first element of which is always assumed to be a procedure which needs executing. In other words, we are introducing "syntactic sugar" to work around the problem of having to explicitly indicate what we wish to be executed. Lisp and Scheme do this kind of hand-waving in many places. For example, (defun urgh (junk foo) (blah1) (blah2)) defines a procedure "urgh" in your symbol table. "urgh", (junk foo), etc., are actually literal data input to the define-a-function routine. Yet the form of the call to "defun" is virtually identical to that of (+ a b) where we feed the VALUES of "a" and "b" to the "+" function. Questions: Can this dichotomy between value and execution be mended for procedure-objects without hand-waving? Would requiring literal data to be quoted be too big an imposition upon the programmer, and would it be worth the gain in expressiveness? (just imagine macros without the mess). A possible but kludgy scheme: When procedure symbols are encountered in the eval stream, they are called with the next list in the eval stream as the parameter list. A special prefix character is necessary to explicitly access the procedure-object, to, for example, assign it to another variable. A program might look like + (2 2) print ( / (2 f)) etc. In other words, the effect would be to move the parentheses around, in comparison with traditional Lisp dialects. Why this is kludgy: We are, again, attaching special considerations to the evaluation of symbols whose value is a procedure-object. I would appreciate any discussion or references about this subject. -- Eric -- Eric Green {ihnp4,cbosgd}!killer!elg {ut-sally,killer}!usl!elg elg@usl.CSNET
peter@sugar.UUCP (09/16/87)
> [instead of] > > (+ a b) > > A program might look like > > + (2 2) In the lisp 1.5 system on the 11/70 at Berkeley some years ago this was an alternate input parser. You could switch to it using the ($mumble) special function. I thought it ugly, but some people liked it. I think this was called nlambda form, because it also deferred evaluation of the arguments until you eval-ed them. FORTH has a valid alternative syntax and semantics that captures some of the flavor of lisp. You might want to look into it for ideas. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` ^^^^^^^^^^^^^^ Not seismo!soma (blush)