freenode/#sbcl - IRC Chatlog
Search
15:52:00
|3b|
(if (realp a) a (coerce a 'complex)) WARNs about derived type not matching asserted type, is there some valid problem there i'm missing?
15:58:58
|3b|
i guess it can't figure out that being a number and not real means it can't be not complex in the deftransform for coerce? (does sbcl have any other subtypes of number?)
18:46:58
kpoeck
I have hit some problems with clasp, but now I wonder whether I found a problem in sbcls code
18:48:36
Bike
i already told you yesterday that I think it's reasonable to interpret a lack of :read-only as meaning to inherit whatever the included slot specified.
18:59:57
pfdietz
"If a slot is read-only in the included structure, then it must also be so in the including structure."
19:07:44
kpoeck
An example is https://github.com/stassats/sbcl/blob/master/src/code/type-class.lisp#L593
19:18:37
pfdietz
It's reasonable to interpret the :read-only as being inherited, but it's also reasonable to say a conforming CL implementation can reject this. So I think SBCL should put in explicit :read-only t for those slot descriptors.
19:22:57
kpoeck
Now clasp shokes on the slot-decription (subforms nil :type (or null (vector t)) :read-only t :read-only t)
19:32:00
kpoeck
I did manage to compile sbcl once with clasp, but with another flavour of the compiler (ast based not cst based)
21:09:28
stassats
i don't read "If a slot is read-only in the included structure, then it must also be so in the including structure." as meaning it should be specified :read-only t
21:18:46
karlosz
yes, i think the verb "be" in contrast to "specified" says that we have conformant behavior
21:20:10
stassats
it doesn't say :type should be respecified again if it's omitted, so i don't expect :read-only to need the same
21:26:04
pfdietz
Even if you read the spec to say :read-only t is not required in the including defstruct, having it there cannot be wrong. SBCL might as well not count on a particular interpretation of that sentence.
21:31:18
karlosz
my inclination is towards supporting other build hosts if possible. we already bend backwards to support so many other implementations
21:36:51
pfdietz
All the other uses of the word "must" in that section are things that the conforming program must do. I don't see why including :read-only t is to be interpreted differently.
21:39:36
pfdietz
You will have to ask the people who wrote these two sentences, which treat the two cases differently: "If a slot is read-only in the included structure, then it must also be so in the including structure. If a type is supplied for a slot, it must be a subtype of the type specified in the included structure. "
21:46:22
pfdietz
However, I will point out this sentence, which argues toward your interpretation: "The structure using :include can specify default values or slot-options for the included slots different from those the included structure specifies, by giving the :include option as:"
22:39:21
kpoeck
sbcl seems to accept (defstruct foo-boo (bar 42 :read-only t :read-only t)) and (defstruct foo-boo (bar 42 :read-only t :read-only nil))
22:40:53
kpoeck
the first is in the sbcl sources at https://github.com/stassats/sbcl/blob/master/src/code/debug-info.lisp#L471
22:48:13
kpoeck
Will try to adapt clasp to the semantics you mentionned earlier (treat the slot as read-only, without requiring to repeat the read-only)