Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

let bindings

3 views
Skip to first unread message

Mark Carroll

unread,
Sep 14, 1999, 3:00:00 AM9/14/99
to
I get the impression from the CLHS that
(let ((x 1)) (let ((x (+ x 1))) x)) will always happily return 2?

-- Mark

Johan Kullstam

unread,
Sep 14, 1999, 3:00:00 AM9/14/99
to
Mark Carroll <ma...@chiark.greenend.org.uk> writes:

> I get the impression from the CLHS that
> (let ((x 1)) (let ((x (+ x 1))) x)) will always happily return 2?

yes. from ACL trial 5.1 for linux i see

USER(1): (let ((x 1)) (let ((x (+ x 1))) x))
2

so at least one implementation does so. i would say ACL is happy
since i see no errors and enter not into a break loop.

as a courtesy to a human reader, you may want to try to avoid using
the same variable name in the inner let as it is confusing. however,
it works and should, e.g., a macro roll it out, you'd still be ok.

--
J o h a n K u l l s t a m
[kull...@ne.mediaone.net]
Don't Fear the Penguin!

Erik Naggum

unread,
Sep 14, 1999, 3:00:00 AM9/14/99
to
* Mark Carroll <ma...@chiark.greenend.org.uk>

| I get the impression from the CLHS that
| (let ((x 1)) (let ((x (+ x 1))) x)) will always happily return 2?

what's your question?

assuming that it has to do with the scope of the bindings, the scope of
bindings in a LET can informally be said to be the body form, but none of
the value forms. the scope of bindings in a LET* can informally be said
to include the following value forms and the body. in an FLET, the scope
is likewise the body, only, but in LABELS the scope is informally the
entire LABELS form. in MACROLET, the scope is the body of the whole
form, but the bodies of the macros defined are expanded _in_ that body,
so the scope appears to be the whole form. whether this is simple or
complex to deal with seems to depend on the mental model brought to the
issues at hand. for instance, I fail to see what could possibly be
ambiguous about the specification which would lead anyone to have only
"impressions" as to what it says in this particular case, but it could be
that the lack of some particular wording or minute point renders a reader
with a predetermined model unable to get a preconceived question resolved.
I'd like to understand what the pre-existing model and issue are, since
it seems to be a lot of small issues like this that keep people from
seeing the "bloody obvious", and I'm sure it's possible to get rid of a
lot of confusion with some very simple statement to dispell confusion.

#:Erik

Kent M Pitman

unread,
Sep 14, 1999, 3:00:00 AM9/14/99
to
Mark Carroll <ma...@chiark.greenend.org.uk> writes:

> I get the impression from the CLHS that
> (let ((x 1)) (let ((x (+ x 1))) x)) will always happily return 2?

Really? I don't see any place in CLHS where it guarantees happiness.

Btw, what do you expect other than 2?

Mark Carroll

unread,
Sep 14, 1999, 3:00:00 AM9/14/99
to
In article <sfwpuzl...@world.std.com>,

Kent M Pitman <pit...@world.std.com> wrote:
>Mark Carroll <ma...@chiark.greenend.org.uk> writes:
>
>> I get the impression from the CLHS that
>> (let ((x 1)) (let ((x (+ x 1))) x)) will always happily return 2?
>
>Really? I don't see any place in CLHS where it guarantees happiness.

Well, it seems to me to say that in (let ((x a) (y b) (z c) ..) ..),
the a, b, c are all evaluated before the x, y, z are bound to their
values.

>Btw, what do you expect other than 2?

I wanted to make sure that none of the bindings could affect anything
around where they are in that region before the main body of the let.

-- Mark

Barry Margolin

unread,
Sep 14, 1999, 3:00:00 AM9/14/99
to
In article <gXE*dT...@news.chiark.greenend.org.uk>,

Mark Carroll <ma...@chiark.greenend.org.uk> wrote:
>In article <sfwpuzl...@world.std.com>,
>Kent M Pitman <pit...@world.std.com> wrote:
>>Mark Carroll <ma...@chiark.greenend.org.uk> writes:
>>
>>> I get the impression from the CLHS that
>>> (let ((x 1)) (let ((x (+ x 1))) x)) will always happily return 2?
>>
>>Really? I don't see any place in CLHS where it guarantees happiness.
>
>Well, it seems to me to say that in (let ((x a) (y b) (z c) ..) ..),
>the a, b, c are all evaluated before the x, y, z are bound to their
>values.

What does that have to do with whether the Lisp implementation is *happy*
when it does it. It may be returning 2 grudgingly, only because it's
required to, not because it wants to.

--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, 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.

Mark Carroll

unread,
Sep 14, 1999, 3:00:00 AM9/14/99
to
In article <31463040...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:
>* Mark Carroll <ma...@chiark.greenend.org.uk>

>| I get the impression from the CLHS that
>| (let ((x 1)) (let ((x (+ x 1))) x)) will always happily return 2?
>
> what's your question?
>
> assuming that it has to do with the scope of the bindings, the scope of
> bindings in a LET can informally be said to be the body form, but none of
> the value forms. the scope of bindings in a LET* can informally be said

Yes, you answered exactly my question - thank you. (-:

(snip useful info about other let-like things)


> issues at hand. for instance, I fail to see what could possibly be
> ambiguous about the specification which would lead anyone to have only
> "impressions" as to what it says in this particular case, but it could be
> that the lack of some particular wording or minute point renders a reader
> with a predetermined model unable to get a preconceived question resolved.

It's probably just a case of getting used to the terminology. Lisp
uses many terms, like 'special form', etc. that you don't really have
to understand that well to get quite substantial things done. But, so
long as you don't understand things properly, you'll occasionally be
surprised. Like with C. That's my impression anyway.

> I'd like to understand what the pre-existing model and issue are, since
> it seems to be a lot of small issues like this that keep people from
> seeing the "bloody obvious", and I'm sure it's possible to get rid of a
> lot of confusion with some very simple statement to dispell confusion.

Certainly, I've found the CLHS as clear as mud on some matters, but it
did fairly well here. It's mostly a case of there being lots of
possibilities with regard to what the guarantees are for that sort of
construct, and me not being wholly used to the human language used in
the Lisp community to describe precise language concepts.

-- Mark

Jim Bushnell

unread,
Sep 14, 1999, 3:00:00 AM9/14/99
to
I sugggest that the following will do what is desired:

(let ((happy t)
.....)
body)

This guarantees happiness, which is not necessarily true in an arbitrary let
form.

Jim Bushnell

Mark Carroll <ma...@chiark.greenend.org.uk> wrote in message
news:gXE*dT...@news.chiark.greenend.org.uk...


> In article <sfwpuzl...@world.std.com>,
> Kent M Pitman <pit...@world.std.com> wrote:
> >Mark Carroll <ma...@chiark.greenend.org.uk> writes:
> >

> >> I get the impression from the CLHS that
> >> (let ((x 1)) (let ((x (+ x 1))) x)) will always happily return 2?
> >

> >Really? I don't see any place in CLHS where it guarantees happiness.
>
> Well, it seems to me to say that in (let ((x a) (y b) (z c) ..) ..),
> the a, b, c are all evaluated before the x, y, z are bound to their
> values.
>

Fredrik Sandstrom

unread,
Sep 17, 1999, 3:00:00 AM9/17/99
to
In article <SNn*uR...@news.chiark.greenend.org.uk>, Mark Carroll wrote:
>I get the impression from the CLHS that
>(let ((x 1)) (let ((x (+ x 1))) x)) will always happily return 2?

No, to guarantee that it does it happily, you must use the :happily
keyword in a return form, and to be able to use return you must wrap
it in a block, like this:

(let ((x 1))
(let ((x (+ x 1)))

(block nil (return :happily t x))))

The default value of happily is implementation dependent.

--
- Fredrik Sandstrom fre...@infa.abo.fi http://infa.abo.fi/~fredrik -
Computer Science at Abo Akademi University --

0 new messages