You know I was just thinking about this whole non-issue that seems to irk some
people that if you misspell some symbol in your REPL, it gets interned and then
stays there forever until you manually scrub it away. I know that Clojure
obsesses over this also: it has a way by which such symbols are treated as
garbage.
What if packages simply used weak pointers for hanging on to symbols? So, come
garbage collection time, if the only reference to a symbol is via its
registration in the package system, it disappears.
If you call (intern "FOO" some-package), ignore the return value, and then the
next time you call (intern "FOO" some-package), you may get a different object.
However, sucha program has no way to tell that it got a different object; it
has no reference to the previously returned symbol to be able to make a
comparison, and if it does retain that reference, then doing so ensures that
the same symbol is returned.
It's a change in behavior for a program which interns a symbol, discards the
reference and then performs a FIND-SYMBOL to check whether the symbol is still
in the package. It may or may not be.
It seems as if DEFPACKAGE breaks because DEFPACKAGE is used to introduce a
bunch of symbols. The weakness could be set up on a per symbol basis. For
instance exported symbols could be normal references, protected from lapsing
under gc.
Shadowing definitions pose another problem. We sometimes make visible one
package inside another package, but then shadow some selectged symbols.
The shadowing symbols are often internal, and so not protected from lapsing by
the above rule. Solution: the symbols which are in the shadow symbol list of a
package are also protected from lapsing.
The principle is to separate "semantic garbage" symbols in a package,
from ones that are deliberate installed there by programmer intent.
In article <20120206213703....@kylheku.com>,
Kaz Kylheku <k...@kylheku.com> wrote:
> What if packages simply used weak pointers for hanging on to symbols? So, > come
> garbage collection time, if the only reference to a symbol is via its
> registration in the package system, it disappears.
On 2012-02-06, Barry Margolin <bar...@alum.mit.edu> wrote:
> In article <20120206213703....@kylheku.com>,
> Kaz Kylheku <k...@kylheku.com> wrote:
>> What if packages simply used weak pointers for hanging on to symbols? So, >> come
>> garbage collection time, if the only reference to a symbol is via its
>> registration in the package system, it disappears.
This wouldn't be a problem because the existence of a variable binding would
create a reference to the symbol FOO.
(I realize that some represenations of dynamic variables don't work that way,
but they would have to for this proposal. I.e. there has to be some association
which binds FOO to a location, making it boundp, and that association holds a
reference to FOO.)
> On 2012-02-06, Barry Margolin <bar...@alum.mit.edu> wrote:
>> In article <20120206213703....@kylheku.com>,
>> Kaz Kylheku <k...@kylheku.com> wrote:
>>> What if packages simply used weak pointers for hanging on to symbols? So, >>> come
>>> garbage collection time, if the only reference to a symbol is via its
>>> registration in the package system, it disappears.
> On 2012-02-06, Barry Margolin <bar...@alum.mit.edu> wrote:
> > In article <20120206213703....@kylheku.com>,
> > Kaz Kylheku <k...@kylheku.com> wrote:
> >> What if packages simply used weak pointers for hanging on to symbols? So, > >> come
> >> garbage collection time, if the only reference to a symbol is via its
> >> registration in the package system, it disappears.
> This wouldn't be a problem because the existence of a variable binding would
> create a reference to the symbol FOO.
No it wouldn't. A variable binding is a reference FROM the symbol, not TO the symbol.
> (I realize that some represenations of dynamic variables don't work that way,
> but they would have to for this proposal. I.e. there has to be some > association
> which binds FOO to a location, making it boundp, and that association holds a
> reference to FOO.)
If bindings were maintained in a symbol table, it would work that way.
But the more common representation is just a pointer from the symbol's value cell.
A dynamic LET binding of a special variable will usually contain a reference to the symbol, but toplevel bindings usually don't.
-- Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
> On 2012-02-06, Kaz Kylheku <k...@kylheku.com> wrote:
> > On 2012-02-06, Barry Margolin <bar...@alum.mit.edu> wrote:
> >> In article <20120206213703....@kylheku.com>,
> >> Kaz Kylheku <k...@kylheku.com> wrote:
> >>> What if packages simply used weak pointers for hanging on to symbols?
> >>> So, > >>> come
> >>> garbage collection time, if the only reference to a symbol is via its
> >>> registration in the package system, it disappears.
MACLISP had a feature called "GCTWA": Garbage Collect Truly Worthless Atoms. Symbols with no value or function bindings, and which were not referenced in any data structures other than the obarray, would be garbage collected.
-- Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
> In article <20120206235044...@kylheku.com>,
> Kaz Kylheku <k...@kylheku.com> wrote:
>> On 2012-02-06, Barry Margolin <bar...@alum.mit.edu> wrote:
>> > In article <20120206213703....@kylheku.com>,
>> > Kaz Kylheku <k...@kylheku.com> wrote:
>> >> What if packages simply used weak pointers for hanging on to symbols? So, >> >> come
>> >> garbage collection time, if the only reference to a symbol is via its
>> >> registration in the package system, it disappears.
>> This wouldn't be a problem because the existence of a variable binding would
>> create a reference to the symbol FOO.
> No it wouldn't. A variable binding is a reference FROM the symbol, not > TO the symbol.
In the abstract, a binding is some kind of association between a symbol and a
storage place. This association is semantically important, regardless of how
the arrows go and must prevent the symbol from being semantic garbage.
(For instance in simple textbook Lisp interpreters a common strategy is to use
an assoc list to represent an environment. A binding is found using (assoc sym
env). That representation of environments "naturally" protects symbols, but
the list has to be traversed to find variables.
>> (I realize that some represenations of dynamic variables don't work that way,
>> but they would have to for this proposal. I.e. there has to be some >> association
>> which binds FOO to a location, making it boundp, and that association holds a
>> reference to FOO.)
> If bindings were maintained in a symbol table, it would work that way.
> But the more common representation is just a pointer from the symbol's > value cell.
Perfectly fine; this falls into the same logic as exported symbols being
protected. Basically various attributes somehow protect a symbol:
- presence in the shadowing symbols list
- presence in the list of exported symbols
- function or variable binding
- anything else: definition of the symbol as a class, type, etc.
Clearly, disappearing variables are a complete nonstarter, everyone must agree.
Barry Margolin <bar...@alum.mit.edu> writes:
>> >> Kaz Kylheku <k...@kylheku.com> wrote:
>> >>> What if packages simply used weak pointers for hanging on to symbols?
>> >>> So, >> >>> come
>> >>> garbage collection time, if the only reference to a symbol is via its
>> >>> registration in the package system, it disappears.
> MACLISP had a feature called "GCTWA": Garbage Collect Truly Worthless > Atoms. Symbols with no value or function bindings, and which were not > referenced in any data structures other than the obarray, would be > garbage collected.
Indeed. In the case of Common Lisp symbols, they have a value slot, a
function slot and a property list.
If the value slot is bound (even to NIL), or the function slot is bound,
or the property list is not NIL (it cannot be "unbound"), then one could
consider that symbol useless.
However, in Common Lisp, FIND-SYMBOL let you retrieve at least one bit
of information, and collecting "useless" symbols destroy that
information.
On the other hand, if we considered that all the symbols already exist,
this would break the package system, where importing symbols from other
packages or "using" other packages creates collision errors. One would
have to unintern (would that be effective), or "shadow" all the imported
or used symbols before.
But as the title says, it's a non-issue. You just reboot a lisp image
and load a compiled library and those symbols don't exist anymore.
"is·sue noun - a matter that is in dispute between two or more parties"
> that seems to irk some
> people that if you misspell some symbol in your REPL, it gets interned and > then stays there forever until you manually scrub it away.
The problem is not that it stays forever, the problem is that it can cause extraneous naming conflicts even if it doesn't stay forever. The most common screw case is this one:
? (make-package :lib)
#<Package "LIB">
? (make-package :app)
#<Package "APP">
? (in-package :lib)
#<Package "LIB">
? (defun libfn () t)
LIBFN
? (in-package :app)
#<Package "APP">
? (defun foo () (libfn))
;Compiler warnings :
; In FOO: Undefined function LIBFN
FOO
? (import 'lib::libfn)
- Error: Importing LIB::LIBFN to #<Package "APP"> would conflict
- with symbol LIBFN .
But that is far from the only screw case.
Note that the mere act of parsing the code (not the subsequent unsuccessful attempt to compile it) is what left the system in a state where it is no longer possible to use the library without manual corrective action.
In article <87wr7zv7ht....@kuiper.lan.informatimago.com>,
"Pascal J. Bourguignon" <p...@informatimago.com> wrote:
> However, in Common Lisp, FIND-SYMBOL let you retrieve at least one bit
> of information, and collecting "useless" symbols destroy that
> information.
Why? If you're not actually using the symbol for anything, what could it break? After all, if you store the result of find-symbol anywhere, that will prevent it from being GC'ed. If you don't, how would you know that it ever existed and then disappeared? The user's memory doesn't count; lots of things get seen by the user, but later get GC'ed.
The only thing I can imagine that would be affected by this would be a program that uses a package as a replacement for a hash table mapping strings to booleans. Screw them, they should use an actual hash table.
-- Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin <bar...@alum.mit.edu> writes:
> In article <87wr7zv7ht....@kuiper.lan.informatimago.com>,
> "Pascal J. Bourguignon" <p...@informatimago.com> wrote:
>> However, in Common Lisp, FIND-SYMBOL let you retrieve at least one bit
>> of information, and collecting "useless" symbols destroy that
>> information.
> > In article <87wr7zv7ht....@kuiper.lan.informatimago.com>,
> > "Pascal J. Bourguignon" <p...@informatimago.com> wrote:
> >> However, in Common Lisp, FIND-SYMBOL let you retrieve at least one bit
> >> of information, and collecting "useless" symbols destroy that
> >> information.
> On 2012-02-06, Kaz Kylheku<k...@kylheku.com> wrote:
>> On 2012-02-06, Barry Margolin<bar...@alum.mit.edu> wrote:
>>> In article<20120206213703....@kylheku.com>,
>>> Kaz Kylheku<k...@kylheku.com> wrote:
>>>> What if packages simply used weak pointers for hanging on to symbols? So,
>>>> come
>>>> garbage collection time, if the only reference to a symbol is via its
>>>> registration in the package system, it disappears.
I use
(defvar foo )
and leave it intentionally unbound for stuff that I expect to bind in the context of a thread (as in http processing). This allows me catch some issues.
We can not throw away such a symbol.
But I think defvar introduced symbols are not a good example of what you are suggesting to fix anyway. This is because defvar also marks something as 'special', whether bound or not.
That makes it more (?) than just a symbol.
That brings a question to my mind - how would someone check if something is special var.
> In article <87obtbuuub....@kuiper.lan.informatimago.com>,
> "Pascal J. Bourguignon" <p...@informatimago.com> wrote:
>> I just explained what it could break!
>> Programs such as:
> You do realize that if you advanced this as a serious example anywhere > but c.l.l. you would be a laughingstock, right?
Only because of all the parentheses.
Here it is also a laughingstock because of what it's doing.
> On 2/6/2012 2:57 PM, Kaz Kylheku wrote:
>> On 2012-02-06, Kaz Kylheku<k...@kylheku.com> wrote:
>>> On 2012-02-06, Barry Margolin<bar...@alum.mit.edu> wrote:
>>>> In article<20120206213703....@kylheku.com>,
>>>> Kaz Kylheku<k...@kylheku.com> wrote:
>>>>> What if packages simply used weak pointers for hanging on to symbols? So,
>>>>> come
>>>>> garbage collection time, if the only reference to a symbol is via its
>>>>> registration in the package system, it disappears.
> I use
> (defvar foo )
> and leave it intentionally unbound for stuff that I expect to bind in > the context of a thread (as in http processing). This allows me catch > some issues.
> We can not throw away such a symbol.
Correct. So the throwing away or not cannot be naively predicated on having a
value or not. But if you defvar something, that symbol has to be remembered
somewhere so that it can be pervasively special, and that can protect it.
> That brings a question to my mind - how would someone check if something > is special var.
> "is·sue noun - a matter that is in dispute between two or more parties"
>> that seems to irk some
>> people that if you misspell some symbol in your REPL, it gets interned
>> and then stays there forever until you manually scrub it away.
> The problem is not that it stays forever, the problem is that it can
> cause extraneous naming conflicts even if it doesn't stay forever. The
> most common screw case is this one:
> Note that the mere act of parsing the code (not the subsequent
> unsuccessful attempt to compile it) is what left the system in a state
> where it is no longer possible to use the library without manual
> corrective action.
I don't see the need for manual correction as a nuisance, especially
in this case. Any decent environment should offer the obvious
restarts, and resolving the conflict just takes a few keystrokes in
SLIME (BTW, SBCL also gives a style-warning about the DEFUN FOO using
the undefined function LIBFM).
I prefer deciding these issues manually when they occur instead of
some dwim-style cleverness that would save a few keystrokes in 99% of
the cases, then, in the remaining 1%, fail silently and cause trouble
later.
RG <rNOSPA...@flownet.com> wrote:
> It's not a non-issue. The mere fact that this discussion is happening > means that, by definition, it is an issue. See:
It's an issue in the sense that people worry about it. Would it be an
issue if they just stopped worrying? I don't know the answer to that, but
I suspect not.
> On 2012-02-07, Antony<remove+spam_lisp.li...@gmail.com> wrote:
>> That brings a question to my mind - how would someone check if something
>> is special var.
> (special-variable-p 'sym)
Didn't find it in CLHS
Says undefined function in ccl (also sbcl)
Then I tried in clisp, it works
> > It's not a non-issue. The mere fact that this discussion is happening > > means that, by definition, it is an issue. See:
> It's an issue in the sense that people worry about it. Would it be an
> issue if they just stopped worrying? I don't know the answer to that, but
> I suspect not.
>> > In article <87wr7zv7ht....@kuiper.lan.informatimago.com>,
>> > "Pascal J. Bourguignon" <p...@informatimago.com> wrote:
>> >> However, in Common Lisp, FIND-SYMBOL let you retrieve at least one bit
>> >> of information, and collecting "useless" symbols destroy that
>> >> information.
> > "is·sue noun - a matter that is in dispute between two or more parties"
> >> that seems to irk some
> >> people that if you misspell some symbol in your REPL, it gets interned
> >> and then stays there forever until you manually scrub it away.
> > The problem is not that it stays forever, the problem is that it can
> > cause extraneous naming conflicts even if it doesn't stay forever. The
> > most common screw case is this one:
> > Note that the mere act of parsing the code (not the subsequent
> > unsuccessful attempt to compile it) is what left the system in a state
> > where it is no longer possible to use the library without manual
> > corrective action.
> I don't see the need for manual correction as a nuisance, especially
> in this case. Any decent environment should offer the obvious
> restarts, and resolving the conflict just takes a few keystrokes in
> SLIME
For that toy example it's not so bad. Consider this case:
(defun foo () (f1) (f2) (f3) ... (fn))
where each of the f's are defined in different package.
Or, worse:
(defun foo (x y z) ...)
(use-package :snoz) ; which happens to export symbols named X, Y and Z
Now you have to manually resolve a conflict that may or may not actually be a conflict (but almost certainly isn't).
> (BTW, SBCL also gives a style-warning about the DEFUN FOO using
> the undefined function LIBFM).
Yes, but by the time you get those warnings the damage has already been done.
> I prefer deciding these issues manually when they occur instead of
> some dwim-style cleverness that would save a few keystrokes in 99% of
> the cases, then, in the remaining 1%, fail silently and cause trouble
> later.
But packages *are* "dwim-style cleverness" it's just that you have to decide the w-i-m part before your code is parsed. When you type "foo" what you really mean is (intern "foo" *package*) because:
Antony <remove+spam_lisp.li...@gmail.com> writes:
> On 2/7/2012 12:05 AM, Kaz Kylheku wrote:
>> On 2012-02-07, Antony<remove+spam_lisp.li...@gmail.com> wrote:
>>> That brings a question to my mind - how would someone check if something
>>> is special var.
>> (special-variable-p 'sym)
> Didn't find it in CLHS
> Says undefined function in ccl (also sbcl)
> Then I tried in clisp, it works
> On 2012-02-07, Antony <remove+spam_lisp.li...@gmail.com> wrote:
> > On 2/6/2012 2:57 PM, Kaz Kylheku wrote:
> >> On 2012-02-06, Kaz Kylheku<k...@kylheku.com> wrote:
> >>> On 2012-02-06, Barry Margolin<bar...@alum.mit.edu> wrote:
> >>>> In article<20120206213703....@kylheku.com>,
> >>>> Kaz Kylheku<k...@kylheku.com> wrote:
> >>>>> What if packages simply used weak pointers for hanging on to symbols?
> >>>>> So,
> >>>>> come
> >>>>> garbage collection time, if the only reference to a symbol is via its
> >>>>> registration in the package system, it disappears.
> > I use
> > (defvar foo )
> > and leave it intentionally unbound for stuff that I expect to bind in > > the context of a thread (as in http processing). This allows me catch > > some issues.
> > We can not throw away such a symbol.
> Correct. So the throwing away or not cannot be naively predicated on having a
> value or not. But if you defvar something, that symbol has to be remembered
> somewhere so that it can be pervasively special, and that can protect it.
Also, if you have functions that bind it, the references from those functions should protect it. Although that's not totally safe -- what if a GC happens between the DEFVAR and DEFUN.
-- Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
> > It's not a non-issue. The mere fact that this discussion is happening > > means that, by definition, it is an issue. See:
> It's an issue in the sense that people worry about it. Would it be an
> issue if they just stopped worrying? I don't know the answer to that, but
> I suspect not.
I looked up "nonissue" in the dictionary. It says "a topic of little or no importance". It's not simply the opposite of an issue, it's a statement about how significant it is.
-- Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
On 2012-02-07, Antony <remove+spam_lisp.li...@gmail.com> wrote:
> On 2/7/2012 12:05 AM, Kaz Kylheku wrote:
>> On 2012-02-07, Antony<remove+spam_lisp.li...@gmail.com> wrote:
>>> That brings a question to my mind - how would someone check if something
>>> is special var.
>> (special-variable-p 'sym)
> Didn't find it in CLHS
> Says undefined function in ccl (also sbcl)
> Then I tried in clisp, it works
