Thank you for your reply.

I corresponded about the (car 0) issue with Marc Nieper-Wißkirchen on
the SRFI-145 mailing list, who wrote [1] :

"(car 0) is only a hack to have something like GCC's
__builtin_unreachable. In a particular implementation, it should be
replaced by somethin g more specific that guides the control-flow
optimization (by telling that this point will never be reached)."

But setting aside the SRFI-145 issue, is there some indication of what
could be causing the assumptions not to hold or how the could be fixed?

Many thanks.

  --Sergey

[1] - https://srfi-email.schemers.org/srfi-145/msg/15470833/

On Wed 11 Nov 2020 10:31:09 AM +02, Arvydas Silanskas wrote:
>
> It looks like (car 0) is being used in a fallback to srfi 145 to fail when
> given assumption isn't true
> https://github.com/diamond-lizard/srfi-207/blob/main/srfi/207.sld#L43 .
>
> Arvydas
>
> 2020-11-11, tr, 10:07 <xxxxxx@mailc.net> rašė:
>
>> When trying to port SRFI-207 to Chicken 5.2.0, I am getting many
>> warnings about invalid types, such as the one I quote below.
>>
>> I have logged the details here:
>>
>>   https://github.com/diamond-lizard/srfi-207/issues/1
>>
>> The GitHub repo which contains the reference implementation port to
>> Chicken 5 that generated these warnings is here:
>>
>>   https://github.com/diamond-lizard/srfi-207/
>>
>> Here is a sample of the kind of warning I'm getting:
>>
>> Warning: Invalid argument
>>   In file `srfi/207/parse.scm:88',
>>   In module `srfi-207',
>>   In procedure `read-textual-bytestring',
>>   In procedure call:
>>
>>     (scheme#car 0)
>>
>>   Argument #1 to procedure `car' has an invalid type:
>>
>>     fixnum
>>
>>   The expected type is:
>>
>>     pair
>>
>>   This is the expression:
>>
>>     0
>>
>>   Procedure `car' from module `scheme' has this type:
>>
>>     ((pair 'a *) -> 'a)
>>