Re: [Chicken-hackers] Pessimizing undefined behavior

[felix . winkelmann]

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

>
> First, even if this optimization you speak of is implemented the user's
> code would still stay deterministic for the parts that can be statically
> analyzed. So if the undefined is sometimes a #f and that uncovers a bug
> it will be easier to debug.

I don't disagree with the technicalities but with the conceptual problem.

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


felix