Re: [Chicken-hackers] Pessimizing undefined behavior

[megane]

address@hidden writes:

>> > No, but it could, depending on some arcane optimization that someone
>> > may implement in the future (or not). It's simply open to the 
>> > implementation.
>> >
>>
>> There's the possiblity of documenting this optimization:
>>
>> "If the expression's value can be determined statically to be undefined
>> the value will be considered truthy. Otherwise the value can be
>> anything, including false."
>>
>> Considering undefined as truthy value have two benefits:
>
> I find both these sentences awkward and counterintuitive in their wording,
> which gives me the impression that something is wrong: either something
> is undefined or it is "truthy" (or finite, or NaN, or unaligned, or whatever).
> It can't be both. Otherwise you subvert the very term "undefined".

The truthyness of undefined is only considered when statically dropping
branches for if expressions. Nothing else. See always-true.

The R5RS says (1.3.2) that the value of an expression with undefined
(actually "unspecified") value has to be a valid scheme value
("object"), and it's up to the implementation what that value is. It
doesn't even have to be the same value from call to call.

I feel this gives us the freedom to do any of these (not an exhaustive
list):
- Always consider undefined to be truthy (currently this)
- Always consider undefined to be false
- Consider undefined to be true or false according to the phase of the
moon at the runtime

Also we can choose whether or not to inform the user what the actual
value is (we don't).

Nothing changes if we statically assign these values, the user still
cannot rely on undefined to be either true or false.

We could legally statically consider undefined to be true or false at
random, but always consider it true at runtime. (This would probably
still give all the static type checking benefits. The messages would
just be changing between compilations.)

The patch only behaves statically according to the current
implementation choice. If the implementation changes we can change the
truthyness, but we don't have to.

I hope it's obvious now if I'm misunderstanding something.

[...]
>> Secondly, this enables the scrutinizer to find more bugs. For example
>> this code doesn't give any warnings, even with -verbose:
>>
>>   (+ 1 (if (print 1) 'a 1))
>>
>> With the patch there would be a note for always true value in
>> conditional _and_ warning for passing a symbol to +.
>
> Sure, that could even be considered a benefit. Yet, I'd rather see removing
> the "undefined" status altogether from forms like that than make it mean 
> something
> specific in some specific cicumstances.

I don't understand this. What do you mean by "removing undefined
status"?

>
>
> felix