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.CSNETpeter@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)