Re: [Chicken-hackers] Pessimizing undefined behavior

[felix . winkelmann]

> And it has to be error, not just a warning. Otherwise the warning just
> flashes by while you're getting some coffee.

That's the point - it is an error under your interpretation only. It's
still perfectly legal code, even if it may not make sense.

> Based on my limited observations (##core#undefined) will always have
> the value 30L at runtime. This is not equal to 6L (or #f). Therefore
> an undefined value in conditional test will always cause the true
> branch to be chosen.

That's an implementation artefact, (begin) may also return #f, which would
be legal according to the standard. "Undefined" is not a value nor a type.

> I have my local branch set up to always throw errors when passing
> undefined to 'if' or function calls. The 4th patch in this patch set was
> found that way as CHICKEN wouldn't compile. I also found several bugs in
> the sdl2 egg through the errors, too. Types are helpful :)

I totally agree that they are helpful. I also agree that the user should be
informed about this. But settling on a particular interpretation can lead
to users to rely on this interpretation and it is hard to revert such a change.

Rejecting the code on the other hand is in my opinion overly strict
and may lead to surprises or force to use workarounds that are even more
pointless than relying on "undefined" being true.

My basic point is that "undefined" is nothing that should have any strict
interpretation, even though it may evaluate to some constant X. That's
why it has been considered "undefined" in the first place.


felix