Steel Bank Common Lisp

On 15-Sep-08, at 3:24 PM, Tobias C. Rittweiler wrote:
> A similiar example is MAKE-DISPATCH-MACRO-CHARACTER whose fndb entry  
> is:
>
>  make-dispatch-macro-character (character &optional t readtable)
>
> And, indeed, the following
>
>  (make-dispatch-macro-character #\^ nil nil)
>
> signals an error. The error message "The value 638976 is not of type
> LIST." indicates that something really quirky is going on, though.

It seems to me that's is a synmptom of two quirks in Python. First,  
function declaration are implicitly trusted, and not turned into  
assertions (in the callee for arguments or in the caller for return  
values). Thus, the code for make-dispatch-macro-character implicitly  
assumes that its readtable argument is a readtable. A declaration in  
the definition of m-d-m-c etc should fix that problem (at least, it  
makes your test case behave correctly).

Second, it is surprising that no warning is signaled for the type  
mismatch between the declaration & the use of m-d-m-c. When the same  
form is wrapped in a lambda, the full compiler is used and a compile- 
time warning is signaled (and the call compiled into an ERROR). When  
the form appears at the toplevel, (most of?) the analyses are skipped  
and the fndb entry ignored. The compiler simply assumes that the  
function is always safe to call (and, if the declaration were right, I  
believe that any consequence for type mismatches would be, strictly  
speaking, standard compliant).

Thank you for diving in there!

Paul Khuong

Paul Khuong <pkhuong@...> writes:

> It seems to me that's is a synmptom of two quirks in Python. First,  
> function declaration are implicitly trusted, and not turned into  
> assertions (in the callee for arguments or in the caller for return  
> values). Thus, the code for make-dispatch-macro-character implicitly  
> assumes that its readtable argument is a readtable. A declaration in  
> the definition of m-d-m-c etc should fix that problem (at least, it  
> makes your test case behave correctly).

I have to confess that I do not understand this paragraph. Could you
elaborate on it, please? You first say "function declarations" are not
turned into assertions, but then adding a "declaration" should fix the
problem, i.e. generate an assertion.

  -T.

On 16-Sep-08, at 6:04 AM, Tobias C. Rittweiler wrote:
> Paul Khuong <pkhuong@...> writes:
>> It seems to me that's is a synmptom of two quirks in Python. First,
>> function declaration are implicitly trusted, and not turned into
>> assertions (in the callee for arguments or in the caller for return
>> values). Thus, the code for make-dispatch-macro-character implicitly
>> assumes that its readtable argument is a readtable. A declaration in
>> the definition of m-d-m-c etc should fix that problem (at least, it
>> makes your test case behave correctly).
>
> I have to confess that I do not understand this paragraph. Could you
> elaborate on it, please? You first say "function declarations" are not
> turned into assertions, but then adding a "declaration" should fix the
> problem, i.e. generate an assertion.

That was a bit unclear, and not quite right. What I meant was that  
when something is declared to be of a (function ...) type, that  
declaration isn't checked, but still trusted. In particular, it's  
assumed that if the call to a (function (foo) ...) returns, then the  
first argument must be of type foo! So in make-dispatch-macro- 
character, what happens is that some of the defknowned argument types  
(those of non-required arguments?) are ignored during the compilation  
of m-d-m-c and set-macro-character. However, m-d-m-c assumes the  
declared function type of set-macro-character is right, so code that  
executes after the call to s-m-c does not check that rt is a  
readtable. The problem is that set-macro-character also returns  
successfully when rt is NIL, even though it was declared that it must  
be a readtable. Declaring the type of optional arguments in (defun  
make-dispatch-macro-character) and (defun set-macro-character) would  
make the compiler emit type checks for them too.

Paul Khuong