Re: [Chicken-users] handling the undefined value

[Felix]

From: Jörg "F. Wittenberger" <address@hidden>
Subject: Re: [Chicken-users] handling the undefined value
Date: Thu, 25 Nov 2010 22:42:15 +0100

> Am Donnerstag, den 25.11.2010, 22:34 +0100 schrieb Felix:
>> From: Jörg "F. Wittenberger" <address@hidden>
>> Subject: Re: [Chicken-users] handling the undefined value
>> Date: Thu, 25 Nov 2010 16:24:01 +0100
>> 
>> > Am Mittwoch, den 24.11.2010, 18:53 +0100 schrieb Felix:
>> >> From: Jörg "F. Wittenberger" <address@hidden>
>> >> Subject: Re: [Chicken-users] handling the undefined value
>> >> Date: Mon, 22 Nov 2010 15:08:46 +0100
>> >> 
>> >> > Have a compiler switch (since it may break some code), which changes the
>> >> > code to return zero values instead of the distinguished undefined value.
>> >> 
>> >> I don't think this is a great idea: this will change the
>> >> semantics of code using call-with-values,
>> > 
>> > So far I did not come around to test, whether or not I'll be able to
>> > find my undefined value with the new scrutinizer version.
>> 
>> Unfortunately I had to disable this feature again. We probably need
>> some sort of "style" warning switch (there are too many places where
>> procedures without result or undefined result use forms like `when').
> 
> Sadly.
> 
> The "style" warning I'd like to avoid if all possible.

Me too.

> 
> I'd rather vote for changing the syntax definitions (one-by-one, tell me
> the git/svn/wtf reference and I'll try my best).

Don't bother with it. There are quite a number of situations where 
a a conditional with an undefined branch must appear in tail-position.

> 
>> > This however I don't understand.  Why would it be less efficient to call
>> > a continuation with zero instead of one value?
>> 
>> There is a bit of wrapping and result-value count checking going on
>> behind the scenes in that case.
> 
> I see.  I understand: could be as efficient, but that would need quite a
> lot of other changes.  Right?
> 

Yes, a lot of changes.


cheers,
felix