Re: [Chicken-hackers] Pessimizing undefined behavior

[megane]

John Cowan <address@hidden> writes:

> On Mon, Apr 1, 2019 at 11:26 PM megane <address@hidden> wrote:
>
> When the scrutinizer walks (begin) it knows the returned value is
>> undefined.
[...]
>
> In Scheme, whoever writes (begin) in a value context, even as a result
> of macro expansion, is almost certainly making a mistake,
> and the Right Thing IMO is to report an error, not to pessimize the
> code.

Totally agree with this.

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

My reasoning for the patch was that "this is just what is happening any
way". Why keep the dead code around?

But yes, drop the optimization. It won't have much effect.

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.

Based on this the patch wouldn't have had any observable program
behavior change. The C compiler backend probably does the same
optimizations for trivial cases anyway.

If some future compiler optimization makes the values of undefined
expressions truly undefined/abitrary then things change. Then the false
branch might become chosen randomly at times.

My preferences for handling undefined types:

1. Compile time error with some compiler flag (e.g. -give-me-some-errors)

2. Compile time warning + throw a runtime error.

3. (This patch) Compile time warning + consider as truthy.

3.01. (Currently) Compile time warning.

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 :)