Hi All,
I am pretty new to LISP and before starting LISP, I used to use
SCHEME (yeah, you're right, I'm an undergrad :). I am just wondering how
can I write a function that returns a function? Thanks in advance.
--Samuel--
Yale University
Branford College
Computer Science & Economics '00
Samuel Ieong wrote:
> Hi All,
>
> I am pretty new to LISP and before starting LISP, I used to use
> SCHEME (yeah, you're right, I'm an undergrad :). I am just wondering how
> can I write a function that returns a function? Thanks in advance.
Here is the classic currying example (paraphrased from Ansi Common Lisp by
Graham)
(defun (make-adder n)
#'(lambda (x)
(+ x n)))
Lisp is somewhat less simple/consistent than Scheme in the respect that
functions are evaluated differently than other types of values and that they
exist in different namespaces. When you want to treat functions like values
in Lisp, you have to prepend it with the #' (pronounced "sharp-quote"). The
sharp-quote is an abbreviation of a special form called FUNCTION. #'(lambda
(x) (* x x)) is the same as (function (lambda (x) (* x x))), and the Scheme
equivalent is just (lambda (x) (* x x)).
-Aaron
* Aaron Leung
| Lisp is somewhat less simple/consistent than Scheme in the respect that
| functions are evaluated differently than other types of values and that
| they exist in different namespaces. When you want to treat functions
| like values in Lisp, you have to prepend it with the #' (pronounced
| "sharp-quote"). The sharp-quote is an abbreviation of a special form
| called FUNCTION. #'(lambda (x) (* x x)) is the same as (function (lambda
| (x) (* x x))), and the Scheme equivalent is just (lambda (x) (* x x)).
`lambda' is a macro in ANSI Common Lisp that returns itself as a function
object. its definition is suggested in the specification.
(defmacro lambda (&whole form &rest bvl-decls-and-body)
(declare (ignore bvl-decls-and-body))
`#',form)
discommending unquoted `lambda' forms may be the only point on which I
disagree with Paul Graham, but I think omitting the #' on `lambda' forms
makes perfect sense. so did, apparently, a sufficient number of members of
the ANSI Common Lisp committee.
#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".
see http://www.naggum.no/emacs/ for Emacs-20-related material.
Erik Naggum <······@naggum.no> writes:
>
> `lambda' is a macro in ANSI Common Lisp that returns itself as a function
> object. its definition is suggested in the specification.
>
> (defmacro lambda (&whole form &rest bvl-decls-and-body)
> (declare (ignore bvl-decls-and-body))
> `#',form)
>
> discommending unquoted `lambda' forms may be the only point on which I
> disagree with Paul Graham, but I think omitting the #' on `lambda' forms
> makes perfect sense. so did, apparently, a sufficient number of members of
> the ANSI Common Lisp committee.
>
And indeed, this is a very good thing.
--
Marco Antoniotti
==============================================================================
California Path Program - UC Berkeley
Richmond Field Station
tel. +1 - 510 - 231 9472
Marco Antoniotti <m a r c o x a @path . berkeley . edu> wrote:
: Erik Naggum <······@naggum.no> writes:
: >
: > `lambda' is a macro in ANSI Common Lisp that returns itself as a function
: > object. its definition is suggested in the specification.
: >
: > (defmacro lambda (&whole form &rest bvl-decls-and-body)
: > (declare (ignore bvl-decls-and-body))
: > `#',form)
: >
: > discommending unquoted `lambda' forms may be the only point on which I
: > disagree with Paul Graham, but I think omitting the #' on `lambda' forms
: > makes perfect sense. so did, apparently, a sufficient number of members of
: > the ANSI Common Lisp committee.
: >
: And indeed, this is a very good thing.
: --
: Marco Antoniotti
: ==============================================================================
: California Path Program - UC Berkeley
: Richmond Field Station
: tel. +1 - 510 - 231 9472
Just jumping in here - this means, then, that lambda is actually
equivalent to #', in the same way quote is equivalent to '?
Larry
--
-- Larry Troxler -- ··@westnet.com -- Patterson, NY USA --
Lawrence Troxler <··@westnet.com> writes:
> Just jumping in here - this means, then, that lambda is actually
> equivalent to #', in the same way quote is equivalent to '?
No, #' is equivalent to FUNCTION in the same way as ' is equivalent to
QUOTE, i.e.
#'(lambda (x) (foo (bar x)))
is the same as
(function (lambda (x) (foo (bar x))))
--
Simon.
* Lawrence Troxler
| Just jumping in here - this means, then, that lambda is actually
| equivalent to #', in the same way quote is equivalent to '?
no, that's not it. #'x is read as (function x). 'x is read as (quote x).
you can easily see this by evaluating (car (read)) and typing in each form.
`lambda' is now a macro that wraps itself in a `function' form. this means
that (lambda (x) (+ x x)) evaluates to (function (lambda (x) (+ x x))),
which is what would be read if you typed #'(lambda (x) (+ x x)), so you can
omit the #' from `lambda' forms with no visible effects in normal code.
#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".
see http://www.naggum.no/emacs/ for Emacs-20-related material.
: I think the near-impossibility of explaining that mess to a novice is
: the best of all possible arguments against defining lambda as a macro.
: == Jamie (I mean, you're only saving two characters...)
Well, at least I surmised what "&whole" does.
Larry
--
-- Larry Troxler -- ··@westnet.com -- Patterson, NY USA --
Jamie Zawinski <···@netscape.com> writes:
> Erik Naggum wrote:
> >
> > `lambda' is now a macro that wraps itself in a `function' form. this means
> > that (lambda (x) (+ x x)) evaluates to (function (lambda (x) (+ x x))),
> > which is what would be read if you typed #'(lambda (x) (+ x x)), so you can
> > omit the #' from `lambda' forms with no visible effects in normal code.
>
> I think the near-impossibility of explaining that mess to a novice is
> the best of all possible arguments against defining lambda as a macro.
That's going a bit far. Macros are not normally explained by showing
their expansion. Erik presumably did it here on the assumption that
he was "among friends". (Ha! :-) The near-impossibility of
explaining the mess is simply an argument against saying anything
beyond "It works to omit the #' before (lambda...)"
That's something that isn't nearly impossible to explain.
Users are mostly always happier not knowing what macros expand into.
That doesn't always mean users would prefer to do without those macros.
> == Jamie (I mean, you're only saving two characters...)
It's not about saving two characters, it's about making a concession
to a cultural style that many people like.
When it came to a vote, the community was split on which was preferred.
So we offered both.
In my long experience with language design, I've found the absolute
hardest thing to get into a language is something that costs almost
nothing and whose purpose is merely to implement "tolerance" of one
person's preference or need in the presence of another person who has
no such need. For example, people will argue bitterly over whether an
operator like FORCE-OUTPUT should be needed because in many systems it
happens implicitly. "Fine," says the person proposing it, "can you
just implement it as (defun force-output (stream) nil) so I can call
it from time to time just in case it's needed and know it will work in
all systems?" "No," says the person who has not yet grasped the
concept of tolerance. "That would be more trouble than I can bear."
The LAMBDA discussion almost went the same way; some people didn't see
the point... because they sought a "technical reason". Saying just
that it would make some users happy and would cost the others nothing
was not enough. Ultimately, we found a technical reason: the user had
been forbidden to redefine symbols in the CL package, so if the system
didn't provide this utterly trivial definition, no user could. Had we
not found this technical reason, I doubt the people whose "convenience
and desire" was already coincidentally satisfied would have lifted a
finger to help those whose convenience and desire was not already
satisfied. Or so I claim. Fortunately, we didn't have to find out.
>>>>> "SDS" == SDS <···········@cctrading.com> writes:
SDS> I cannot find the corresponding place in CLtL2, so here is the question:
SDS> (funcall (lambda (x) (1+ x)) 3)
SDS> ACL3.0.2 for Windows -- signals an error.
SDS> CLISP -- returns 4.
SDS> (both grock the obviously correct
SDS> (funcall #'(lambda (x) (1+ x)) 3))
SDS> What is the correct behavior? (apparently CLISP behavior is correct, but
SDS> I would like to be sure).
I think CLISP is right, but why bother? #'(lambda ...) is always
correct, so why not use it?
Ray
SDS <···········@cctrading.com> writes:
> I cannot find the corresponding place in CLtL2, so here is the question:
> (funcall (lambda (x) (1+ x)) 3)
> ACL3.0.2 for Windows -- signals an error.
> CLISP -- returns 4.
> What is the correct behavior?
We've discussed at length on this ng why CLTL2 is not an appropriate
reference to ANSI CL. There were numerous changes to the language made
after the time when CLTL2 was written (both additions and retractions to
the working draft upon which CLTL2 was based). Look in the
Common Lisp HyperSpec (TM) for a better reference. It's at:
http://www.harlequin.com/books/HyperSpec/FrontMatter/index.html
From the CLHS, select the Symbol Index, select letter "L",
select "LAMBDA", and finally select "Macro".
If you want a copy of the CLHS for your local system, you can get info at
http://www.harlequin.com/books/HyperSpec/
In my opinion #' and #'(lambda ..) might
be better replaced by (function ..).
That is (function (x y) (list x y)) == #'(lambda (x y) (list x y))
and (function foo) == #'foo.
and (function foo (x y) (list x y)) defines a function named foo.
I mean, "lambda" creates a function, why not use "function"
to create a function?
If one like C's short cryptic names, call it "func" instead,
or really be terse, and use "f".
Hmm, I must say, #' really make it stand out when a functional arg is used,
and that is probably a good thing. I'll change my proposal,
and suggest #'(function (x y) ..) be supported
instead of #'(lambda (x y) ..), and futhermore #'(function foo)
would be the same as #'foo and (function foo).
Now we can have 4-5 ways to specify the same thing...
(position-if (f whitespacep) line)
(position-if (func whitespacep) line)
(position-if (function whitespace) line)
(position-if #'(function whitespacep) line)
(position-if #'whitespacep line)
(position-if 'whitespacep line)
(position-if (function (ch) (whitespacep ch)) line)
(position-if (lambda (ch) (whitespacep ch)) line)
(position-if #'(lambda (ch) (whitespacep ch)) line)
(position-if '(lambda (ch) (whitespacep ch)) line) ;; oops won't be compiled!
(position-if #'(function (ch) (whitespacep ch)) line)
OK, bring on the flames... ;)
-Kelly Murray ···@franz.com
In article <············@news2.franz.com>, Kelly Murray <···@franz.com> wrote:
>I mean, "lambda" creates a function, why not use "function"
>to create a function?
Historical reasons. Lisp's functional notation was based on some concepts
from Church's Lambda Calculus.
Also, there's a semantic difference between what LAMBDA does and what
FUNCTION does. LAMBDA is used to create functions, while FUNCTION is used
to look them up.
Finally, there would be ambiguity caused by the extension of function names
to include (SETF <place>): with your proposed notation, would (function
(setf xxx)) be equivalent to #'(setf xxx) or (lambda (setf xxx))?
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
Support the anti-spam movement; see <http://www.cauce.org/>
Please don't send technical questions directly to me, post them to newsgroups.
Barry Margolin <······@bbnplanet.com> writes:
> Also, there's a semantic difference between what LAMBDA does and what
> FUNCTION does. LAMBDA is used to create functions, while FUNCTION is
> used to look them up.
[Nota contradiction of what Barry says, just an embellishment.]
Actually, I see the difference as conceptual more than semantics.
The difference between (function (lambda...)) and (function foo)
is rather like the difference between a noun (e.g., "an aglet")
and a noun phrase ("one of those little things you find at the
end of a shoelace"). One refers "by name" and one refers "by
description". Whether or not the implementation recognizes
#'(lambda (x) (+ x 1))
as a synonym for #'1+ seems an issue of optimization issue unrelated
to the conceptual question which is, do these functions do different
things?
(defun foo (x) (mapcar #'1+ x))
(defun bar (x) (mapcar #'(lambda (x) (+ x 1)) x))
As with many things, Lisp emphasizes what happens, and deemphazies
how it happens.
Then again, some choose to say that FUNCTION's job is to refer to a
named entity in the function namespace and prefer to say that
while FOO is the name of a "named function", (LAMBDA (X) (+ X 2))
is the name of an "anonymous function". So you can use (lambda (x) ...)
where you can use a function name--in the car of a form, as an
"argument" to function, etc. Then again you find some rough edges.
e.g., You can do:
(defun foo (x) x)
but you can't do:
(defun (lambda (x) x) (y) y)
probably because we fear you'll try to do:
(defun (lambda (x) x) (y) (+ 1 y))
SETF gets a litte messy, too.
Kent Pitman wrote:
> rather like the difference between a noun (e.g., "an aglet")
> and a noun phrase ("one of those little things you find at the
> end of a shoelace").
An educational place, comp.lang.lisp...
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk Cambridge University, England.
In article <··········@tools.bbnplanet.com>, Barry Margolin <······@bbnplanet.com> writes:
>> In article <············@news2.franz.com>, Kelly Murray <···@franz.com> wrote:
>> >I mean, "lambda" creates a function, why not use "function"
>> >to create a function?
>>
>> Historical reasons. Lisp's functional notation was based on some concepts
>> from Church's Lambda Calculus.
>>
>> Also, there's a semantic difference between what LAMBDA does and what
>> FUNCTION does. LAMBDA is used to create functions, while FUNCTION is used
>> to look them up.
Right, but they are functionally both the same, they return function objects.
In my dialect, I also use (function foo (x y) ...) to define a named function,
That is, the function operator is used to define, create, and reference functions.
Makes sense to me..
Interestingly, one could extend the notion of closures, to include named closures.
I believe the Lisp Machine had such a notion, a named-lambda?
So (function foo (x) (foo x)) would be the same
as (lambda (x) (foo x)), except that within the body of the function,
the function value of 'foo references itself, like a flet or labels.
Thus, a closure could get a pointer to itself and call (or pass) itself recursively.
I personally think this would just complicate the compiler, but it is
interesting.
So, (function foo) --> returns function value of foo
So, (function foo (x y) ...) --> defines and returns function value of foo
So, (function (x y) ...) --> defines and returns an anonymous function
>>
>> Finally, there would be ambiguity caused by the extension of function names
>> to include (SETF <place>): with your proposed notation, would (function
>> (setf xxx)) be equivalent to #'(setf xxx) or (lambda (setf xxx))?
>>
The same holds true for non-setf, e.g. (function (x y)) could mean
#'(lambda (x y)) or #'(x y), even though only setf has a valid meaning.
One could extend CL to include effective method specifiers too,
(which may or maynot be a good idea),
such as #'(method foo ((x string))) to return the effective methods
But it can be defined without ambiguity, #'function with one argument does a lookup,
so (function (setf xxx)) is #'(setf xxx).
While it is true that (lambda (setf xxx)) is a syntactically a
valid CL function without a body, I see no reason why it must be so.
It is pretty trivial to use (lambda (setf xxx) nil) instead.
Making (defun foo (x y)) invalid as well suits me just fine.
Of course, this would differ from CL.
-Kelly Murray ···@franz.com
SDS <···········@cctrading.com> wrote in article
<·············@WINTERMUTE.eagle>...
> I cannot find the corresponding place in CLtL2, so here is the question:
>
> (funcall (lambda (x) (1+ x)) 3)
>
> ACL3.0.2 for Windows -- signals an error.
> CLISP -- returns 4.
>
> (both grock the obviously correct
> (funcall #'(lambda (x) (1+ x)) 3))
>
> What is the correct behavior? (apparently CLISP behavior is correct, but
> I would like to be sure).
>
> --
> Sam Steingold
>
Ok I'm still learning lisp, but why is the later incorrect? When I try it
out in a clisp beta for Win32 I get:
Microsoft(R) Windows NT(TM)
(C) Copyright 1985-1996 Microsoft Corp.
C:\>d:
D:\>cd clisp
D:\clisp>clisp
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I I I I I I I 8 8 8 8 8 8
I I I I I I I 8 8 8 ooooo 8oooo
I \ `+' / I 8 8 8 8 8
\ `-+-' / 8 o 8 8 o 8 8
`-__|__-' ooooo 8oooooo ooo8ooo ooooo 8
|
------+------ Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
> (funcall (lambda (x) (1+ x)) 3)
4
> (funcall #'(lambda (x) (1+ x)) 3)
4
>
Cheers
Barry
* Barry Perryman
| Ok I'm still learning lisp, but why is the later incorrect?
sigh. #'(lambda ...) is not _incorrect_. (where did you get that idea?)
the following three forms have _identical_ semantics in contexts where a
function object is expected. some Lisp programmers think one of them is
better than the others. which one they think is better varies according to
the personal taste of each one. I prefer the former.
(lambda (x) (+ x x))
#'(lambda (x) (+ x x))
(function (lambda (x) (+ x x)))
#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".
see http://www.naggum.no/emacs/ for Emacs-20-related material.
* Joerg Hoehle
| Emphasize this is only valid in ANSI CL which defines lambda as a
| macro, but not in CLtL1 or CLtL2 Lisps. That might explain the
| difference between Allegro and CLISP (a compile-only
| vs. interpreter+compiler present inplementation might do as well).
Allegro comes in to flavors: Windows and Unix (also available for NT).
Allegro for Windows is an ancient Lisp, mostly CLtL1 with CLOS and a
Windows-specific interface builder, and is compile-only as you say.
Allegro for Unix is a modern Lisp, almost completely ANSI-conformant, and
has both an interpreter and a compiler. they differ greatly in what they
implement, in particular: one should not impute Windows limitations to
Unix. to wit, I'm greatly impressed with the Unix version, and equally
unimpressed with the Windows version.
| The correct way of course was
| (defvar *df* `(,#'(lambda () (do1)) ,#'(lambda (a) (do2 a))))
| without any coercion (you don't need to compile at run-time here).
hm. I'd suggest optimizing for less syntactic hair:
(defvar *df* (list (lambda () (do1)) (lambda (a) (do2 a))))
of course, with (optimize (hair 3)), we could always write
(defvar *df '(#.#'(lambda () (do1)) #.#'(lambda (a) (do2 a))))
and force people to understand how this all works, but ... maybe not.
#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".
see http://www.naggum.no/emacs/ for Emacs-20-related material.
Erik Naggum <······@naggum.no> wrote:
>of course, with (optimize (hair 3)), we could always write
>
> (defvar *df '(#.#'(lambda () (do1)) #.#'(lambda (a) (do2 a))))
Won't work if you want to run it through the file compiler because
functions are not externalizable. Some implementations do, as an
extension, externalize non-closure functions, but they don't have to.
LispWorks, for example, doesn't. Yet another reason always to use
(OPTIMIZE (HAIR 0)).
--David Gadbois
Kent M Pitman <······@world.std.com> wrote:
+---------------
| In my long experience with language design, I've found the absolute
| hardest thing to get into a language is something that costs almost
| nothing and whose purpose is merely to implement "tolerance" of one
| person's preference or need in the presence of another person who has
| no such need.
+---------------
In the Internet protocol arena, this principle is codified in the maxim,
"Be strict in what you emit, and liberal in what you accept."
It comes up time & again...
-Rob
-----
Rob Warnock, 7L-551 ····@sgi.com http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673 [New area code!]
2011 N. Shoreline Blvd. FAX: 650-933-4392
Mountain View, CA 94043 PP-ASEL-IA
In article <················@netscape.com>,
Jamie Zawinski <···@netscape.com> wrote:
>I think the near-impossibility of explaining that mess to a novice is
>the best of all possible arguments against defining lambda as a macro.
If CL left out everything that was difficult to explain to novices, we'd
have Scheme. :(
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
Support the anti-spam movement; see <http://www.cauce.org/>
Please don't send technical questions directly to me, post them to newsgroups.
Barry Margolin <······@bbnplanet.com> writes:
> If CL left out everything that was difficult to explain to novices, we'd
> have Scheme. :(
Or vice versa.
(I was going to say more, but it would have started a holy war.
"This remark deliberately left cryptic.")
Lawrence Troxler wrote:
> : > (defmacro lambda (&whole form &rest bvl-decls-and-body)
> : > (declare (ignore bvl-decls-and-body))
> : > `#',form)
...
> Just jumping in here - this means, then, that lambda is actually
> equivalent to #', in the same way quote is equivalent to '?
No, you misread. FORM in that definition is bound to the whole
LAMBDA form, so it says that (lambda (x) x) is equivalent to
#'(lambda (x) x).
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk Cambridge University, England.
Aaron Leung wrote:
> ... Here is the classic currying example (paraphrased from Ansi Common Lisp by
>
> Graham)
>
> (defun (make-adder n)
> #'(lambda (x)
> (+ x n)))
> ...
Sorry, there's a mistake. The above should be
(defun make-adder (n)
#'(lambda (x)
(+ x n)))
Have to admit, I'm more used to Scheme than Lisp....
-Aaron