Re: [Chicken-hackers] [PATCH] two scrutinizer fixes

[Felix]

> On Mon, Nov 05, 2012 at 08:15:31PM +0100, Felix wrote:
>> a) when matching "list-of"/"vector-of" with "list"/"vector", each
>>    element of the latter must match the element-type of the former
>>    (reported by megane, fixes #948). Previously the "list"/vector"
>>    type was matched as "(list-of (or ...))" instead, which makes
>>    the match less precise.
> 
> The patch looks like it's the correct way to fix the example.
> However, I'm not sure, but doesn't this still go wrong in the case a
> list is matched against a pair?
> 
> A small change in the test causes the compiler to accept the program
> silently; just change (apply1 + (list 'a 2 3)) to
> (apply1 + (cons 'a (cons 2 '()))).  AFAIK this is just the same problem:
> pairs are converted to a (list-of (or symbol fixnum)).
> 
> I tried to fix it first in the case in the same place you changed, but
> I think it never gets there due to the clause before it:
> 
> (and (pair? t2) (eq? 'pair (car t2))) precedes
> (and (pair? t1) (eq? 'list-of (car t1))) so checking for a pair type
> on t2 is pointless since it will never match (unless I'm missing
> something) due to the former path already having been taken.
> 
> I messed around in the code a bit more, but was unable to come up with
> an effective patch :(

I'll do that later, in a different patch. You can create a ticket for
this and assign it to me if you like.

> 
>> b) when matching result-types, allow "undefined" to match "noreturn"
>>    as the "noreturn" property can not be inferred for foreign procedures
>>    (for example) in general
> 
> Shouldn't this only be the case when doing a non-strict type match?
> ie, when (not exact) is true?  I admit, I'm still a little unclear on
> how exact is supposed to work...

Strict is only required for compiler-typecase and for specialization,
also, whether a procedure is noreturn or not has actually nothing to
do with the type (undefined is just as good). So, I think this is ok
(to treat "noreturn" like "undefined" here), since it's not incorrect.

> 
>> Additionally, when converting the internal node tree in the compiler
>> to expressions, internal type-declaration forms are not shown to
>> reduce clutter in the output (this is just a cosmetic change).
> 
> Only in debugging mode, when the user has uncommented the define-syntax
> that disables the debugging stuff, right?

No, it's for the code-fragments created in error messages (like
the ones from the scrutinizer).


cheers,
felix