Am 19.06.2015 um 10:36 schrieb [email protected]: >> Am 18.06.2015 um 15:00 schrieb [email protected]: >>>> 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 _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
