I'd like to declare an argument to be either T or NIL, so I'm trying:
(defun f (x)
(declare (boolean x))
x)
With CLisp and SBCL, this goes straightforwardly, but with CMUCL, I get
a note, and I would be happier if I could understand it:
; Note: Abbreviated type declaration: (BOOLEAN X).
What does this mean, and should I do something about it? Can I do
something to make it disappear, or should I let it be seen by the users
of my code?
Philippe Lorin wrote:
> I'd like to declare an argument to be either T or NIL, so I'm trying:
>
> (defun f (x)
> (declare (boolean x))
> x)
>
> With CLisp and SBCL, this goes straightforwardly, but with CMUCL, I get
> a note, and I would be happier if I could understand it:
>
> ; Note: Abbreviated type declaration: (BOOLEAN X).
>
> What does this mean, and should I do something about it? Can I do
> something to make it disappear, or should I let it be seen by the users
> of my code?
(declare (type boolean x))
'boolean could theoretically be an implementation-dependent declaration,
so it's better to have explicit (non-abbreviated) type declarations.
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
On Sun, 16 Oct 2005 17:13:14 +0200, Lars Brinkhoff <·········@nocrew.org> wrote:
> http://clhs.lisp.se/Body/t_ban.htm
According to figure 4-6 in 4.2.3 BOOLEAN is not a standardized type
specifier name. (Not that I would be able to fully grasp the
consequences of this...)
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> Lars Brinkhoff <·········@nocrew.org> wrote:
> > http://clhs.lisp.se/Body/t_ban.htm
> According to figure 4-6 in 4.2.3 BOOLEAN is not a standardized type
> specifier name.
I believe it was a late addition in the ANSI process. It's not in
CLtL2. This message seems to allude to the new type being added:
http://groups.google.com/group/comp.lang.lisp/msg/f4a61cfc70b2d789
> (Not that I would be able to fully grasp the consequences of
> this...)
Looks like a rather trivial bug in the specification.
Pascal Costanza <··@p-cos.net> writes:
> Philippe Lorin wrote:
>> I'd like to declare an argument to be either T or NIL, so I'm trying:
>> (defun f (x)
>> (declare (boolean x))
>> x)
>> With CLisp and SBCL, this goes straightforwardly, but with CMUCL, I
>> get a note, and I would be happier if I could understand it:
>> ; Note: Abbreviated type declaration: (BOOLEAN X).
>> What does this mean, and should I do something about it? Can I do
>> something to make it disappear, or should I let it be seen by the
>> users of my code?
>
> (declare (type boolean x))
>
>
> 'boolean could theoretically be an implementation-dependent
> declaration, so it's better to have explicit (non-abbreviated) type
> declarations.
Why assign qualitative goodness or badness to abbreviations?
A declaration specifier, according to 3.3.2, is a list whose car is
a declaration identifier, which, if you look at the glossary entry,
includes "a symbol which is the name of a type". Also, 3.3.3 talks
in more detail about declaration identifiers, including the possibility
of a warning being issued if the identifier is invalid (i.e. is not in
the actual list, and is not the name of a type, and is not the target
of a declaration declaration somewhere). Note that for the OP, what
showed up was not a warning; it was a note, so CMUCL is conformant.
However, I don't see any reason to distinguish (type boolean ...) from
(boolean ...), just as I don't see any reason to distinguish as a type
the expression (vector double-float *) from its abbreviation
(vector double-float) as shown in 4.2.3. But even if there is good
reason to provide a note to the effect that something was abbreviated,
I don't understand the reason for your phrase "it is better ..." - I
simply don't agree that it should be an issue.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>>Philippe Lorin wrote:
>>
>>>I'd like to declare an argument to be either T or NIL, so I'm trying:
>>>(defun f (x)
>>> (declare (boolean x))
>>> x)
>>>With CLisp and SBCL, this goes straightforwardly, but with CMUCL, I
>>>get a note, and I would be happier if I could understand it:
>>>; Note: Abbreviated type declaration: (BOOLEAN X).
>>>What does this mean, and should I do something about it? Can I do
>>>something to make it disappear, or should I let it be seen by the
>>>users of my code?
>>
>>(declare (type boolean x))
>>
>>'boolean could theoretically be an implementation-dependent
>>declaration, so it's better to have explicit (non-abbreviated) type
>>declarations.
>
> Why assign qualitative goodness or badness to abbreviations?
Good question. What I had in mind was that it might happen that someone
wants to introduce a type and someone else wants to introduce a
declaration with the same name, without the intention to match that
type. However, I haven't thought this through. The guy who introduces
the type "controls" the name, so can be aware that it is simultaneously
available as a declaration (and vice versa, in a sense). If you want to
introduce a type and an unrelated declaration with the same name, you
can do so by placing the names in different packages.
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
Pascal Costanza <··@p-cos.net> writes:
> Duane Rettig wrote:
>> Pascal Costanza <··@p-cos.net> writes:
>>
>>>Philippe Lorin wrote:
>>>
>>>>I'd like to declare an argument to be either T or NIL, so I'm trying:
>>>>(defun f (x)
>>>> (declare (boolean x))
>>>> x)
>>>>With CLisp and SBCL, this goes straightforwardly, but with CMUCL, I
>>>>get a note, and I would be happier if I could understand it:
>>>>; Note: Abbreviated type declaration: (BOOLEAN X).
>>>>What does this mean, and should I do something about it? Can I do
>>>>something to make it disappear, or should I let it be seen by the
>>>>users of my code?
>>>
>>>(declare (type boolean x))
>>>
>>>'boolean could theoretically be an implementation-dependent
>>>declaration, so it's better to have explicit (non-abbreviated) type
>>>declarations.
>> Why assign qualitative goodness or badness to abbreviations?
>
> Good question. What I had in mind was that it might happen that
> someone wants to introduce a type and someone else wants to introduce
> a declaration with the same name, without the intention to match that
> type. However, I haven't thought this through. The guy who introduces
> the type "controls" the name, so can be aware that it is
> simultaneously available as a declaration (and vice versa, in a
> sense). If you want to introduce a type and an unrelated declaration
> with the same name, you can do so by placing the names in different
> packages.
You're describing a namespace conflict. Such conflicts are better
found and debugged when the warnings are given at the source of
the conflict, which is when the actual conflicting definition is
seen. If warnings or even notes are given every time a _potential_
conflict is seen at the name's usage, then users would be inundated
with messages that they would tend to ignore eventually.
Let's look at an example. Please bear with me, because this example
is so trivial and is used so often that it may not be obvious as to
how it applies to your concern.
Let's start with a simple file:
CL-USER(1): (shell "cat foo.cl")
(defun foo (x)
(bar x))
0
CL-USER(2): (defun bar (x) (car x))
BAR
CL-USER(3): (compile-file "foo.cl")
;;; Compiling file foo.cl
;;; Writing fasl file foo.fasl
;;; Fasl write complete
#P"foo.fasl"
NIL
NIL
CL-USER(4):
Q: Why did we not get a warning about the potentially
ambiguous usage of BAR?
A: Because BAR was already defined in the lisp, and because
a form whose car is a name that defines a function is assumed
to be a call to the functon that it names.
Q: But what if BAR is then redefined as a macro?
A: Then we have a problem at that time, but not before.
Note:
CL-USER(4): (shell "cat foo2.cl")
(defun foo2 (x)
(bar x))
(defmacro bar (x)
`(car ,x))
0
CL-USER(5): (compile-file "foo2.cl")
;;; Compiling file foo2.cl
Warning: BAR, :OPERATOR was defined at the top level and is now being defined
in foo2.cl
;;; Writing fasl file foo2.fasl
;;; Fasl write complete
#P"foo2.fasl"
T
T
CL-USER(6):
The compiler is now warning about the actual conflict, not at the time
FOO2 was compiled, but at the time BAR was being redefined. How do we
know? We can try loading the new file and seeing what calling FOO2 does.
CL-USER(6): (load "foo2")
; Fast loading /tmp_mnt/net/gemini/home/duane/foo2.fasl
Warning: BAR was a function and is being redefined as a macro
Warning: BAR, :OPERATOR was defined at the top level and is now being defined
in foo2.cl
T
CL-USER(7): (foo2 '(a . b))
Error: Attempt to call BAR which is defined as a macro.
[condition type: UNDEFINED-FUNCTION]
Restart actions (select using :continue):
0: Return to Top Level (an "abort" restart).
1: Abort entirely from this (lisp) process.
[1] CL-USER(8):
And indeed, FOO2 was compiled with the expectation that BAR is a
function.
Q: shouldn't the compiler warn about the potential conflict in
usages between BAR the function and BAR the macro?
A: (Answering a question with a question): Imagine all of the
warnings you would receive in all of your code it this were the
case; would you heed any of them if you were so inundated with
these warnings?
Finally, I hope to have made a similar enough case above to the
situation about which you are concerned to allow you to draw the
same conclusions about any warnings when a user-defined type
is used as a declaration-identifier in a declaration.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
>>Good question. What I had in mind was that it might happen that
>>someone wants to introduce a type and someone else wants to introduce
>>a declaration with the same name, without the intention to match that
>>type. However, I haven't thought this through. The guy who introduces
>>the type "controls" the name, so can be aware that it is
>>simultaneously available as a declaration (and vice versa, in a
>>sense). If you want to introduce a type and an unrelated declaration
>>with the same name, you can do so by placing the names in different
>>packages.
>
> You're describing a namespace conflict.
Yes, but that's not what I had in mind. I have made a wrong assumption
about the potential conflicts that could arise with a type declaration
that is not introduced with 'type. (It's no use to explain that
assumption because it's incorrect anyway, and probably not possible to
describe coherently.)
Thanks for your detailed explanation, it definitely helped me to see
what's going on...
Cheers,
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Philippe Lorin wrote:
> I'd like to declare an argument to be either T or NIL, so I'm trying:
I declare this argument both T and NIL. That is to say, me T, you NIL.
:)