From: Faré <fa...@gm...> - 2014-04-25 08:56:58
|
I was surprised to find that this worked on SBCL but not on other implementations: (in-package :fare-quasiquote) (defstruct (quasiquote-vector-pattern (:include optima::constructor-pattern) (:constructor make-quasiquote-vector-pattern (content-pattern &aux (subpatterns (list content-pattern)))))) The thing is, that &aux subpatterns initializes a slot named optima::subpatterns, defined in optima::constructor-pattern. If I specify optima::subpatterns, the code works on CCL and CLISP; but if I specify subpatterns, CCL and CLISP create a different slot for the structure. Is it a bug or a feature that SBCL matches the name with STRING= (or some such) rather than EQ? Looking at CLHS 3.4.6, I'd say it's a bug, To reproduce easily the issue on any Lisp with no context: (defpackage a (:use cl)) (defpackage b (:use cl)) (defstruct foo (a::x 0)) (defstruct (bar (:include foo) (:constructor mkbar (v &aux (b::x (+ v v)))))) (describe (mkbar 2)) (foo-x (mkbar 2)) SBCL and CMUCL say 4, other lisps say 0. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I have many lucky numbers: 45, 357, 9, etc etc etc. but 911 is NOT one of them — I440r |
From: Christophe R. <cs...@ca...> - 2014-04-25 09:16:17
|
Faré <fa...@gm...> writes: > Is it a bug or a feature that SBCL matches the name with STRING= > (or some such) rather than EQ? Looking at CLHS 3.4.6, I'd say it's a bug, Feature, sort of, but it's a bit of a mess. CLHS DEFSTRUCT says: The symbols which name the slots must not be used by the implementation as the names for the lambda variables in the constructor function, since one or more of those symbols might have been proclaimed special or might be defined as the name of a constant variable. So there must already be some sort of indirection in between constructors and the slot names. The way we implement this is by using gensyms with the same (under STRING=) name as the slot names, and basically try to treat defstruct slot names as strings rather than symbols. (We fail at this in SLOT-VALUE, I think, but strictly SLOT-VALUE on structures in not defined anyway). For more evidence that defstruct slot names are string-like: If any two slot names (whether present directly or inherited by the :include option) are the same under string=, defstruct should signal an error of type program-error. Cheers, Christophe |
From: Faré <fa...@gm...> - 2014-04-25 10:22:09
|
On Fri, Apr 25, 2014 at 5:16 AM, Christophe Rhodes <cs...@ca...> wrote: > Faré <fa...@gm...> writes: > >> Is it a bug or a feature that SBCL matches the name with STRING= >> (or some such) rather than EQ? Looking at CLHS 3.4.6, I'd say it's a bug, > > Feature, sort of, but it's a bit of a mess. > > CLHS DEFSTRUCT says: > > The symbols which name the slots must not be used by the > implementation as the names for the lambda variables in the > constructor function, since one or more of those symbols might have > been proclaimed special or might be defined as the name of a constant > variable. > Of course, this comment is for normal constructors, where the lambda-list is deduced from the list of slots. In the case of a boa constructor, where the slot names are derived from the symbols, which goes the other way around, and there is no specification of how a variable "matches" a slot name. In other words, it looks like both the SBCL and the CCL approaches are defensible, here. Which is scary. > So there must already be some sort of indirection in between > constructors and the slot names. The way we implement this is by using > gensyms with the same (under STRING=) name as the slot names, and > basically try to treat defstruct slot names as strings rather than > symbols. (We fail at this in SLOT-VALUE, I think, but strictly > SLOT-VALUE on structures in not defined anyway). > > For more evidence that defstruct slot names are string-like: > > If any two slot names (whether present directly or inherited by the > :include option) are the same under string=, defstruct should signal > an error of type program-error. > Thanks for the language lawyering. Oh my. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It's your road and yours alone; others may walk it *with* you, but no one will walk it *for* you... |