This simple function:
(defun int (n)
(declare (type integer n))
n)
I want this function only accept a integer type argument, and it can work in
CMUCL when compiled, but cannot in Lispworks Persional Edition.
Why?
binghe wrote:
> This simple function:
> (defun int (n)
> (declare (type integer n))
> n)
>
> I want this function only accept a integer type argument, and it can work in
> CMUCL when compiled, but cannot in Lispworks Persional Edition.
>
> Why?
If you violate a type constraint in a declaration, you have lied
to the lisp compiler/evaluator and the result (by the standard)
is undefined.
http://www.lispworks.com/documentation/HyperSpec/Body/d_type.htm#type
An implementation is also permitted to ignore type declarations completely.
http://www.lispworks.com/documentation/HyperSpec/Body/03_ca.htm
Paul
>>>>> "binghe" == binghe <··············@gmail.com> writes:
binghe> This simple function:
binghe> (defun int (n)
binghe> (declare (type integer n))
binghe> n)
binghe> I want this function only accept a integer type argument, and it can work in
binghe> CMUCL when compiled, but cannot in Lispworks Persional Edition.
That is a CMUCL extension. If you really want to accept only
integers, use check-type.
Ray
Raymond Toy <···········@ericsson.com> writes:
> That is a CMUCL extension. If you really want to accept only
なるほど。:-)
> integers, use check-type.
>
> Ray
Thanks, that is why I love CMUCL...
--
GnuPG Key: 0xF7C63B10
In LW you can do
(defun int (n)
(declare (type integer n)
(optimize (safety 3)
(debug 3)))
n)
This declaration will ensure a type check
see
http://www.lispworks.com/documentation/lw445/LWUG/html/lwuser-89.htm#pgfId-886019
CL-USER 2 > (int "test")
Error: Variable N was declared type INTEGER but is being bound to value
"test"
1 (abort) Return to level 0.
2 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other
options
CL-USER 3 : 1 > :a
CL-USER 4 > (int 12)
12
CL-USER 5 >
Wade
binghe wrote:
> This simple function:
> (defun int (n)
> (declare (type integer n))
> n)
>
> I want this function only accept a integer type argument, and it can work in
> CMUCL when compiled, but cannot in Lispworks Persional Edition.
>
> Why?
>
>
Yes but.... (LWM)
CL-USER 1 > (defun int (x)
(declare (type integer x)
(optimize (safety 3) (debug 3)))
x)
INT
CL-USER 2 > (compile 'int)
INT
NIL
NIL
CL-USER 3 > (defun use-int (x)
(int x))
USE-INT
CL-USER 4 > (compile 'use-int)
USE-INT
NIL
NIL
CL-USER 5 > (defun use-int-2 (x)
(declare (type symbol x))
(int x))
USE-INT-2
CL-USER 6 > (compile 'use-int-2)
USE-INT-2
NIL
NIL
CL-USER 7 >
Now, you can argue that the compiler should have told you that at least
USE-INT-2 is bogus.
Cheers
--
Marco
PS. Please do not start with the "you lied to the compiler" crap. The
answer is that I am too stupid to lie to the compiler. The compiler
should be able to tell me that I am stupid.
Wade Humeniuk wrote:
> In LW you can do
>
> (defun int (n)
> (declare (type integer n)
> (optimize (safety 3)
> (debug 3)))
> n)
>
> This declaration will ensure a type check
>
> see
>
> http://www.lispworks.com/documentation/lw445/LWUG/html/lwuser-89.htm#pgfId-886019
>
>
> CL-USER 2 > (int "test")
>
> Error: Variable N was declared type INTEGER but is being bound to value
> "test"
> 1 (abort) Return to level 0.
> 2 Return to top loop level 0.
>
> Type :b for backtrace, :c <option number> to proceed, or :? for other
> options
>
> CL-USER 3 : 1 > :a
>
> CL-USER 4 > (int 12)
> 12
>
> CL-USER 5 >
>
>
> Wade
> binghe wrote:
>
>> This simple function:
>> (defun int (n)
>> (declare (type integer n))
>> n)
>>
>> I want this function only accept a integer type argument, and it can
>> work in
>> CMUCL when compiled, but cannot in Lispworks Persional Edition.
>>
>> Why?
>>
>>
Marco Antoniotti wrote:
> Yes but.... (LWM)
> Now, you can argue that the compiler should have told you that at least
> USE-INT-2 is bogus.
I would argue that the compiler does not have to do this. Since Lisp is
dynamic the definition of INT can change at any time, thus USE-INT-2 can
be valid in a past or future time though maybe not at the moment that
the compiler is compiling. This is the core and basic nature of Lisp.
It might be OK for the compiler to give you a warning but I really hate
that about compilers like CMUCL.
Wade
>
> Cheers
> --
> Marco
>
> PS. Please do not start with the "you lied to the compiler" crap. The
> answer is that I am too stupid to lie to the compiler. The compiler
> should be able to tell me that I am stupid.
>
>
>
> Wade Humeniuk wrote:
>
>> In LW you can do
>>
>> (defun int (n)
>> (declare (type integer n)
>> (optimize (safety 3)
>> (debug 3)))
>> n)
>>
>> This declaration will ensure a type check
>>
>> see
>>
>> http://www.lispworks.com/documentation/lw445/LWUG/html/lwuser-89.htm#pgfId-886019
>>
>>
>> CL-USER 2 > (int "test")
>>
>> Error: Variable N was declared type INTEGER but is being bound to
>> value "test"
>> 1 (abort) Return to level 0.
>> 2 Return to top loop level 0.
>>
>> Type :b for backtrace, :c <option number> to proceed, or :? for other
>> options
>>
>> CL-USER 3 : 1 > :a
>>
>> CL-USER 4 > (int 12)
>> 12
>>
>> CL-USER 5 >
>>
>>
>> Wade
>> binghe wrote:
>>
>>> This simple function:
>>> (defun int (n)
>>> (declare (type integer n))
>>> n)
>>>
>>> I want this function only accept a integer type argument, and it can
>>> work in
>>> CMUCL when compiled, but cannot in Lispworks Persional Edition.
>>>
>>> Why?
>>>
>>>
Wade Humeniuk <····················@telus.net> writes:
> Marco Antoniotti wrote:
>> Yes but.... (LWM)
>> Now, you can argue that the compiler should have told you that at
>> least USE-INT-2 is bogus.
>
> I would argue that the compiler does not have to do this. Since Lisp is
> dynamic the definition of INT can change at any time, thus USE-INT-2 can
> be valid in a past or future time though maybe not at the moment that
> the compiler is compiling. This is the core and basic nature of Lisp.
> It might be OK for the compiler to give you a warning but I really hate
> that about compilers like CMUCL.
Marco's example was bogus, but would your feeling have been if all
those definitions had been in a single file compiled with
CL:COMPILE-FILE?
Christophe
Christophe Rhodes wrote:
> Wade Humeniuk <····················@telus.net> writes:
>
>
>>Marco Antoniotti wrote:
>>
>>>Yes but.... (LWM)
>>>Now, you can argue that the compiler should have told you that at
>>>least USE-INT-2 is bogus.
>>
>>I would argue that the compiler does not have to do this. Since Lisp is
>>dynamic the definition of INT can change at any time, thus USE-INT-2 can
>>be valid in a past or future time though maybe not at the moment that
>>the compiler is compiling. This is the core and basic nature of Lisp.
>>It might be OK for the compiler to give you a warning but I really hate
>>that about compilers like CMUCL.
>
>
> Marco's example was bogus, but would your feeling have been if all
> those definitions had been in a single file compiled with
> CL:COMPILE-FILE?
>
Why should it be bogus? It could actually be argued that whe you are at
the listener, the compiler has "more access" to the current state of the
environment. I see no difference between the two cases.
Cheers
--
Marco
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Why should it be bogus? It could actually be argued that whe you are at
> the listener, the compiler has "more access" to the current state of the
> environment. I see no difference between the two cases.
It's bogus because ANSI explicitly specifies the circumstances in
which the compiler is permitted to assume that the compile-time
definition will remain in force at runtime, and explicitly specifies
that in other circumstances the compiler may not assume that the
compile-time definition of a function will remain in force at runtime.
Entering forms at the REPL and compiling them with COMPILE does not
allow the compiler to treat definitions as sealed, whereas using
COMPILE-FILE on a file with definition and use is one of those
situations. See CLtS 3.2.2.3.
Christophe
Christophe Rhodes wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
>
>>Why should it be bogus? It could actually be argued that whe you are at
>>the listener, the compiler has "more access" to the current state of the
>>environment. I see no difference between the two cases.
>
>
> It's bogus because ANSI explicitly specifies the circumstances in
> which the compiler is permitted to assume that the compile-time
> definition will remain in force at runtime, and explicitly specifies
> that in other circumstances the compiler may not assume that the
> compile-time definition of a function will remain in force at runtime.
>
> Entering forms at the REPL and compiling them with COMPILE does not
> allow the compiler to treat definitions as sealed, whereas using
> COMPILE-FILE on a file with definition and use is one of those
> situations. See CLtS 3.2.2.3.
>
The fact that ANSI specifies all of these concepts does not alter the
argument that it would be a good thing if a compiler were able to help
the programmer in his chores by warning of apparent signature mismatches.
After all, most of the specs in the relevant sections fall back on the
abhorred "implementation dependent" or "consequences undefined"
terminology. Hence, it is conceivable to desire a compiler that "did
the right thing" when dealing with different environment; meaning that
it signalled as many helpful warning as possible while not braking the
conformance requirement.
Yet again, I do not write compilers, so my opinion is only my 2cents :)
Cheers
--
Marco
Christophe Rhodes wrote:
> Wade Humeniuk <····················@telus.net> writes:
>
>
>> Marco Antoniotti wrote:
>>
>>> Yes but.... (LWM)
>>> Now, you can argue that the compiler should have told you that at
>>> least USE-INT-2 is bogus.
>>
>>
>> I would argue that the compiler does not have to do this. Since Lisp is
>> dynamic the definition of INT can change at any time, thus USE-INT-2 can
>> be valid in a past or future time though maybe not at the moment
that the compiler is compiling. This is the core and basic nature of Lisp.
>> It might be OK for the compiler to give you a warning but I really hate
>> that about compilers like CMUCL.
>
>
>
> Marco's example was bogus, but would your feeling have been if all
> those definitions had been in a single file compiled with
> CL:COMPILE-FILE?
>
Deep down I do not view files as a integral part of a Lisp. A Lisp
to me is an image, composed of objects, externally representable as
forms. In theory code could be written that exists within an
object database (or some other human accessible storage). So, no,
my feelings would not be any different. The compiler in a way
intrudes into the dynamic nature of Lisp if it does static like
checking (static in this meaning, determinable type checking).
When I code in Lisp I do not think in terms of the "type" of
the objects being used but their "meanings". Representation
is secondary to semantics. I would happier if the compiler
would signal warnings about what I mean, problems with my
representation will be found very quickly. Warnings about
types is just, well intrusive. When I code I usually write
a function, try evaluating it, test it a little, compile it,
unit test some more, so I am pretty sure everything will work.
This is one of the things I found disturbing about using CMUCL,
it was warning me about things before I was finished, and that
I knew were not finished, distracting me with trivial considerations.
Wade
Wade Humeniuk wrote:
> Marco Antoniotti wrote:
>
>> Yes but.... (LWM)
>> Now, you can argue that the compiler should have told you that at
>> least USE-INT-2 is bogus.
>
>
> I would argue that the compiler does not have to do this. Since Lisp is
> dynamic the definition of INT can change at any time, thus USE-INT-2 can
> be valid in a past or future time though maybe not at the moment that
> the compiler is compiling. This is the core and basic nature of Lisp.
> It might be OK for the compiler to give you a warning but I really hate
> that about compilers like CMUCL.
This is the usual line of argument. However, when (compile 'use-int-2)
was called, INT had a very specific signature.
Moreover, we are very well used to thinking of a CL system as an
environment. Practically all implementations have a WHO-CALLS vel
similia. Hence the compiler has access to this functionality as well.
It is true that to catch all the signature changes is difficult, but
because of the line of argument you are using, then we fall back to
catching none. I'd be happy to catch a few more.
OTOH, I am not in the business or hobby of CL compiler writing. So this
is just a desiderata on my part.
Cheers
--
Marco
>
> Wade
>
>>
>> Cheers
>> --
>> Marco
>>
>> PS. Please do not start with the "you lied to the compiler" crap.
>> The answer is that I am too stupid to lie to the compiler. The
>> compiler should be able to tell me that I am stupid.
>>
>>
>>
>> Wade Humeniuk wrote:
>>
>>> In LW you can do
>>>
>>> (defun int (n)
>>> (declare (type integer n)
>>> (optimize (safety 3)
>>> (debug 3)))
>>> n)
>>>
>>> This declaration will ensure a type check
>>>
>>> see
>>>
>>> http://www.lispworks.com/documentation/lw445/LWUG/html/lwuser-89.htm#pgfId-886019
>>>
>>>
>>> CL-USER 2 > (int "test")
>>>
>>> Error: Variable N was declared type INTEGER but is being bound to
>>> value "test"
>>> 1 (abort) Return to level 0.
>>> 2 Return to top loop level 0.
>>>
>>> Type :b for backtrace, :c <option number> to proceed, or :? for
>>> other options
>>>
>>> CL-USER 3 : 1 > :a
>>>
>>> CL-USER 4 > (int 12)
>>> 12
>>>
>>> CL-USER 5 >
>>>
>>>
>>> Wade
>>> binghe wrote:
>>>
>>>> This simple function:
>>>> (defun int (n)
>>>> (declare (type integer n))
>>>> n)
>>>>
>>>> I want this function only accept a integer type argument, and it can
>>>> work in
>>>> CMUCL when compiled, but cannot in Lispworks Persional Edition.
>>>>
>>>> Why?
>>>>
>>>>