From: james anderson
Subject: Re: A theoretical question about extent
Date: 
Message-ID: <3D5645ED.BE6E6035@setf.de>
Joe Marshall wrote:
> 
> "Barry Margolin" <······@genuity.net> wrote in message ······················@paloalto-snr1.gtei.net...
> > In article <···············@sindri.juniper.net>,
> > Joel Ray Holveck  <·····@juniper.net> wrote:
> > >Assuming that X is not special, in the following function:
> > >
> > >(defun foo (x)
> > >  x)
> > >
> > >Is the extent for this binding of X said to have ended after FOO
> > >exits?  That is to say, does the extent of a binding terminate simply
> > >because the binding is no longer reachable?
> >
> > Yes.  The extent of a binding is the period of time during which references
> > may occur.  Since it's not possible to refer to that binding after FOO has
> > returned, the extent ends then.  If FOO had created a closure that
> > referenced X, e.g.
> >
> > (defun foo (x)
> >   (setq *x-getter* #'(lambda () x))
> >   x)
> >
> > then its extent would last as long as any of those closures are still
> > around.
> 
> I don't want to contradict Barry (he is correct), but another way to
> view this is that the variable X has `indefinite' extent.  That is
> to say that binding `lasts forever'.

does the primacy of "reference" in lisp really make 'indefinite' and 'forever'
the same thing?

>                                         Now it is trivial (in this case)
> for the compiler to prove that there is no way to refer to X after
> the function exits, so it can arrange for the binding to be
> discarded.  If a closure over the binding is made (and that closure
> `escapes' the dynamic context), then the compiler will have to arrange
> for the garbage collector to discard the binding.

which are entailed by the definition "lasts as long as the possibility of
reference remains," but still somehow different than 'forever'.

...

From: Joe Marshall
Subject: Re: A theoretical question about extent
Date: 
Message-ID: <r5s59.91092$D36.80575@rwcrnsc53>
"james anderson" <··············@setf.de> wrote in message ······················@setf.de...
> Joe Marshall wrote:
> >
> > I don't want to contradict Barry (he is correct), but another way to
> > view this is that the variable X has `indefinite' extent.  That is
> > to say that binding `lasts forever'.
>
> does the primacy of "reference" in lisp really make 'indefinite' and 'forever'
> the same thing?
>
> >                                         Now it is trivial (in this case)
> > for the compiler to prove that there is no way to refer to X after
> > the function exits, so it can arrange for the binding to be
> > discarded.  If a closure over the binding is made (and that closure
> > `escapes' the dynamic context), then the compiler will have to arrange
> > for the garbage collector to discard the binding.
>
> which are entailed by the definition "lasts as long as the possibility of
> reference remains," but still somehow different than 'forever'.

I guess there may be a subtle difference between `indefinite' and
`forever', but there isn't an operational difference.  You can't
write code that could determine whether a binding is kept around
longer than the last reference.  (Indeed, it probably is kept longer
than the last reference --- until the next GC of the appropriate
generation.)
From: james anderson
Subject: Re: A theoretical question about extent
Date: 
Message-ID: <3D565C07.F340D551@setf.de>
Joe Marshall wrote:
> 
> "james anderson" <··············@setf.de> wrote in message ······················@setf.de...
> > Joe Marshall wrote:
> > >
> > > I don't want to contradict Barry (he is correct), but another way to
> > > view this is that the variable X has `indefinite' extent.  That is
> > > to say that binding `lasts forever'.
> >
> > does the primacy of "reference" in lisp really make 'indefinite' and 'forever'
> > the same thing?
> >
> > >                                         Now it is trivial (in this case)
> > > for the compiler to prove that there is no way to refer to X after
> > > the function exits, so it can arrange for the binding to be
> > > discarded.  If a closure over the binding is made (and that closure
> > > `escapes' the dynamic context), then the compiler will have to arrange
> > > for the garbage collector to discard the binding.
> >
> > which are entailed by the definition "lasts as long as the possibility of
> > reference remains," but still somehow different than 'forever'.
> 
> I guess there may be a subtle difference between `indefinite' and
> `forever', but there isn't an operational difference.

what about the difference between

  (lambda (x) ...)

which form leaves the extent of the binding "without specific limitiation,
undetermined", that is, 'indefinite', and

  (defconstant x ...)

which form specifies that a reference to the respective symbol always refers to
the respective value, that is, that the extent of the binding is 'forever'?

>                                                       You can't
> write code that could determine whether a binding is kept around
> longer than the last reference.  (Indeed, it probably is kept longer
> than the last reference --- until the next GC of the appropriate
> generation.)
From: Joe Marshall
Subject: Re: A theoretical question about extent
Date: 
Message-ID: <ZXv59.88593$uj.46070@rwcrnsc51.ops.asp.att.net>
"james anderson" <··············@setf.de> wrote in message ······················@setf.de...
>
> what about the difference between
>
>   (lambda (x) ...)
>
> which form leaves the extent of the binding "without specific limitiation,
> undetermined", that is, 'indefinite', and
>
>   (defconstant x ...)
>
> which form specifies that a reference to the respective symbol always refers to
> the respective value, that is, that the extent of the binding is 'forever'?
>

In *theory* the binding to X could be discarded if it could be
proven that X could not be referenced in the future.  So if there
were no code that referred to X, and if you could not intern the
symbol X, you could discard it.  An agressive treeshaker *might*
be able to do this.

Of course I'm just splitting hairs.