question re let and lambda syntax
Jason
I've been playing with Lisp (esp Emacs Lisp) for a year and a half or
so, and have finally decided to study Scheme. I'm working through "The
Scheme Programming Language", by Dybvig, and am finding the subject
fascinating so far, but am stumped by an example given on page 28:
(let ((f (lambda x x)))
(f 1 2 3 4))
When I run this I get
=> (list 1 2 3 4)
Now, this is just baffling me! It seems that this example is creating
a variable named "f", and setting this variable to an empty function
(lambda x x), but apparently that's not the case. Also, there are two
x's in the argument list, but the compiler doesn't seem to mind.
However, when I remove one x, it does.
(let ((f (lambda x)))
(f 1 2 3 4))
=> lambda: bad syntax in: (lambda x)
And if I rework this into something that I *think* is equivalent, I
get more errors!
(define f
(lambda (x x)))
=> lambda: bad syntax in: (lambda (x x))
What am I missing here?
-Jason
Kjetil S. Matheussen
On Fri, 8 Jun 2007, Jason wrote:
>
> What am I missing here?
>
"
(lambda ( . x)
x)
"
is the same as:
"
(lambda x
x)
"
And
"
(define (list . x)
x)
"
is the same as:
"
(define list
(lambda ( . x)
x))
"
which is also the same as:
"
(define list
(lambda x
x))
"
Brian C. Barnes
>
> (let ((f (lambda x x)))
> (f 1 2 3 4))
Hi Jason.
Look at the syntax for let
(let
((variable value) ... )
(expression) ...)
So, you have "let", then you have a single binding, namely
(f (lambda x x))
This says to bind to f the value (lambda x x).
The syntax for lambda is:
(lambda (formal ...) (expression)
OR
(lambda formal (expression))
In the first case, you have a list of formal arguments, like:
(lambda (x y z) (somthing))
In the second case, you have just a single formal argument
(lambda x (something))
The difference is that in the first case, you must pass 3 arguments to
this function, and they are assigned to the formals x, y, and z. In the
second case, you can pass as many arguments as you want, and Scheme
will automatically package them all up into a single list and assign
that list to the formal x.
So, the definition (lambda x x) basically defines a function that takes
any number of arguments, assigned them to "x", and then returns the
value of x as its result.
The final part of the "let" is an expression to be evaluated, which is
an application of the function "f" (which was just defined), passing it
the arguments 1, 2, 3, and 4. Scheme packages these up into a list and
binds them to the symbol "x". The procedure "f" then simply returns
this list as its result.
Hope that helps.
Brian.
Jason
wrote:
Okaaay. This is starting to clear up a bit. In the text, Dybvig is
discussing the three ways in which arguments to lambda are bound to
the variables in the argument list. We have Arg1 ... ArgN; ArgR; and
Arg1 ... ArgN . ArgR.
Although clear in concept, this is still fuzzy in implementation. I
made some test cases that help me to understand.
((lambda (x . y) x) 1 2 3 4)
==> 1
((lambda (x . y) y) 1 2 3 4)
==> (list 2 3 4)
That makes sense, but then I have the explicit dot notation in the
argument list to help me. In my original example, there is no dot
notation. However, from your illustration I see that (lambda x x)
implicitly is the same as (lambda ( . x) x), so from that point of
view it makes sense. What I still don't understand is, if I can write
((lambda (x . y) x) 1 2 3 4)
==> 1
((lambda (x . y) y) 1 2 3 4)
==> (list 2 3 4)
and
((lambda x x) 1 2 3 4)
==> (list 1 2 3 4)
why can't I write
((lambda ( . x) x) 1 2 3 4)
==> read: illegal use of "."
?
-Jason
Jason
Bingo! That's it! I get it now. I was thinking that (f (lambda x x))
was a function "f" that took two arguments, both named "x", and did
nothing with them. Really it was as you describe. When I made my test,
I converted it to (f (lambda (x) x)) which, obviously *now*, was
fundamentally changing the logic from ArgR form, to Arg1 ... ArgN
form, and that's not at all what I wanted.
> The final part of the "let" is an expression to be evaluated, which is
> an application of the function "f" (which was just defined), passing it
> the arguments 1, 2, 3, and 4. Scheme packages these up into a list and
> binds them to the symbol "x". The procedure "f" then simply returns
> this list as its result.
>
> Hope that helps.
>
> Brian.
Thanks Brian (and thanks Kjetil) for helping this noob understand this
simple (but I suspect fundamental) concept. Now I can continue with my
reading. :)
-jason
Barry Margolin
Jason <jem...@gmail.com> wrote:
> Hi all,
>
> I've been playing with Lisp (esp Emacs Lisp) for a year and a half or
> so, and have finally decided to study Scheme. I'm working through "The
> Scheme Programming Language", by Dybvig, and am finding the subject
> fascinating so far, but am stumped by an example given on page 28:
>
> (let ((f (lambda x x)))
> (f 1 2 3 4))
>
> When I run this I get
> => (list 1 2 3 4)
Are you sure that's what you get? I'd expect
=> (1 2 3 4)
Where is the symbol 'list coming from? Or are you adding that yourself
to indicate that you're getting the same result as if you'd typed
(list 1 2 3 4)
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Kjetil S. Matheussen
I'm not sure. Theres really no good reason why it should be allowed
either I think, and after trying some scheme implementations, it seems
like it only works with guile. But you got the idea. :-)
Mike
Noticed the question and have read the responses to far ...
must be having a bad hair day because I'm afraid I don't get
it. Clearly you know what you are talking about so no
argument from me on your answer. The code works - but
buggered if I know why or what purpose it serves.
For the moment, I'm ignoring the let statement - in the
presented problem f is bound to the lambda function (lambda
x x) so whatever the function does, f is applied to the
arguments 1 2 3 4.
And it is here that I get lost - the lambda function. I
just don't see what you do. This is way past my
understanding of Scheme. But superficially, while I am
clueless about how the code works, is this a better way of
doing things than, say, '(1 2 3 4). The result is the
same - and I have the joy of knowing why :)
Like Jason, I tinkered to see if I might produce odd
results - found them.
((lambda (a . b . c ) a) 1 2 3 ) ; ==> 2
((lambda (a . b . c ) b) 1 2 3 ) ; ==> 1
((lambda (a . b . c ) c) 1 2 3 ) ; ==> 3
Stepper was no joy - just went straight to the result.
Taking a stab at my examples, it seems the lambda function
is doing a cons on the arguments - building pairs. If so
then the first example is similar to (car (cdr 'foo)).
Nope, I'm well out of my depth.
I'm guessing there is a good reason to be able to do this -
but I have not seen any code examples to see where it 'fits'
into practical use.
Is this something useful to know or something 'interesting'.
No insult to Scheme intended. Ignorance exposed on show
here :)
Sorry to bother you.
Mike
"Brian C. Barnes" <bcba...@austin.rr.com> wrote in message
news:466a048d$0$30659$4c36...@roadrunner.com...
Jens Axel Søgaard
> Like Jason, I tinkered to see if I might produce odd
> results - found them.
>
> ((lambda (a . b . c ) a) 1 2 3 ) ; ==> 2
> ((lambda (a . b . c ) b) 1 2 3 ) ; ==> 1
> ((lambda (a . b . c ) c) 1 2 3 ) ; ==> 3
> I'm guessing there is a good reason to be able to do this -
> but I have not seen any code examples to see where it 'fits'
> into practical use.
You have fallen over a PLT Scheme specific extension.
The "double dot" allows you to put the operator in an
"infix" position.
(2 . < . 3) instead of (< 2 3)
The most common use in PLT Scheme is in contract writing
(number? string? . -> . number)
The example you found *is* very confusing.
--
Jens Axel Søgaard
Jason
> In article <1181350991.695638.237...@r19g2000prf.googlegroups.com>,
>
> Jason <jeme...@gmail.com> wrote:
> > Hi all,
>
> > I've been playing with Lisp (esp Emacs Lisp) for a year and a half or
> > so, and have finally decided to study Scheme. I'm working through "The
> > Scheme Programming Language", by Dybvig, and am finding the subject
> > fascinating so far, but am stumped by an example given on page 28:
>
> > (let ((f (lambda x x)))
> > (f 1 2 3 4))
>
> > When I run this I get
> > => (list 1 2 3 4)
>
> Are you sure that's what you get? I'd expect
>
> => (1 2 3 4)
>
> Where is the symbol 'list coming from? Or are you adding that yourself
> to indicate that you're getting the same result as if you'd typed
>
> (list 1 2 3 4)
When I run this in chicken, I get => (1 2 3 4)
When I run this in guile, I get => (1 2 3 4)
When I run this in DrScheme, I get => (list 1 2 3 4)
It must be a factor of the way DrScheme implements (or displays) these
results.
-Jason
Jens Axel Søgaard
> When I run this in chicken, I get => (1 2 3 4)
> When I run this in guile, I get => (1 2 3 4)
> When I run this in DrScheme, I get => (list 1 2 3 4)
>
> It must be a factor of the way DrScheme implements (or displays) these
> results.
You are using one of the teaching languages. The teaching languages
use constructor syntax to display the results.
If you change to "Pretty Big Scheme" or "R5RS" you'll
see the same result in DrScheme.
--
Jens Axel Søgaard
Brian C. Barnes
> Hi Brian,
>
> And it is here that I get lost - the lambda function. I
> just don't see what you do. This is way past my
> understanding of Scheme. But superficially, while I am
> clueless about how the code works, is this a better way of
> doing things than, say, '(1 2 3 4). The result is the
> same - and I have the joy of knowing why :)
>
If you typed in "23", you would see the result 23. If you typed in "(+
22 1)" you would also see the result of 23. In the first case, you are
typing in an expression which is a constant value. In the second case,
you are typing in an expression that is more complicated, and involved
applying the "+" procedure to the arguments 22 and 1. The end result is
the same thing.
Just like typing in "'(1 2 3 4)". Here, you are typing in an expression
which is a constant value, the list (1 2 3 4). Typing in "((lambda x x)
1 2 3 4)" applies the procedure "(lambda x x)" to the argument "1, 2,
3, and 4".
There are lots of different ways to get the result "23", and there are
lots of ways to get the result "(1 2 3 4)".
Just as "+" is a procedure that adds its arguments together, "lambda"
is a procedure that takes its arguments, and builds a new procedure out
of them. It's the way you define new procedures that don't already
exist in Scheme.
> Taking a stab at my examples, it seems the lambda function
> is doing a cons on the arguments - building pairs.
This is the definition of that particular form of "lambda". As I
mentioned in my previous email, if you use the form (lambda (x) ...)
(notice the formal "x" is enclosed in parenthesis) then you get one
argument, x. If you use (lambda x ...) (notice here that the x is NOT
within parenthesis) then you get any number of arguments, automatcially
packaged up into a list for you, and assigned to x. The example is
confusing because the function itself actually does nothing, it is the
automatic packaging up of the arguments into a list that is doing all
the work.
> I'm guessing there is a good reason to be able to do this -
> but I have not seen any code examples to see where it 'fits'
> into practical use.
>
How about this simple one - a procedure which takes any number of
arguments, and returns the number of arguments it is given:
(lambda args
(length args))
Not terribly exciting, but shows a use of that capability. You could
imagine lots of other things that this form might be good for.
> Is this something useful to know or something 'interesting'.
> No insult to Scheme intended. Ignorance exposed on show
> here :)
>
> Sorry to bother you.
Not in the least. Now I have the pleasure of giving something back to
this community, which has helped me several times in the past.
>
> Mike
>
Hope I've helped.
Brian.
Ray Dillinger
> And it is here that I get lost - the lambda function. I
> just don't see what you do. This is way past my
> understanding of Scheme. But superficially, while I am
> clueless about how the code works, is this a better way of
> doing things than, say, '(1 2 3 4). The result is the
> same - and I have the joy of knowing why :)
>
> Like Jason, I tinkered to see if I might produce odd
> results - found them.
>
> ((lambda (a . b . c ) a) 1 2 3 ) ; ==> 2
> ((lambda (a . b . c ) b) 1 2 3 ) ; ==> 1
> ((lambda (a . b . c ) c) 1 2 3 ) ; ==> 3
Erk? Okay, I think your "odd result" is that your
implementation even _accepts_ the above expressions.
I really have no idea what it parses them into. And,
frankly, I would say that whoever made the parser that
accepts that, ought to be spanked. The correct result
for any of the above expressions is a parse error.
Here's why.
There is a lispy principle that any sequence of characters
which reads as valid code, must also read as valid data.
We have "quote" and "unquote" to switch between them at
need.
What you've written above doesn't read as valid data, and
according to the standard isn't valid code. A parenthesized
list reads as a series of cons cells, with the CAR field
of each pointing at a subexpression and the CDR field of
each pointing at the next cons cell. The problem is that
what a space-delimited period means, is only meaningful once
in a list, and only before the very last element in a list.
It marks an exception to this structure where the CDR field
of the last cell points to the final subexpression rather
than being nil - a net savings of one cons cell in list
structure.
Now, if you think about that, you will see that having more
than one space-delimited period inside a single list can't
mean anything in terms of datastructure. The period means
"don't allocate any more list structure and use the last
link to point to this final element." That means any further
list elements have no way to be linked into the list.
If the above is too many words, then here's a simpler rule.
You must have at least one list element in a list *before*
a space-delimited period (the last such element is what
the CAR field of the last cons cell in the list structure
points at) and _exactly_ one element *after* a space-delimited
period (it's what the CDR field of the last cons cell in
the list structure points at).
Now, rewriting your examples so that they aren't syntax
errors, and providing correct results:
((lambda (a b . c ) a) 1 2 3 ) ; ==> 1
((lambda (a b . c ) b) 1 2 3 ) ; ==> 2
((lambda (a b . c ) c) 1 2 3 ) ; ==> (3)
(lambda (a b . c) takes two arguments corresponding
to a and b, and packages any further arguments into
a list which it calls c. If you call it with two
arguments, then c will be an empty list. If you call
it with less than two arguments, then you'll get an
arity error.
Note that the return values from expressions are to be
read as data, not code. So the last one is data meaning
a list containing the number 3, not an expression
meaning a call to a function named 3.
My advice to you is to ignore any "extensions" that
make expressions out of things that don't mean anything
as data. Such extensions are actively harmful to your
understanding of how the language works, as you found
with your examples.
Bear
Matthias Blume
> My advice to you is to ignore any "extensions" that
> make expressions out of things that don't mean anything
> as data.
My advice to you is that before you hand out "advice" you check to
make sure that it makes any sense.
The implementation in question (PLT Scheme, I assume) does parse these
forms in question as data just fine:
$ mzscheme
Welcome to MzScheme version 299.400, Copyright (c) 2004-2005 PLT Scheme, Inc.
> '(a . b . c)
(b a c)
> (read)
(a . b . c)
(b a c)
>
You may disagree with the taste of the designers, but there is no
"Lispy principle" nor anything else being violated here. The
designers of PLT Scheme have simply decided to give meaning to a
syntactic form that RnRS does not assign meaning to.
> Such extensions are actively harmful to your
> understanding of how the language works, as you found
> with your examples.
Yes, never even consider thinking about the integers. They might harm
your understanding of how the naturals work.
Cheers,
Matthias
Ray Dillinger
> Ray Dillinger <be...@sonic.net> writes:
>
>
>>My advice to you is to ignore any "extensions" that
>>make expressions out of things that don't mean anything
>>as data.
>
>
> My advice to you is that before you hand out "advice" you check to
> make sure that it makes any sense.
>
> The implementation in question (PLT Scheme, I assume) does parse these
> forms in question as data just fine:
<clip brain-warping infix absurdity>
But they do so in a way that contributes nothing
but confusion to someone's understanding of the
language called "scheme" or to the understanding
of the standard meaning of the dot notation in lists.
I think that the advice I give above is good advice
and should be followed by anyone who is actually
trying to understand the programming language that
this newsgroup is about.
Bear
Mike
Whew! Thanks. I *thought* something odd was happening but
I'm not confident enough in the language to say a particular
thing deserves a spank :)
I can follow your reasoning perfectly well, thank you. That
was what I expected to see - an error.
And yes, until an extension adds value (as in makes life
easier) I don't see a mad need to rush into using things.
Although I appear to have stumbled on a small 'undocumented
feature', you are quite correct in your concern about it's
affect on my understanding of the language (or rather, data
structures used in the language). Lots of languages have
many features I ignore - not because they are 'good' or
'bad' but because I haven't been compelled to do so.
Sometimes 'slow' is a lot faster - always better when it
works.
My appreciate of Scheme remains undiminished ... now hang
on, I'll just dust off the old wooden spoon for the spanking
:)
BTW - DrScheme (my hat is off to anyone capable of coding
any interpreter).
Kindest regards,
Mike
"Ray Dillinger" <be...@sonic.net> wrote in message
news:466b6c22$0$27186$742e...@news.sonic.net...
Matthias Blume
> Matthias Blume wrote:
>> Ray Dillinger <be...@sonic.net> writes:
>>
>>>My advice to you is to ignore any "extensions" that
>>>make expressions out of things that don't mean anything
>>>as data.
>> My advice to you is that before you hand out "advice" you check to
>> make sure that it makes any sense.
>> The implementation in question (PLT Scheme, I assume) does parse
>> these
>> forms in question as data just fine:
>
> <clip brain-warping infix absurdity>
If you find such simple stuff "brain-warping", I'd recommend you get
out of programming a.s.a.p.
> But they do so in a way that contributes nothing
> but confusion to someone's understanding of the
> language called "scheme" or to the understanding
> of the standard meaning of the dot notation in lists.
Really? No offense, but who are you to argue with the designers and
implementers of arguably the best /teaching/ environment for the
language in question?
> I think that the advice I give above is good advice
> and should be followed by anyone who is actually
> trying to understand the programming language that
> this newsgroup is about.
I think it is more important to understand the more general concept
that the reader maps certain syntactic forms to certain data structure
layouts, and that the nature of this mapping is essentially arbitrary.
Matthias
Anton van Straaten
> Although I appear to have stumbled on a small 'undocumented
> feature'
The feature is documented in the "A Guide to PLT Scheme", section 2.4.3
in the latest versions, which can be found in the DrScheme Help Desk.
On the web, there's a version at:
http://pre.plt-scheme.org/docs/html/guide/Pairs__Lists__and_Scheme_Syntax.html
The documentation points out that "This two-dot convention is
non-traditional, and it has essentially nothing to do with the dot
notation for non-list pairs. PLT Scheme programmers use the infix
convension sparingly – mostly for asymmetric binary operators such as <
and is-a?."
Actually, almost the only place I've seen this feature used is for type
specifications in PLT's contracts system. This use is documented in "A
Guide to PLT Scheme Contracts", here:
http://people.cs.uchicago.edu/~robby/plt-contracts-guide/#dots
There's a section "What are the dots in contracts about?" which includes
the following explanation:
"If you are used to mathematics, you like the arrow in between the
domain and the range of a function, not at the beginning. If you have
read "How to Design Programs," you have seen this many times. [...]
"Of course, placing the arrow to the left of the range follows not only
mathematical tradition but also that of typed functional languages."
Anton
Nils M Holm
> Ray Dillinger <be...@sonic.net> writes:
> > But they do so in a way that contributes nothing
> > but confusion to someone's understanding of the
> > language called "scheme" or to the understanding
> > of the standard meaning of the dot notation in lists.
>
> Really? No offense, but who are you to argue with the designers and
> implementers of arguably the best /teaching/ environment for the
> language in question?
If the best would /always/ be right, we would still "know" that
the earth is flat and the atom is indivisible.
I agree that PLT Scheme is one of the finest Scheme environments
around, but there are some things that they simply got wrong,
especially from a teachers point of view. Infix notation is one
of them. It /is/ brain-warping (to beginners) because it is not
(standard) Scheme.
--
Nils M Holm <n m h @ t 3 x . o r g> -- http://t3x.org/nmh/
Anton van Straaten
> I agree that PLT Scheme is one of the finest Scheme environments
> around, but there are some things that they simply got wrong,
> especially from a teachers point of view. Infix notation is one
> of them. It /is/ brain-warping (to beginners) because it is not
> (standard) Scheme.
But the PLT teaching language levels don't support this feature, so
where's the problem from a teacher's point of view?
I do notice, however, that the "R5RS" language level supports this
extension, which seems to me like a mistake. Ideally, the answer to
someone experimenting like this would be "use the R5RS language level if
you want to experiment with standard Scheme behavior". That answer
doesn't work in this case.
> If the best would /always/ be right, we would still "know" that
> the earth is flat and the atom is indivisible.
What would really keep us from discovering new things is inhibiting our
ability to experiment. PLT Scheme is a research platform as well as a
teaching environment.
Anton
Eli Barzilay
Here's another PLT stupidity:
(let ((a 1))
(for-each thread-wait
(list (thread (lambda () (set! a 2)))
(thread (lambda () (set! a 3)))))
a)
This is obviously the kind of brain-warping evaluation-order absurdity
that can damage your understanding of the programming language that
this newsgroup is about. And to add an insult to injury, there are
piles of these things there. IMO, either "PLT Scheme" should change
to "PLT Workshop Scheme", or someone should get more spanking.
(And while we're at it, avoid learning French at all costs -- it looks
just close enough to English to damage your spelling capabilities.
I can't even describe the horror of these languages that use weird
symbols in the wrong direction -- leveling off the middle-east is
definitely the right thing.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
Eli Barzilay
> I do notice, however, that the "R5RS" language level supports this
> extension, which seems to me like a mistake. Ideally, the answer to
> someone experimenting like this would be "use the R5RS language
> level if you want to experiment with standard Scheme behavior".
> That answer doesn't work in this case.
And *this* should be (and is, IIRC) a bug.
Ray Dillinger
> Yes, never even consider thinking about the integers. They might harm
> your understanding of how the naturals work.
Two notes:
First, I recall several years of working with natural numbers
before negative numbers were introduced. Hence, the understanding
of what binary minus meant was well-established before unary minus
was introduced, and that understanding was already well beyond
harm from the new usage. This is basic teaching strategy: teach
one meaning at a time for a given word or symbol before teaching
things it might get confused with.
Second, the meaning of unary minus _is_ related in a reasonable
way to the meaning of binary minus, so learning unary minus (and
integers) extended the meaning of an existing symbol rather than
adding a completely different meaning with nothing in common with
established understanding. IOW, *both* uses of the minus sign
were manifestations of the same meta-level idea.
A parser that does what the poster above described fails on both
points: first, he's tripping on it before the standard usage of
dotted lists is established and his understanding of that secure,
and second, there is no unifying idea that is manifest in both
usages.
Further, he's tripping over this in the context of _lambda's_
_formal_ _argument_ _lists_, where the dotted list notation
has a crucial semantic meaning. Invoking an alternate meaning
and switching the list order around in this non-call expression
neither produces "infix" behavior of any reasonable kind,
nor contributes to understanding of how lambda works.
I'm going to stand by my initial assessment; sorry, but this
is a braindamaged failure. Having it as an option or as some
kind of delimited macrology is one thing, but having it on by
default, especially in lambda lists, is nothing short of
malicious.
Bear
Anton van Straaten
> I'm going to stand by my initial assessment; sorry, but this
> is a braindamaged failure. Having it as an option or as some
> kind of delimited macrology is one thing, but having it on by
> default, especially in lambda lists, is nothing short of
> malicious.
It is certainly something short of malicious, unless you have some
reason to believe that PLT is intentionally trying to harm people
learning Scheme. If so, that's quite a subtle plot they've got going.
The MI5 victim who's been posting here might want to check that they're
not also after him.
Anton
Matthias Blume
> Further, he's tripping over this in the context of _lambda's_
> _formal_ _argument_ _lists_, where the dotted list notation
> has a crucial semantic meaning.
And that meaning is, AFAIK, preserved. PLT Scheme merely gave meaning
to previously illegal notation.
> Invoking an alternate meaning
> and switching the list order around in this non-call expression
> neither produces "infix" behavior of any reasonable kind,
> nor contributes to understanding of how lambda works.
List notation has nothing to do with how lambda works in the first
place. Conflating these two issues is a far bigger mistake.
> I'm going to stand by my initial assessment; sorry, but this
> is a braindamaged failure. Having it as an option or as some
> kind of delimited macrology is one thing, but having it on by
> default, especially in lambda lists, is nothing short of
> malicious.
If you have any point here, you are severely undermining it by gross
overstatement.