Re: [Chicken-hackers] Pessimizing undefined behavior
On Thu, Apr 4, 2019 at 11:41 AM megane wrote:
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.
That's true. But a violation of syntax, which (begin) is, is what the
RnRS calls "an error", which is the same as "undefined behavior"
in other standards. The program can misbehave in arbitrary ways,
and in particular the compiler is free to reject such programs
(which amounts to a failure before the program starts to run).
This is the same case as (car 1) or (substring "abc" n (- n 1))
or (let ((x 10) (x 20) ) x) or in particular (if #t).
It is completely different from (set! x 32) which returns an
unspecified value, the case you describe above.
--
John Cowan http://vrici.lojban.org/~cowanco...@ccil.org
Half the lies they tell about me are true.
--Tallulah Bankhead, American actress
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Pessimizing undefined behavior
> > Once you give a fixed meaning, even by doing an optimization based > > on this meaning, users _will_ start to rely on it. At that stage it isn't > > undefined anymore. > > There's two ways I can think of getting warnings, then. > > a) Easy version. Randomly choose true or false at each if. Use some > method that keeps the builds deterministic. This wouldn't assign any > more fixed meaning for undefined than there currently is. > > b) Add special code to handle undefined in ifs. Adds one more of those > type tree walkers. May not be entirely trivial. Any takers? I think this is getting out of hand... I'm not suggesting to do anything like this, of course. Just leave things as they are, take more care when warnings scroll by, keep your own fork or consider a "treat-warnings-as-errors" switch. I don't see a serious problem with the way things are currently implemented. My point is that "undefined" should have no ad-hoc _definition_ of "truthiness", whether this means documentation or some fixed compile-time semantics. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Pessimizing undefined behavior
megane writes: > felix.winkelm...@bevuta.com writes: > >>> >>> Nothing changes if we statically assign these values, the user still >>> cannot rely on undefined to be either true or false. >> >> Once you give a fixed meaning, even by doing an optimization based >> on this meaning, users _will_ start to rely on it. At that stage it isn't >> undefined anymore. > > There's two ways I can think of getting warnings, then. > > a) Easy version. Randomly choose true or false at each if. Use some > method that keeps the builds deterministic. This wouldn't assign any > more fixed meaning for undefined than there currently is. It would have to be constant true/false for the whole compilation. Otherwise, bugs. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Pessimizing undefined behavior
felix.winkelm...@bevuta.com writes: >> >> Nothing changes if we statically assign these values, the user still >> cannot rely on undefined to be either true or false. > > Once you give a fixed meaning, even by doing an optimization based > on this meaning, users _will_ start to rely on it. At that stage it isn't > undefined anymore. There's two ways I can think of getting warnings, then. a) Easy version. Randomly choose true or false at each if. Use some method that keeps the builds deterministic. This wouldn't assign any more fixed meaning for undefined than there currently is. b) Add special code to handle undefined in ifs. Adds one more of those type tree walkers. May not be entirely trivial. Any takers? ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Pessimizing undefined behavior
> > Nothing changes if we statically assign these values, the user still > cannot rely on undefined to be either true or false. Once you give a fixed meaning, even by doing an optimization based on this meaning, users _will_ start to rely on it. At that stage it isn't undefined anymore. > > 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"? Return a defined value in all cases. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Pessimizing undefined behavior
felix.winkelm...@bevuta.com 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
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Pessimizing undefined behavior
> > 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 ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Pessimizing undefined behavior
megane writes: > felix.winkelm...@bevuta.com writes: > >>> >> 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)? >> >> 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." Maybe this is better: "In conditionals an expression having an undefined value can be considered either true or false. This may cause the true or false branch to be dropped." ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Pessimizing undefined behavior
felix.winkelm...@bevuta.com writes: >> >> 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)? > > 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: 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. 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 +. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
