Lambda functions
Aisha Fenton
Hi a real newbi question here.
I want to create a lambda function whose declaration is based on the result
of evaluating a function.
So I am doing something like
---
(setf x #'(lambda (x) (create-random-function))
---
The above produces a lambda function which calls (create-random-function).
What I want though is a lambda function that was declared with the returned
value of (create-random-function)
eg.
---
(setf x #'(lambda (x) (first x)) --> where (first x) was returned from
(create-random-function)
---
Is there anyway to get lambda to evaluate a function within it's
declaration?
Thanks heaps,
Aisha
ps. I am trying to write a genetic program. My thought was the
(create-function) will randomly create an individual program to solve the
problem. I then would bind each generated function to a population list.
Christopher J. Vogt
>
> Hi a real newbi question here.
> I want to create a lambda function whose declaration is based on the result
> of evaluating a function.
>
> So I am doing something like
>
> ---
> (setf x #'(lambda (x) (create-random-function))
> ---
>
> The above produces a lambda function which calls (create-random-function).
> What I want though is a lambda function that was declared with the returned
> value of (create-random-function)
>
> eg.
> ---
> (setf x #'(lambda (x) (first x)) --> where (first x) was returned from
> (create-random-function)
> ---
>
> Is there anyway to get lambda to evaluate a function within it's
> declaration?
Here are three ways, IMHO the first way is the best style. Read the
documentation on macros and backqoute syntax.
1. Define a macro and then use it:
(defmacro make-lambda-evaled-body (arg body)
`#'(lambda ,arg ,(eval body)))
(setf x (make-lambda-evaled-body (x) (create-random-function)))
2. Use the backquote syntax:
(setf x `#'(lambda (x) ,(create-random-function)))
3. Similar to number two above, but without the backquote syntax:
(setf x (coerce (list 'lambda '(x) (create-random-function)) 'function))
Coby Beck
"Aisha Fenton" <te...@xtra.co.nz> wrote in message
news:EVGq7.3645$4j.5...@news.xtra.co.nz...
>
> Hi a real newbi question here.
> I want to create a lambda function whose declaration is based on the result
> of evaluating a function.
>
> So I am doing something like
>
> ---
> (setf x #'(lambda (x) (create-random-function))
> ---
>
> The above produces a lambda function which calls (create-random-function).
> What I want though is a lambda function that was declared with the returned
> value of (create-random-function)
>
Have a look at this listener session:
CL-USER 12 > (defun create-random-function ()
`(,(nth (random 2) '(1+ 1-)) arg))
CREATE-RANDOM-FUNCTION
CL-USER 13 > (create-random-function)
(1- ARG)
CL-USER 14 > (create-random-function)
(1+ ARG)
CL-USER 15 > (setf func (compile nil `(lambda (arg)
,(create-random-function))))
#<function 9 2040508A>
CL-USER 16 > (funcall func 58)
57
CL-USER 17 > (funcall func 5)
4
The combination of a backquote and a comma causes what the comma preceeds to be
evaluated before being put into the quoted structure that is then handed to
compile.
That's how I do things like that anyway....
Coby
--
(remove #\space "coby . beck @ opentechgroup . com")
Tim Bradshaw
> 1. Define a macro and then use it:
> (defmacro make-lambda-evaled-body (arg body)
> `#'(lambda ,arg ,(eval body)))
I rather like this:
(defun make-function-evaluating (x)
;; X is some Lisp source. The function will have no arguments.
(compile nil `(lambda () ,x)))
So
(funcall (make-function-evaluating '(print "Hello world")))
Or in the original case:
(funcall (make-function-evaluating (create-random-function)))
--tim
Frode Vatvedt Fjeld
> I want to create a lambda function whose declaration is based on the
> result of evaluating a function.
You need to know or specify at what time in the read-compile-evaluate
cycle you want the computation of your function to happen.
1. At read-time: It will look as the return value of your function was
inserted in the file (or typed in), for example:
(defun generated-function (x) . #.(create-random-function))
If create-random-function returns ((print x) (* x 2)), it would be
just as if the file looked like
(defun generated-function (x) (print x) (* x 2))
This technique can be used to insert any kind of data, not just
function bodies.
2. At compile-time: Macros is the simplest way of tapping into the
compiler. For example:
(defmacro define-random-function (name)
`(defun ,name (x) . ,(create-random-function)))
Now, whenever the compiler sees (define-random-function foo), it will be
like it sees (defun foo (x) (print x) (* x 2)), if that's what
create-random-function returns.
3. At evaluation/run-time: I don't know anything about "genetic
programs", but I'd guess this is what you want. Now you must decide if
you want an interpreted or compiled function. To get a compiled
function object, call the function COMPILE:
(compile nil `(lambda (x) . ,(create-random-function)))
If you're not familiar with the backquote syntax, the same thing is
(compile nil (list* 'lambda '(x) (create-random-function)))
Or, to get an interpreted function:
(coerce (list* 'lambda '(x) (create-random-function)) 'function)
To put the result in a variable x, you obviously do
(setf x (compile ..))
or
(setf x (coerce ..))
--
Frode Vatvedt Fjeld
Kalle Olavi Niemitalo
> 1. Define a macro and then use it:
>
> (defmacro make-lambda-evaled-body (arg body)
> `#'(lambda ,arg ,(eval body)))
>
> (setf x (make-lambda-evaled-body (x) (create-random-function)))
Doesn't this call CREATE-RANDOM-FUNCTION at compile time, when the
macro is expanded? That won't work in all situations.
(flet ((create-random-function () '(+ 2 2)))
(make-lambda-evaled-body () (create-random-function)))
> 2. Use the backquote syntax:
>
> (setf x `#'(lambda (x) ,(create-random-function)))
This will only give you a list that contains (function (lambda ...)).
It is not yet a function, although evaluating it results in a
function.
> 3. Similar to number two above, but without the backquote syntax:
>
> (setf x (coerce (list 'lambda '(x) (create-random-function)) 'function))
Now this could actually work.
The same with backquote:
(setf x (coerce `(lambda (x) ,(create-random-function)) 'function))
Jochen Schmidt
> {2001-09-21 15:10} "Aisha Fenton":
>
>> I want to create a lambda function whose declaration is
>> based on the result of evaluating a function.
>
> I would prefer to use the term "lambda expression" and
> "definition" here.
>
>> (setf x #'(lambda (x) (create-random-function))
>> Is there anyway to get lambda to evaluate a function within
>> it's declaration?
>
> Build the expression and then evaluate it.
>
> (setq expr (list 'lambda '(x) (create-random-function))
> (setq x expr)
>
> But beware! I have not been writing LISP for years and have no
> LISP system to try this code, so it surely will contain errors.
> However, possibly one can get the idea.
You will have to evaluate the constructed expression by e. g. COMPILE
or EVAL.
Like
(setq x (compile nil expr))
ciao,
Jochen
Barry Margolin
Anette Stegmann <anette_s...@gmx.de> wrote:
>BTW: What does the Newsgroup think of the ISO/IEC 13816:1997
>ISLISP Language versus CL? Sorry, this must be an FAQ, so any
>hints to web sites or previous threads are appreciated.
There was a short thread about ISLISP a few days ago. Other than that, it
hasn't received much discussion in the group.
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Jochen Schmidt
> {2001-09-21 17:47} "Jochen Schmidt":
>
>>> (setq expr (list 'lambda '(x) (create-random-function))
>>> (setq x expr)
>>You will have to evaluate the constructed expression by e. g.
>>COMPILE or EVAL.
>
> In the meantime I was able to test this. I have been successfully
> trying to get access to an ISO LISP interpreter and here is a
> session transcript (some output deleted):
>
> ? (defglobal create-random-function)
> ? (defglobal expr)
>
> ? (setq create-random-function '(lambda () '(+ 9 x)))
> ? (setq expr (list 'lambda '(x) (funcall create-random-function)))
>
> ? (funcall expr 12)
> 21
>
> So it works as expected. No COMPILE or EVAL. The only thing I
> did not foresee was the need to use 'defglobal' and 'funcall'
> with this LISP dialect.
CL-USER 1 > (setq create-random-function '(lambda () '(+ 9 x)))
(LAMBDA NIL (QUOTE (+ 9 X)))
CL-USER 2 > (setq expr (list 'lambda '(x) (funcall create-random-function)))
Error: Argument to apply/funcall is not a function (LAMBDA NIL (QUOTE + 9
X))).
CL-USER 1 > (setq create-random-function #'(lambda () '(+ 9 x)))
#'(LAMBDA NIL (QUOTE (+ 9 X)))
CL-USER 2 > (setq expr (list 'lambda '(x) (funcall create-random-function)))
(LAMBDA (X) (+ 9 X))
CL-USER 3> (funcall expr 12)
Error: Argument to apply/funcall is not a function (LAMBDA (X) (+ 9 X)).
CL-USER 4> (funcall (compile nil expr) 12)
21
ciao,
Jochen Schmidt
Kent M Pitman
> {2001-09-21 17:47} "Jochen Schmidt":
>
> >> (setq expr (list 'lambda '(x) (create-random-function))
> >> (setq x expr)
> >You will have to evaluate the constructed expression by e. g.
> >COMPILE or EVAL.
>
> In the meantime I was able to test this. I have been successfully
> trying to get access to an ISO LISP interpreter and here is a
> session transcript (some output deleted):
>
> ? (defglobal create-random-function)
> ? (defglobal expr)
>
> ? (setq create-random-function '(lambda () '(+ 9 x)))
> ? (setq expr (list 'lambda '(x) (funcall create-random-function)))
>
> ? (funcall expr 12)
> 21
>
> So it works as expected. No COMPILE or EVAL. The only thing I
> did not foresee was the need to use 'defglobal' and 'funcall'
> with this LISP dialect.
I don't see anything in the ISO ISLISP spec that suggests that a lambda
expression is a function. Unless you can find a specific passage that
contradicts my belief, I'm pretty sure an implementation is buggy if it
lets you funcall a list whose car is LAMBDA.
> BTW: What does the Newsgroup think of the ISO/IEC 13816:1997
> ISLISP Language versus CL? Sorry, this must be an FAQ, so any
> hints to web sites or previous threads are appreciated.
It has been largely ignored by most of the Lisp community.
I don't think there's anything technically wrong with it, but it's
very small by itself and as such not suitable for commercial work.
That doesn't mean you can't write a commercial quality ISLISP, just
that you have to extend it a lot in order to get to the level of
commercial interest. Although there are some ISLISP-compatible Lisps,
most are academic in nature. The only one I can think of that's not
(i.e., that's a serious attempt to be commercial quality)
is from ILog, and I'm not sure they still sell it.
Kaz Kylheku
Stegmann wrote:
>{2001-09-22 23:48} "Kent M Pitman":
>>I don't see anything in the ISO ISLISP spec that suggests
>>that a lambda expression is a function. Unless you can find
>>a specific passage that contradicts my belief, I'm pretty
>>sure an implementation is buggy if it lets you funcall a list
>>whose car is LAMBDA.
>
>between 195X and 197X. Has something changed in the meantime?
>
>In my understanding a lamda expression is a way to notate a
>function.
>
>I am used to code like the following, IIRC:
>
> > ((lambda (x) (+ x x))2)
> 4
This is fine in Common Lisp.
> > (setq f (lambda (x)(+ x x)))
> > (f 4)
> 8
This won't work, you have to use
(funcall f 4)
what is going on behind the scenes is that lambda is actually a macro,
which epxands (lambda (x)(+ x x)) to (function (lambda (x)(+ x x)))
This function thing, in turn, is a special form which takes a lambda list,
and constructs a closure. (function X) is abbreviated #'X which
you can use directly:
(setq f #'(lambda (x)(+ x x)))
This shows explicitly that a closure is being made from a lambda list.
Now in the first position of an evaluated list, you must be a symbol
that ahs a function binding, or otherwise be a function object.
of a function, or an object that c; the lambda list is treated as a
function object when it appears in the first position. But (f 4) is an
error if f has no binding to a function. In this case, it has a variable
binding to a closure, requiring an operator like apply or funcall.
A Common Lisp symbol has independent function and value bindings,
so you can do
(defun f () (format t "Hello~%"))
(defvar f 3)
f
--> 3
(f)
Hello
--> NIL
Another thing: setq is a low level assignment function for a symbol.
In Common Lisp, there is an ``intelligent'' macro called setf, which
recognizes a number of different kinds ``places'' where a value can
be stored and generates the appropriate assignment. So it's often
better to just use setf.
(setf x 3)
(setf (aref arr 3) 4) ; assuming arr is an array
(setf list (cons 'a 'b))
list
--> (A . B)
(setf (car list) 'c)
list
--> (C . B)
(setf (first list) nil)
You can see how setf can assign to different places, like the car of
a cons cell, an array element, a symbol's value binding and so on.
Without setf, you'd have to use a dedicated operator for setting
the car, namely (rplaca list 'c) and setq for the symbol and so on.
I don't think there is a standard low-level way to write to an
array element; you have to use setf.
Erik Naggum
> I don't see anything in the ISO ISLISP spec that suggests that a lambda
> expression is a function. Unless you can find a specific passage that
> contradicts my belief, I'm pretty sure an implementation is buggy if it
> lets you funcall a list whose car is LAMBDA.
* Anette Stegmann
> That surprises me. I only know old LISP dialects from the time between
> 195X and 197X. Has something changed in the meantime?
Your reading of what Kent wrote lacks the precision he put into it.
> In my understanding a lamda expression is a way to notate a function.
>
> I am used to code like the following, IIRC:
>
> > ((lambda (x) (+ x x))2)
> 4
>
> > (setq f (lambda (x)(+ x x)))
> > (f 4)
> 8
If you really need exmples, the following form is what Kent was talking
about
(funcall '(lambda (x) (+ x x)) 3)
None of your examples are funcalling a _list_, but are instead funcalling
the value of an evaluated expression. Incidentally, the latter of your
two examples presupposes a Lisp where functions and variables share the
same value space. That is appropriate over in comp.lang.scheme. It is
thus either (funcall f 4) or (setf (fdefinition 'f) ...) in a real Lisp.
///
--
Why did that stupid George W. Bush turn to Christian fundamentalism to
fight Islamic fundamentalism? Why use terms like "crusade", which only
invokes fear of a repetition of that disgraceful period of Christianity
with its _sustained_ terrorist attacks on Islam? He is _such_ an idiot.
Kent M Pitman
> {2001-09-22 23:48} "Kent M Pitman":
>
> >I don't see anything in the ISO ISLISP spec that suggests
> >that a lambda expression is a function. Unless you can find
> >a specific passage that contradicts my belief, I'm pretty
> >sure an implementation is buggy if it lets you funcall a list
> >whose car is LAMBDA.
>
> That surprises me. I only know old LISP dialects from the time
> between 195X and 197X. Has something changed in the meantime?
Yes.
It used to be in original Common Lisp (1984) and some dialects before
that (funcall '(lambda (x) (+ x 1)) 1) => 2
Now this is an error, in both ANSI Common Lisp and ISO ISLISP.
You must somehow promote the list expression (lambda (x) (+ x 1)) to a
function before it can be funcalled. In ANSI Common Lisp, this is done
by EVAL or COMPILE. e.g.,
(funcall (eval '(lambda (x) (+ x 1))) 1)
or
(eval (list '(lambda (x) (+ x 1)) 1))
> In my understanding a lamda expression is a way to notate a
> function.
This is still true.
> I am used to code like the following, IIRC:
>
> > ((lambda (x) (+ x x))2)
> 4
Here you have used lambda as a form. There is an implicit call to EVAL
at the read-eval-print loop which is what promotes the form you type to
something executable. But in previous postings, you
refered to code that wants to construct a lambda, as in
(setq expr (list 'lambda '(x) (funcall create-random-function)))
(funcall expr ...)
The value of expr is a list. You cannot simply funcall it.
> > (setq f (lambda (x)(+ x x)))
> > (f 4)
> 8
>
> This looks very simple to me and I always regarded lamda-
> expressions-as-functions as being the heart of LISP.
They are. But the ability to construct lambda expressions and promote
them to callable code requires EVAL or COMPILE. EVAL is also at the
heart of LISP.
> Is this wrong today? Why? (Or does my memory not serve me and
> this was never possible?)
You're confusing yourself by not reading the post that I replied to and
the text I enclosed and instead inventing new examples that are not what
I replied to and which are materially different in nature.
Thomas F. Burdick
> You must somehow promote the list expression (lambda (x) (+ x 1)) to a
> function before it can be funcalled. In ANSI Common Lisp, this is done
> by EVAL or COMPILE. e.g.,
>
> (funcall (eval '(lambda (x) (+ x 1))) 1)
>
> or
>
> (eval (list '(lambda (x) (+ x 1)) 1))
EVAL, COMPILE, or COERCE. You can also do:
(funcall (coerce '(lambda (x) (+ x 1)) 'function) 1)
Unless I'm missing something, this doesn't involve EVAL. In fact, I'd
guess it would probably be the other way around (EVAL invokes whatever
machinery COERCE uses).
Kent M Pitman
Right. I didn't say "only". Incidentally, COMPILE-FILE+LOAD has that
power, too.
It's all the same. The ponit is that both EVAL and COMPILE have the
same power--they both have to understand the full semantics of the
language. The issue with EVAL or COMPILE is that using it potentially
increases the size of a deliverable since there's a lot of baggage
involved in that understanding. We took the power away from FUNCALL
since it's used too often in ways that are opaque to the compiler; we
figured it was safer to leave the power only on COERCE. Even then I'm
not so sure.
Kent M Pitman
> {2001-09-23 01:20} "Kaz Kylheku":
>
> >what is going on behind the scenes is that lambda is actually
> >a macro, which epxands (lambda (x)(+ x x)) to (function
> >(lambda (x)(+ x x)))
>
> The second lambda must be different from the first one, because
> otherwise there would be an infinite macro recursion. Therefore
> it is confusing to use the same name for both.
Yes, (function ...) is a special form. It does not evaluate its argument,
so no macro expansion occurs.
> What if I do not want to have a closure? (which I understand to
> be something like the lambda with x replace by a generated
> unique symbol). Is there a way to invoke the non-macro lambda?
No, I think your understanding is wrong. A closure is simply a lambda
expression that uses a variable free and that does not intend to take
the innermost dynamic binding of the variable. In Common Lisp, there is
no other possible interpretation than a dynamic reference.
> >This shows explicitly that a closure is being made from a
> >lambda list.
>
> Well, IIRC in the "old LISPs" there where no closures.
Right.
> I still find it conceptually simple to see things this way:
>
> A name is naming an expression and on evaluation is replaced by
> its value.
>
> ((lambda (x)(+ x x))2)
>
> when I use (setq f (lambda (x)(+ x x))) then I am naming the
> lambda list by the name of "f" and so in "(f 2)" the name f then
> should be replaced by its value "(lambda (x)(+ x x))" giving
> "((lambda (x)(+ x x))2)" what then can be evaluated.
Common Lisp uses two namespaces. in (f a b c), f is in the function
namespace and a, b, and c are in the variable namespace. You cannot
setq f in order to assign the function namespace; indeed, you can only
bind names in the function namespace--there is no imperative assignment
of the function namespace, except globally, which is done through
(setf (symbol-function 'f) ...)
> >Now in the first position of an evaluated list, you must be a
> >symbol that ahs a function binding, or otherwise be a
> >function object.
See the Common Lisp HyperSpec's definitions of this. It's too painful
to enumerate here in full, but approximately a list must have a car
that is a symbol naming an operator (function, macro, or special operator)
or else must be a list that is a lambda expression.
> Possibly you meant to say "list to be evaluated"?
No. A lambda expression is treated specially in the car of the form,
but arbitrary forms are not allowed. You cannot write ((f x) y)
in Common Lisp. You must write (funcall (f x) y).
> >position. But (f 4) is an error if f has no binding to a
> >function.
>
> I see. It is because CL has multiple values for a name depending
We use the term "namespaces", but yes.
> on the context. I am not sure if I like this, because it is
> conceptually simple to have a name be just a name for /one/
> value.
This has been discussed at length and was carefully reviewed in the
design process.
Btw, the human brain commonly associates different meanings with names
depending on context. You've done it probably dozens, maybe hundreds,
of times while reading this message. What you think is simpler may not
be what IS simpler. Some think simple is the thing closest to a blank
sheet of paper; I think that you think with a brain, not a blank sheet of
paper, and that simplest is best measured by being closest to how you
routinely think.
> This is as if, for example and comparision, in a conventional
> language every name could have a number and a string value, so:
>
> a = 2
> a = "hello"
> printnum a
> printstr a
> printnum a
>
> would print "2hello2". The first impression I would have is that
> this makes things more complicated than necessary.
No, it is like "This" has a certain meaning as a preposition and a
different meaning as an adjective. It is like how "is" has a certain
meaning in "john is cold" and a different meaning in "john is my
father". It is like how "as" has a different meaning in "As I went to
work..." than in "I am as tall as Fred". It is like how "if" has a
certain meaning in "if x then y" and a different meaning in "as if".
It is like how "for" has a different meaning in "This is for you" than
in "For the next 2 hours, wait here." It is like how "example" has a
different meaning in "Give me an example." and "I'll make an example
of you." It is like how "and" has a different meaning in "Bill and
Joe are here." than in "Give me some food and I'll feel less hungry."
... I could go on and on. By the way, these examples are chosen to
illustrate the ambiguity in your prior quoted segment, which begins
"This is as if, for example..." Every single word there has multiple
meanings, yet you are perfectly comfortable with the ambiguity.
CL is not ambiguous like natural language is, but it still takes good
advantage of your ability to resolve multiple contexts.
> With (defun x () ...) and (defvar x 3) the expression (x x)
> looks like the application of a function to itself, but if I got
> you and right, here x is applied to 3.
It only looks like x applied to itself if you ignore the meaning of
context. The same argument would cause you to fail to understand the
sentence "Go down two blocks, then turn right. But make sure you take
the right right! If there's still a right left, you left out a right
and there's still one left."
And please don't tell me it's only English that does this. I tried to
learn German at one point and there are plenty of situations where the
same pronoun means different gender or case depending on context.
In Spanish, the sentence "Como como como." (I eat how I eat) might
sound funny but would not cause a the slightest confusion to the hearer.
> I actually dislike it that this apparent self-application is not
> happening, because here the "notation lies" in my eyes.
Heh. No. It's your brain that lies to you, telling you that your
eyes will lie once you get used to it. But the fact is that what lies
is your attempt to apply semantics without knowledge of the rules.
That works in no language. And once you know the rules, your eyes will
be as faithful to you this way as any other.
> I dislike it that it is possible that the same name is naming two
> totally different things in this expression (x x).
>
> When, as I assume, after (defvar x 3) the second x in (x x) is
> effectively replaced by 3, how would I then write a self-
> application, i.e., an application of a function to itself?
(funcall f f)
Kaz Kylheku
Stegmann wrote:
>{2001-09-23 01:20} "Kaz Kylheku":
>
>>a macro, which epxands (lambda (x)(+ x x)) to (function
>>(lambda (x)(+ x x)))
>
>otherwise there would be an infinite macro recursion.
In the second form, the lambda list is an argument to the function
special form. Its evaluation is suppressed in that context; it is in
the hands of that form, which receives it unevaluated.
>Therefore
>it is confusing to use the same name for both.
It's only confusing if you know about it. If you don't konw about
the lambda macro, then it just looks like ``the right thing'' happens.
You forget the #' but you get a closure anyway.
>What if I do not want to have a closure? (which I understand to
>be something like the lambda with x replace by a generated
>unique symbol). Is there a way to invoke the non-macro lambda?
The non-macro lambda doesn't exist as a defined entity. The non-macro
lambda is just any list with the symbol 'lambda in the first position. Such
a list is recognized by by (function), and in the first position of
a list.
If you don't want to evaluate a list, then you have to quote it, or
otherwise use it in a context where you know the evaluation is supressed.
>>This shows explicitly that a closure is being made from a
>>lambda list.
>
>Well, IIRC in the "old LISPs" there where no closures.
>
>I still find it conceptually simple to see things this way:
>
>A name is naming an expression and on evaluation is replaced by
>its value.
This breaks down due to Common Lisp's position-sensitive evaluation
rules. In the expression
(dummy x)
x is treated exactly as you say. But in
(x dummy)
x is expected to name a function. Evaluation of the first position of
a list is different.
> ((lambda (x)(+ x x))2)
>
>when I use (setq f (lambda (x)(+ x x))) then I am naming the
>lambda list by the name of "f" and so in "(f 2)" the name f then
>should be replaced by its value "(lambda (x)(+ x x))" giving
>"((lambda (x)(+ x x))2)" what then can be evaluated.
>
>>Now in the first position of an evaluated list, you must be a
>>symbol that ahs a function binding, or otherwise be a
>>function object.
>
>Possibly you meant to say "list to be evaluated"?
No. It's not true that any arbitrary list will be evaluated in
the first position of a list. Scheme does it that way, but not CL.
>>position. But (f 4) is an error if f has no binding to a
>>function.
>
>I see. It is because CL has multiple values for a name depending
>on the context. I am not sure if I like this, because it is
>conceptually simple to have a name be just a name for /one/
>value.
>
>This is as if, for example and comparision, in a conventional
>language every name could have a number and a string value, so:
>
> a = 2
> a = "hello"
> printnum a
> printstr a
> printnum a
>
>would print "2hello2". The first impression I would have is that
>this makes things more complicated than necessary.
I'd be uncomfortable with that. But somehow, the division between
code and data makes it okay to have these separate bindings.
And of course if you are treating functions as data, then you will
use the value binding anyway, as in
(setf x #'(lambda ...))
only certain constructs affect the function binding of a symbol,
like defmacro, defun, labels, flet.
>With (defun x () ...) and (defvar x 3) the expression (x x)
>looks like the application of a function to itself, but if I got
>you and right, here x is applied to 3.
Yes, the function x is applied to 3.
>I actually dislike it that this apparent self-application is not
>happening, because here the "notation lies" in my eyes. I
>dislike it that it is possible that the same name is naming two
>totally different things in this expression (x x).
That's right. But of course, nobody twists your arm into overloading
the symbol x with these meanings. If you haven't done so, then
(x x) is simply an error, either because x doesn't have a function
value, or because it doesn't have a value.
>When, as I assume, after (defvar x 3) the second x in (x x) is
>effectively replaced by 3, how would I then write a self-
>application, i.e., an application of a function to itself?
(x (function x))
or, using the shorthand discussed earlier:
(x #'x)
(function x) accesses x's function value binding and produces a function
object representing that function, similar to a closure.
Thomas F. Burdick
> > When, as I assume, after (defvar x 3) the second x in (x x) is
> > effectively replaced by 3, how would I then write a self-
> > application, i.e., an application of a function to itself?
(defvar f (lambda (f) (do-something-with f)))
(funcall f f)
(defun f (f) (do-something-with f))
(f #'f)
Erik Naggum
> what is going on behind the scenes is that lambda is actually
> a macro, which epxands (lambda (x)(+ x x)) to (function
> (lambda (x)(+ x x)))
* Anette Stegmann
> The second lambda must be different from the first one, because
> otherwise there would be an infinite macro recursion. Therefore
> it is confusing to use the same name for both.
function is a special form. It does not evaluate its argument. (This is
_really_ basic stuff, and behooves you to access reference material to
get simple answers like this instead of wasting everybody else's time
explaining things like this to you.)
> What if I do not want to have a closure? (which I understand to be
> something like the lambda with x replace by a generated unique symbol).
Huh? A closure captures the binding of the free variables in the lambda
expression. Various forms of renaming are employed lambda calculus, but
that is a way to describe argument passing formally, not something we
actually do in the code.
> Well, IIRC in the "old LISPs" there where no closures.
Yes, because there were no lexical variables.
> I still find it conceptually simple to see things this way:
It would be massively _more_ conceptually simple for you if you could
become willing to wrap your head around the way these things are actually
done in the language under study. Nobody cares what you find simple or
not, really, but the language is there and does what it does, and you
should care to see its simplicity instead of trying to impose on it the
one that you bring with you. If you cannot hack the language as it is,
some other language may suit you better if you really insist on giving
_your_ conceptual simplicity higher precedence than exploiting and
employing the vast resources made available by people within the existing
framework. This has much to do with the personal attitude problem I
label "ignorant arrogance", and it occurs with people at every skill
level, even people who _supposedly_ know the language well, but still
insist that if/when/unles are braindamaged because they break with his
pre-existing view or the world and that view is of _course_ much more
important than everybody else's, at all costs. Understanding how
something came to be and why other people think it is great is part of
that humility that comes with sufficient intelligence to recognize that
and when others are way smarter than you are. Failure to recognize this
causes you to behave stupidly and that is tremendously annoying because
those who fail to recognize it are also unlikely to grasp when to let go
of their preconceptions.
> A name is naming an expression and on evaluation is replaced by its value.
>
> ((lambda (x)(+ x x))2)
>
> when I use (setq f (lambda (x)(+ x x))) then I am naming the lambda list
> by the name of "f" and so in "(f 2)" the name f then should be replaced
> by its value "(lambda (x)(+ x x))" giving "((lambda (x)(+ x x))2)" what
> then can be evaluated.
You may find this conceptually simple, but real Lisps decided long ago
that the human language tendency to have verbs and nouns draw from the
same lexicon, but mean different things according to context actually
works tremendously well. Lisp was developed in the English language
community. Algol and several other languages that fight against this
tendency in human languages were developed in non-English communities.
If you do not like the ability to spell a verb and a noun the same way,
take it up with English or German, not with languages that evolved with
designers and users speaking the respective languages.
> It is because CL has multiple values for a name depending on the
> context. I am not sure if I like this, because it is conceptually simple
> to have a name be just a name for /one/ value.
Please accept that some of us, native and almost-native English speakers,
cannot fathom how other languages can be useful when they have to invent
new words just because a word of a different type is spelled the same
way. E.g., my native language is Norwegian, essentially close to German,
which has the annoying tendency that the noun and verb are completely
different, but I have been a bilingual American-English speaker since
about age 6, and to me the ability to name verbs and nouns the same is a
conceptual simplicity that far outweighs the _artificial_ simplicity of
associating only one value or meaning with a word. Matter of fact, I
appreciate the fact that most languages affords numerous interpretations
of each word, and especially enjoy the literal and the figurative meaning
that we can trace back to the classic languages.
> This is as if, for example and comparision, in a conventional language
> every name could have a number and a string value, so:
>
> a = 2
> a = "hello"
> printnum a
> printstr a
> printnum a
>
> would print "2hello2". The first impression I would have is that this
> makes things more complicated than necessary.
I find it utterly amazing that people who object to the function/data
seperation have to invent some annoyingly stupid example with two kinds
of data instead of actually trying to get the very simple idea that
functions are _used_ very differently from data so often that it makes
sense to separate the two from eachother. The only cost is that we read
the first position in a form as an operator and everything else as an
operand, and then when we need to talk about the operator, we use an
adjective like function, and when we need to _call_ some data value that
is a function, we use funcall the exact same way apply is used to call
both functions (with the above adjective) and data. Please accept that
some of us find this fantastically natural and think in terms that make
conflating nouns and verbs tremendously confusing. Scheme does this, and
they are _hysterical_ about issues that we real Lispers simply do not
understand their emotionalism about: hygienic macros, for instance, guard
against clobbering the functional value of variables that some programmer
is likely to use for data. That is a stupid solution to a non-existing
problem as seen from real Lisps: They made the obvious mistake of getting
rid of the verb/noun distinction, and now they have to pay for it. Duh!
> I actually dislike it that this apparent self-application is not
> happening, because here the "notation lies" in my eyes. I dislike it
> that it is possible that the same name is naming two totally different
> things in this expression (x x).
Get over it. Or use Scheme. In any case, your dislike is _completely_
irrelevant to real Lisps. _You_ deal with it, or not. The language
stays the same. If you are irritated by it, go away and spend your life
on something less irritating. Personally, I could not care less what
some Scheme freak is irritated by, but I find it amazing that so many
Scheme freaks waltz over here to comp.lang.lisp and spout the arrogance
about what they dislike as if they expect to be considered anything but a
real pest in a forum that has explicitly accepted, embraced, and enjoy
what you "dislike". Do you do this in real life, too, by the way? Do
you waltz into political party meetings and express your _dislike_ for
core elements of their program? Do you walk into stores and express your
_dislike_ for the way they choose to display their products? If so, may
I suggest Augustine's prayer?
God grant me serenity to accept the things I cannot change,
courage to change the things I can,
and wisdom to know the difference.
> When, as I assume, after (defvar x 3) the second x in (x x) is
> effectively replaced by 3, how would I then write a self-application,
> i.e., an application of a function to itself?
I think you need to get hold a reasonably up-to-date Lisp text. You ask
a bunch of questions that assume so much that one would have to return to
first principles to re-teach you how to see the problems you have come to
think of as obvious. I wonder why this happens to people, incidentally.
I am studying SQL at the moment, and I have the "pleasure" of playing
with a rather interesting set of implementations that have a rather
interesting concept of adherence to the database theory that I studied
several years ago, not to mention conformance to the standard. However,
if I am to be good at SQL, there is simply no way around accepting what
is out there _until_ I am good enough at this to know what to demand and
how to achieve what I want. Like, MySQL is sufficient for a lot of small
applications, but lacking transactions (i.e., commit and rollback), you
invite a veritable disaster if you base real applications on it. But
more importantly, qua language, SQL has to be understood on its own
terms, not the terms of some _other_ language. Oracle has PL/SQL and is
flirting heavily with Java these days, and people use Perl to interface
with several other databases. I have found the need to learn Perl well,
too, and fortunately, Perl's huge suck factor is gradually decreasing
since it is now possible to refer to variables sanely. (Note, however,
that Perl also makes a big issue about separating verbs and nouns. Note
also that the SGML family of languages have lots of namespaces: elements,
attributes, entities, unique ids, etc, and that people find this simple
and intuitive to deal with, because the human brain is obviously wired
for dealing with context. At least English-speaking human brains.)
Dr. Edmund Weitz
> Judging on what is "simple" I would take a look at mathematical
> notation, because this has been developing over hundreds of
> years without any need to care about
>
> - whether it would be easy to parse by a computer program
> - whether it would be easy to compile it or interpret it
> by a computer program
> - whether computer fonts are available for the symbols
>
> Mathematical notation has been invented /only/ for the purpose
> to be readable and writeable by humans.
>
> And it happens that in this notation a name names only one
> object, independent of its context.
Having spent most of my adult life with mathematics I have to disagree
here. Mathematicians have a tendency to use sloppy notational
conventions which only make sense if they are understood in the proper
context because it would usually be too much work to read and write
everything exactly.
To give one example from my former work (using TeX notation): It is
common practice in infinite set theory to let the symbol '+' denote
ordinal addition as well as cardinal addition. \omega and \Aleph_0
both denote _exactly_ the same thing, namely the set of natural
numbers. But everyone working in this field would understand \omega +
\omega to be the ordinal sum of the two sets (which is the second
limit ordinal) which is _different_ from \Aleph_0 + \Aleph_0 which is
understood to be the cardinal sum of the two sets (which is \Aleph_0,
i.e. \omega, itself).
It would, of course, be more exact to use to different symbols (like
'+_1' instead of '+' for ordinal addition) but this is rarely done. It
is instead taken for granted that it will be clear from the context
what the symbol '+' stands for.
Another example would be ring theory where it is common pratice to
denote the (multiplicative) identity with the symbol '1' in _every_
ring. Even if dealing with several rings at once nobody would write,
say, 1_R and 1_S to denote the identities of the rings R and S. Both
identities would be written as the symbol '1' although they are (or
can be) _different_ objects and you have to see the context to
understand what '1' stands for.
Edi.
Kent M Pitman
> Judging on what is "simple" I would take a look at mathematical
> notation,
Well, I simply disagree. After those same hundreds of years,
talking Barbie still says "Math is hard." while at the same time,
every young child who pulls that string understands that math is
"difficult" not "unsoft". I have never met any person, no matter
how ill-educated, who does not correctly process English and its
context-sensitive nature. I have met inordinate numbers of people
who find the notations you're referring to an impenetrable barrier
to higher learning.
Of course, neither your statements nor mine are hard science so we
should just agree to disagree. But at least you understand where
I and my ilk are coming from in having designed the language as we
did.
> because this has been developing over hundreds of
> years without any need to care about
>
> - whether it would be easy to parse by a computer program
I worked on Macsyma for a number of years. My expert opinion is that
parsing math in its full-blown form is quite complex. Perhaps you
don't regard "case" or "font" as "context", but I do. Math abuses
this notion of context heavily.
However, as someone pointed out here recently, and I found it insightful,
mathemeticians do always not speak their notation aloud. They do not say
"funny script R" they say "the Reals". They don't say "capital Sigma
superscripted by x subscripted by 0" they say "The sum from 0 to x". etc.
Their funny notations are designed to be visual, rather than auditory.
Human language, by contrast, is designed to be both spoken and written,
and it doesn't even require a very close examination of Latin and French,
German and Dutch, Spanish to Portuguese, and so on to tell that natural
language is principally carried auditorily, not written. Psychology
memory experiments have been done to confirm this as well. That makes it
distinctly different in character than math notation.
In programming languages, we have had a choice which branch to follow,
and some languages (e.g., APL) have gone one way while most (e.g., LISP)
have gone the other way. I worry greatly about pronounceability of the
language because I do expect people to speak it. A lot of people have
referred to Lisp in a favorable way by saying that it is very English-like
(by which I think the mean natural-language-like). This is not by
accident.
> - whether it would be easy to compile it or interpret it
> by a computer program
Compilation and interpretation requires only definite knowledge.
There is nothing ambiguous about CL's semantics.
> - whether computer fonts are available for the symbols
Hmm.
> Mathematical notation has been invented /only/ for the purpose
> to be readable and writeable by humans.
>
> And it happens that in this notation a name names only one
> object, independent of its context.
I suspect this is, in part, because Math has so many contexts it
couldn't easily enumerate them all well enough to assign a different
meaning to each. ;-)
Kent M Pitman
>
> {2001-09-23 04:08} "Kaz Kylheku":
>
> >I'd be uncomfortable with that. But somehow, the division
> >between code and data makes it okay to have these separate
> >bindings.
>
> In the 1950's McCarthy was creating a list processing library
> for FORTRAN. He invented 'EVAL' only as a theoretical tool. Then
> someone from his working group starts to implement 'EVAL' and
> thus LISP was born.
>
> Therefore, to mee, it was always apparent that the birth of LISP
> happend exactly at that point where one gave up the strict
> separation between code and data. The Newsgroup must be aware of
> this, too: In LISP one can build a list (as "data") and then
> interpret (execute) this as a program.
Nothing keeps you from doing this. EVAL is still what does this.
> I am surprised to find out that nowadays the division between
> code and data in LISP has been enforced by separate namespaces.
It is not enforced in that way. Namespaces have nothing to do with
the issue of code vs data. That's a red herring. All the problems
you're having with EVAL would still be there if common lisp had only
one namespace. The change that is bugging you is utterly orthogonal.
For example, Scheme (which has the namespace properties you're talking
about) has exactly the same requirement that you do something to turn
a list into a function. A list whose car is LAMBDA is not a function
in Scheme.
Kent M Pitman
> {2001-09-23 04:47} "Erik Naggum":
>
> >It would be massively _more_ conceptually simple for you if
> >you could become willing to wrap your head around the way
> >these things are actually done in the language under study.
>
> /The/ language under study, sounds as if this was a newsgroup
> only for /Common/ Lisp? From my understanding of the name
> "comp.lang.lisp" should also apply to other/older LISP dialects.
In practice, this is not so. I think people here are happy to tolerate
some deviation in the name of not being harsh, but the practical fact
is that Common Lisp is the only lisp discussed here 99% of the time.
Most other "dialects of lisp" or "languages in the lisp family" (whichever
terminology you prefer) have their own newsgroups or mailing list.
I'm probably one of the few on this list who's ever seen the ISLISP
spec and only probably because I was its project editor, not because
I've programmed in it. GNU emacs, autolisp, and scheme have their own
newsgroups that we offload traffic to. Eulisp, I think, uses a
mailing list. ISLISP, as far as I know, is simply not discussed
anywhere, though there are occasional questions here. Some people on
this forum still talk about old-Common Lisp (CLTL1), but even that has
mostly fallen into disuse and people encourage users of it to upgrade.
> I admit, that I am not aware of many aspects of Common Lisp, but
> I am also not a user of Scheme. I have learned LISP from books
> written well before the first specification of Common Lisp.
I think it's great that you're still interested in Lisp and I'm not
trying to scare you away, but you should understand when you talk
about these old and odd dialects that people here are going to vaguely
understand you, but mostly be confused by everything you say. Sort of
like trying to speak dutch in germany or spanish in italy...
> I thought that in this newsgroup it might be on-topic to discuss
> the differences between older (historic) LISPs and Common Lisp
> and the rationale for them. Of course, to do so, I should learn
> more about Common Lisp, first. In so far, you are right.
I generally agree with everything you said in this paragraph. It will
help you to learn more CL. It also isn't out of bound to ask about the
rationales that led to existing decisions. Just try to understand that
these decisions were made long ago, and that in many ways the real difference
between the Scheme and Common Lisp communities, at least as seen by people
here, is that the Scheme community debates endlessly what is "Right" while
the CL community is more interested in "what will suffice to move things
forward"; that is, we're a community of people organized around an industrial
strength standard that is "good enough". We've designed it as best we can,
and it has little things here and there that bug this or that person, but all
in all, having just decided on something is important because it means we
can move on to quibble about new things instead of continuing to revisit
the past. So if you see some unrest in the discussion it's because people
here have done these discussions to death years ago and many just want to
debate new things...
Erik Naggum
> I am surprised to find out that nowadays the division between code and
> data in LISP has been enforced by separate namespaces.
It is not. Your insistence on not rejecting your preconceptions surprises
me. Or more honestly, it does _not_ surprise me, anymore. Unwillingness
to think and listen goes hand in hand with preconceptions hard as concrete.
Go to Scheme; people of like (lack of) mind enjoy the silliness you crave.
Erik Naggum
> I thought that in this newsgroup it might be on-topic to discuss the
> differences between older (historic) LISPs and Common Lisp and the
> rationale for them. Of course, to do so, I should learn more about
> Common Lisp, first. In so far, you are right.
We can sure _discuss_ the differences, but you keep karping on what you
_dislike_. Please understand the difference. I have absolutely no
interest in talking with someone who focuses on what she _dislikes_
before she understands anything at all about what is going on, and
especially not some ignorant arrogant jerk that spends her time whining
about how _wrong_ some of the decisions that cannot be undone are. It is
simply not fruitful to deal with people of so closed minds. They need a
newsgroup for closed minds, and comp.lang.scheme is the best choice, now.
Study first, become competent, make informed choices. _Quit_ whining!
Erik Naggum
> Judging on what is "simple" I would take a look at mathematical notation
Well, I would not. Since this is where the disagreement is, not in the
application of your premise, would you be kind enough to tell us _why_
mathematical notation is the only appropriate standard of simplicity for
programming languages?
Heikki Tuuri
Erik Naggum wrote in message <32102020...@naggum.net>...
>* Kaz Kylheku
> how to achieve what I want. Like, MySQL is sufficient for a lot of small
> applications, but lacking transactions (i.e., commit and rollback), you
> invite a veritable disaster if you base real applications on it. But
MySQL supports transactions through BDB and InnoDB
tables. See http://www.innodb.com for more info and benchmarks.
Regards,
Heikki Tuuri
Innobase Oy
Christophe Rhodes
> And it happens that in this notation a name names only one
> object, independent of its context.
Nonsense. I work all the time in a field of mathemantics where
functions f and parameters f are used. And it's not only f that gets
overloaded, either.
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Frank A. Adrian
> /The/ language under study, sounds as if this was a newsgroup
> only for /Common/ Lisp? From my understanding of the name
> "comp.lang.lisp" should also apply to other/older LISP dialects.
You can discuss them but, in reality, there are only four widely used Lisps
in the world these days - AutoLisp, ELisp, ISO Lisp, and Common Lisp. The
first three of these are either (a) not officially standardized (AutoLisp,
ELISP) or (b) not widely used (ISO Lisp) so, for all intents and purposes,
if you want to talk about "Lisp", it is Common Lisp you refer to, for
better or worse. Sometimes, people will refer to "older dialects",
sometimes with nostalgia, sometimes with revile, but they are in the past.
ANY relevance they may have had as far as goes the present reality or
FUTURE of Lisp is likely to be small.
> I admit, that I am not aware of many aspects of Common Lisp, but
> I am also not a user of Scheme. I have learned LISP from books
> written well before the first specification of Common Lisp.
This will be a problem. Read a modern book on Common Lisp: Norvig's
"Paradigms of AI Programming" is probably the best, but Graham's "ANSI
Common Lisp" will do in a pinch. In a spirit of humility, assume that
"everything you know is wrong".
> I thought that in this newsgroup it might be on-topic to discuss
> the differences between older (historic) LISPs and Common Lisp
> and the rationale for them. Of course, to do so, I should learn
> more about Common Lisp, first. In so far, you are right.`
See above. Although you can ask "Why?", these matter have been hashed out
long ago (about 15-20 years ago). Saying that these people were wrong and
that you are right, or bringing in irrelevancies like what you "like" or
"dislike" might be fine as a catharsis or ego boost for you, but tends to
annoy some people who are, quite frankly, tired of having people who (even
admittedly) come in here not knowing the language, not understanding the
reasons behind `decisions that were made', and bitching about both.
If you want a different language - fine! Build one! Use Lisp as a basis -
it's simple enough to write and interpreter for whatever YOU want to do in
Lisp. Then you can work in YOUR environment quite happily. Otherwise,
live in reality, in "what is", and quit complaining...
faa
>
Kaz Kylheku
>Hi!
>
>Erik Naggum wrote in message <32102020...@naggum.net>...
>>* Kaz Kylheku
>> how to achieve what I want. Like, MySQL is sufficient for a lot of small
>> applications, but lacking transactions (i.e., commit and rollback), you
>> invite a veritable disaster if you base real applications on it. But
Note that I didn't write anything bout MySQL; this is a misquote.
Christophe Rhodes
> {2001-09-23 18:43} "Christophe Rhodes":
>
> >> And it happens that in this notation a name names only one
> >> object, independent of its context.
> >
> >Nonsense. I work all the time in a field of mathemantics
> >where functions f and parameters f are used. And it's not
> >only f that gets overloaded, either.
>
> Therefore, it should be easy for you to give some reference,
> like a postscript-thesis on a web server or so, where something
> like "f(f)" appears and both "f" have different meanings.
If you like.
From your favourite xxx archive mirror, find hep-th/0108215, to take a
paper that is lying on my desk; find equation 4.5, which is roughly
\ddot{\delta} + H\dot{delta}-18H^2\delta = -\frac{4}{3}\delta E_{00}
The "\delta"s on the left hand side have a different meaning (density
contrast) from the "\delta" on the right hand side (small change).
Tim Bradshaw
> Mathematical notation has been invented /only/ for the purpose
> to be readable and writeable by humans.
>
So I suppose all this multiple-letter-variable-name stuff that happens
in computer programs is really a bad development: maths gets by with
single-character names, why can't we?
--tim
Kaz Kylheku
Stegmann wrote:
>{2001-09-24 10:26} "Christophe Rhodes":
>>\ddot{\delta} + H\dot{delta}-18H^2\delta = -\frac{4}{3}\delta
>>E_{00}
>>
>>The "\delta"s on the left hand side have a different meaning
>>(density contrast) from the "\delta" on the right hand side
>>(small change).
>
>symbol by itself, but just part of "\delta E", a two letter
>name. That would correspond to two different symbols like "d"
>and "de" in an programming language.
>
>In order to answer this, one should ask if the right side
>"\delta" can be interpret as a mathematical object (like a
>function or an operator with a well defined range and behaviour)
>independent of the following "E".
Since this is TeX, \delta is simply a control sequence. Regardless
of what it is, the space after it terminates the control sequence,
and is eaten.
Whether or not E is an argument to the control sequence depends on what
that control sequence represents; it could be a macro that takes one
parameter like this
\def\delta#1{...}
Then E would be consumed as argument #1. That is all.