Re: [Chicken-hackers] regression - probably in let*

[Jörg F. Wittenberger]

Am 19.06.2015 um 10:36 schrieb address@hidden:
>> Am 18.06.2015 um 15:00 schrieb address@hidden:
>>>> thanks for your confirmation.  So it's -strict-types.  Maybe the test
>>>> should go into the test suite to prevent the issue sneaking into future
>>>> releases.
>>>>
>>>> (As for -unsafe: that's actually reasonable behavior.  After all -unsafe
>>>> was requested.)
>>>
>>> -strict-types is dangerous and unintuitive,
>>
>> Dangerous: I see, I've just been caught.  Though it did work perfectly
>> for me for maybe five years or so.
>>
>> But what's unintuitive about it?
> 
> It makes certain assumptions about variable types and can be easily 
> confused. Basically, the declaration states that a variable always
> is of the same type, but there is no indication that shows you a problem
> in case you violate that constraint.

I recall having seen several warnings (or where them errors; I treated
them like the latter) telling me about violations of strict type rules.

> 
>> But if it's really better not being used, why is it still supported by
>> CHICKEN?
> 
> A good question. We should probably get rid of it.

I'd like to keep it.

I know that the language compiled with strict types is only a strict
subset of Scheme.  A subset which I want to enforce sometimes.  When I
move things from a Scheme prototype into a C implementation, one of the
things I have to do is get rid of the assumption of dynamic types.
Compiling with strict types helps a lot.

Furthermore doing so allows me to get rid of most if not all internal
type checks generated by the compiler.  This gives me already a rough
expectation how much gain is to be expected by converting to C and the
other way around how expensive the next step, the addition of type
checks around the C code (using the enforce-argument-types declaration),
will cost.

Since strict types does already restrict Scheme, I could even live with
more restrictions.  For the example at hand:  This does not break the
strict types assumption.  (At lest not for the "reuse" binding; I just
noticed that the result of my test case actually does.  Hm, that's been
the made up part when stripping down the original code.)  The problem
seems to be related to having the side effect in that loop.  Changing a
#t to a #f, which was eventually ignored.  I'd rather document an
additional constraint for strict types like "no side effects".  (Though
I believe that's overly strict.)

Best

/Jörg