brister@td2cad.intel.com (James Brister) (03/07/89)
COMMON LISP gurus (and maybe non-gurus--I'm still new to LISP). I have a question concerning the evaluation of the first element in a form. If the first element is not a symbol then only a lambda expression is legal (right?) According to CLtL the lambda expression is treated as the name of a function and isn't evaluated--which wouldn't be meaningful. The question. What about the language prohibits this? It would be nice to say: (defun foo () '(lambda (x) (* x x))) or even (defun foo () #'(lambda (x) (* x x)) and then ((foo) 4) instead of having to mess with funcall's all the time. It seems to me (and I'll admit to ignorance) that it wouldn't be too hard to have the evaluation say "If the element is not a symbol or a lambda expression, then evaluate this (sub) form and apply its returned value to the arguments of the function call." I noticed Scheme does this and Guy Steele was involved in both language specifications. Comments? Should I put on my asbestos underwear? James -- --------------------------------------------------------------------------- James Brister brister@td2cad.intel.com (408) 765-9713 ...!decwrl!td2cad!brister "Is the set of all respectable sets respectable?"
barmar@think.COM (Barry Margolin) (03/08/89)
In article <BRISTER.89Mar6212320@andrea.td2cad.intel.com> brister@td2cad.intel.com (James Brister) writes: >If the first element is not a symbol then only a lambda expression is legal >(right?) According to CLtL the lambda expression is treated as the name of >a function and isn't evaluated--which wouldn't be meaningful. > >The question. What about the language prohibits this? Nothing about the language prevented it from being included. It was an arbitrary decision by the designers of Common Lisp. Common Lisp is mainly descended from MacLisp and Zetalisp, and they didn't include this feature (actually, MacLisp would do it, but the compiler would print a warning). The feeling among much of the Common Lisp community is that it is appropriate to specially notate use of computed functions. Hence, instead of doing ((foo) args) you must do (funcall (foo) args) Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
pc@linus.UUCP (Melissa P. Chase) (03/09/89)
You might to look at the article by Richard Gabriel and Kent Pitman,
"Technical Issues of Separation in Function Cells and Value Cells,"
that appeared in the first issue of LISP and Symbolic Computation.
- Penny
--
UUCP: { ... }!linus!pc
INTERNET: pc@mitre.orggaynor@athos.rutgers.edu (Silver) (03/12/89)
Penny (pc@mitre.org) writes: > You might to look at the article by Richard Gabriel and Kent Pitman, > "Technical Issues of Separation in Function Cells and Value Cells," > that appeared in the first issue of LISP and Symbolic Computation. I find seperate function and value cells for symbols somewhat distasteful, adding unnecessary complexity to the langauge. It wavers from the functions as data philosophy. I wouldn't mind seeing a little action on this topic; perhaps some of you might care to impart your opinion and the reasoning that formed it. Regards, [Ag] gaynor@rutgers.edu
barmar@think.COM (Barry Margolin) (03/13/89)
Many members of X3J13 (the ANSI committee standardizing Common Lisp)
agree that separate function and value cells are inferior (I'm not one
of them). We've had much discussion about the issue, and even used to
have a subcommittee investingating it. The previously-mentioned paper
by Gabriel and Pitman is basically the result of that investigation.
The most important result of our discussion has been the concensus that
in this case compatibility is more important than language purity.
MacLisp, Zetalisp, and Common Lisp all have separate function and
variable namespaces, and it would be a major incompatibility to change
this in the ANSI standard.
A secondary result was the realization that functions and variables
are not the only things named by symbols, so merging these two
namespaces would not be the "grand unification" many people expect.
For example, symbols also have property list cells, and they are used
to name classes and data types. We had been calling Common Lisp
"Lisp-2" and Scheme "Lisp-1", but now it appears that the issue is
"Lisp-N" versus "Lisp-N-1". Those of us in the Lisp-N camp believe
that objecting to just one of these namespaces is half-hearted and
inconsistent.
Barry Margolin
Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmarplogan@mntgfx.mentor.com (Patrick Logan) (03/15/89)
In article <37400@think.UUCP> barmar@think.COM (Barry Margolin) writes:
=> A secondary result was the realization that functions and variables
=> are not the only things named by symbols, so merging these two
=> namespaces would not be the "grand unification" many people expect.
=> For example, symbols also have property list cells, and they are used
=> to name classes and data types. We had been calling Common Lisp
=> "Lisp-2" and Scheme "Lisp-1", but now it appears that the issue is
=> "Lisp-N" versus "Lisp-N-1". Those of us in the Lisp-N camp believe
=> that objecting to just one of these namespaces is half-hearted and
=> inconsistent.
Someone who doesn't know Scheme may be lead into thinking Scheme has
separate name spaces for property lists, classes, and data types.
Scheme only has one name space, for the value bound or assigned.
I appreciate that simplicity and feel class hierarchies and property
lists, etc., should be implemented as data structures within the
environment.
Alternatively there could be a different name space for every data type!
That may satisy my friends who don't like Lisp's approach to type checking.
(Smile?)
--
Patrick Logan ...!{decwrl,sequent,tessi}!mntgfx!plogan
Mentor Graphics Corporation
Beaverton, Oregon