Re: [Chicken-hackers] Pessimizing undefined behavior

[megane]

address@hidden writes:

>> 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.

Yes, I'm talking about my own preferences. Sorry about the confusion.
I'm not trying to change CHICKEN to turn these type warnings into errors
for everybody else in the normal operation mode.

I would only suggest adding a compiler flag to turn "clearly wrong"
cases into something that stops the compilation. I cannot be the only
one who would find this feature helpful. I'll try not to push this
feature too hard, but it's so hard :).

(I want to see the warnings/errors as I change the code. And as I have
quite a lot of code I will miss those messages if I blink at the wrong
time. That's why I have turned those warnings into errors. Other option
could be a shell script grepping for warnings and stopping the party if
anything is found.)

>
>> 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.

You mean the compiler currently sometimes returns #f for (begin)?

If that's the case then this optimization would have been totally wrong.
My intention was not to change the behaviour of CHICKEN programs in any
way.

>> 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.

Agree on the reverting part. I would be very unhappy if CHICKEN started
to, for example evaluating call arguments in random/parallel order. Or
if 'map' started to map elements in arbitrary order. Lot's of things
would break even if the standard says you shouldn't have relied on a
specific order.

>
> 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.

Totally agree.

>
> 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.

Yeah, R5RS only says expression having unspecified value has to return
some object without an error. It's up to the implementation what object
that should be.

And, as I took a look at the spec, I saw that we've been talking about
_unspecified_, not _undefined_ (used in 7.2).