Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
comp.lang.lisp
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion Implementation Favoritism, a question of Lisp mindsets
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Peter Seibel  
View profile  
 More options May 4 2003, 12:59 am
Newsgroups: comp.lang.lisp
From: Peter Seibel <pe...@javamonkey.com>
Date: Sun, 04 May 2003 04:58:15 GMT
Local: Sun, May 4 2003 12:58 am
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Print | View thread | Show original | Report this message | Find messages by this author

Peter Seibel <pe...@javamonkey.com> writes:
> Mark Conrad <nos...@iam.invalid> writes:

> > In article <costanza-737264.15343803052...@news.netcologne.de>, Pascal
> > Costanza <costa...@web.de> wrote:

> > > And PLEASE: It's not very constructive that you don't follow the links
> > > people provide to you. See http://www.psg.com/~dlamkins/sl/contents.html,
> > > especially lessons 5 and 6.

> > > Do it! Do it now! Take some time to read and understand these things.
> > > There are over 30 chapters in that book. You don't want to post that
> > > much as you do on every single topic, right?

> > That online book was very helpful, I read all the chapters you
> > suggested plus chapter 15 on closures.

> > The book was not all that helpful in resolving the issue of whether a
> > "binding" is a location in memory or not, and whether that "binding" is
> > *still* a "binding" if no value is placed in the
> > binding-memory-location.

> > Confusion reigns surpreme on this particular aspect of "binding",
> > because even the Hyperspec says that a binding is an association
> > between a variable and its value.

> I'm not sure the HyperSpec says that. Here's another way to read it,
> which may clarify things. Or not--I certainly agree that folks tend to
> use different words to mean the same thing and the same words to mean
> slightly different things when discussing this topic, which can be
> confusing. And here I am just adding another interpretation. But here
> goes. (BTW, if folks think this explanation is flawed or good, I'd be
> interested to hear about it--I'm trying to write something about this
> for some materials I'm working on.)

Blech. I think I need to recant, or at least rethink, this
explanation. Because the way I wanted to understand "binding", "bind",
"bound", and "unbound" doesn't fit with the definiton of BOUNDP and
MAKUNBOUND and the observed behavior of two implementations. (I.e. I
assume the implementors, since they agree, got it right and I'm the
one who's confused.) Anyway suppose you do define a special variable
with DEFVAR:

  (defvar *s* 10)

Now evaluate:

  (let ()
    (format t "*S*: ~a (boundp: ~a)~%" *s* (boundp '*s*))
    (let ((*s* 20))
      (format t "*S*: ~a (boundp: ~a)~%" *s* (boundp '*s*))
      (makunbound '*s*)
      (if (boundp '*s*)
          (format t "*S*: ~a (boundp: ~a)~%" *s* (boundp '*s*))
          (format t "*s* not bound~%"))
      (setq *s* 30)
      (if (boundp '*s*)
          (format t "*S*: ~a (boundp: ~a)~%" *s* (boundp '*s*))
          (format t "*s* not bound~%")))
    (format t "*S*: ~a (boundp: ~a)~%" *s* (boundp '*s*)))

In both the implementations I tried this, it prints:

  *S*: 10 (boundp: T)
  *S*: 20 (boundp: T)
  *s* not bound
  *S*: 30 (boundp: T)
  *S*: 10 (boundp: T)

At this point I have to join Mark Conrad in his confusion about what
the relation between "bindings", being "bound", and having a "value"
is. Here are some relevant bits of the standard:

  binding glossary entry

    "n. an association between a name and that which the name
    denotes."

  bound glossary entry:

    "1. adj. having an associated denotation in a binding."

  unbound glossary entry:

    "adj. not having an associated denotation in a binding. See bound."

  BOUNDP dictionary entry:

    "Returns true if symbol is bound; otherwise, returns false."

  MAKUNBOUND

    "Makes the symbol be unbound, regardless of whether it was
    previously bound."

  LET dictionary entry:

    "let and let* create new variable bindings"

  PROGV dictionary entry:

    "If too few values are supplied, the remaining symbols are bound
    and then made to have no value."

  variable glossary entry:

    "n. a binding in the ``variable'' namespace."

So it seems that the only way to interpret the definiton of "binding"
that is consistent with the definitions of "bound", "unbound", BOUNDP,
and MAKUNBOUND, is that the *value* is "that which the name denotes",
as it's the *value* that MAKUNBOUND removes.

However, the code I showed above seems to demonstrate--in the two
implementations I tried it in, anyway--that there is *something* that
is created by the inner LET that persists after the MAKUNBOUND. That
is, there's either a "location" that the SETQ stores the value 30 that
is different than the "location" that the global value of *S* is
stored, or there's something that causes the old value of *S* to be
restored at the end of the inner LET. I'm tempted to call that
"something" the "binding" but that isn't correct since the "binding"
is "an association between a name and that which the name denotes" and
the name *S* in "unbound" and thus doesn't have "an associated
denotation". And it can't be the "variable" because a "variable" is
just "a binding", per the glossary.

So what the heck is the name for that something?

-Peter

P.S. I'm fairly sure I understand the *behavior* of DEFVAR, LET,
PROGV, BOUNDP, MAKUNBOUND, etc. I'm just confused about how to
correctly use the terminology of the spec to describe that behavior.

--
Peter Seibel                                      pe...@javamonkey.com

  The intellectual level needed   for  system design is  in  general
  grossly  underestimated. I am  convinced  more than ever that this
  type of work is very difficult and that every effort to do it with
  other than the best people is doomed to either failure or moderate
  success at enormous expense. --Edsger Dijkstra


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google