Hi, there!
I cannot write this without the parser complaining:
number caseOf: { 0 -> 1. 1 -> 1. } otherwise: { ... }.
Because what I should write is this:
number caseOf: { [0] -> [1]. [1] -> [1]. } otherwise: { ... }.
I think that this is not for the parser to decide. Numbers do understand #value. Any object does. So this is fine. Am I missing something?
It reminds me of this mistake our students typically make at least once:
(someBooleanExpression) and: (someOtherBooleanExpression) versus (someBooleanExpression) and: [someOtherBooleanExpression] versus [someBooleanExpression] and: (someOtherBooleanExpression) versus [someBooleanExpression] and: [someOtherBooleanExpression]
Sure, we can offer tool support to help in such situations. But the parser is just too naggy. :-)
Best, Marcel
-- View this message in context: http://forum.world.st/caseOf-otherwise-Parser-is-way-too-cautious-tp4897986.... Sent from the Squeak - Dev mailing list archive at Nabble.com.
marcel.taeumel wrote
Hi, there!
I cannot write this without the parser complaining:
number caseOf: { 0 -> 1. 1 -> 1. } otherwise: { ... }.
Because what I should write is this:
number caseOf: { [0] -> [1]. [1] -> [1]. } otherwise: { ... }.
I think that this is not for the parser to decide. Numbers do understand #value. Any object does. So this is fine. Am I missing something?
It reminds me of this mistake our students typically make at least once:
(someBooleanExpression) and: (someOtherBooleanExpression) versus (someBooleanExpression) and: [someOtherBooleanExpression] versus [someBooleanExpression] and: (someOtherBooleanExpression) versus [someBooleanExpression] and: [someOtherBooleanExpression]
Sure, we can offer tool support to help in such situations. But the parser is just too naggy. :-)
Best, Marcel
Okay, this was stoopid. ;o) I assumed an implicit comparison:
number caseOf: { [number = 0] -> [1]. [number = 1] -> [1]. } otherwise: { ... }.
Still, no need to force the result also into a block? Why not just modify the implementation of #caseOf:otherwise: to make such comparisons if there is no block given?
Goal: Avoid nested iftrue-iffalse calls. Is there something more Smalltalk-ish? Or functional? Is there some pattern matching hidden somewhere?
Best, Marcel
-- View this message in context: http://forum.world.st/caseOf-otherwise-Parser-is-way-too-cautious-tp4897986p... Sent from the Squeak - Dev mailing list archive at Nabble.com.
On 29.05.2016, at 10:59, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
marcel.taeumel wrote
Hi, there!
I cannot write this without the parser complaining:
number caseOf: { 0 -> 1. 1 -> 1. } otherwise: { ... }.
Because what I should write is this:
number caseOf: { [0] -> [1]. [1] -> [1]. } otherwise: { ... }.
I think that this is not for the parser to decide. Numbers do understand #value.
Only since recently. Still not sure it’s a good idea.
Any object does. So this is fine. Am I missing something?
It reminds me of this mistake our students typically make at least once:
(someBooleanExpression) and: (someOtherBooleanExpression) versus (someBooleanExpression) and: [someOtherBooleanExpression] versus [someBooleanExpression] and: (someOtherBooleanExpression) versus [someBooleanExpression] and: [someOtherBooleanExpression]
Sure, we can offer tool support to help in such situations. But the parser is just too naggy. :-)
Best, Marcel
Okay, this was stoopid. ;o) I assumed an implicit comparison:
number caseOf: { [number = 0] -> [1]. [number = 1] -> [1]. } otherwise: { ... }.
Still, no need to force the result also into a block? Why not just modify the implementation of #caseOf:otherwise: to make such comparisons if there is no block given?
This is exactly the reason we resisted adding Object>>value for a long time, because it hides errors. E.g. your use of {} in the otherwise-case, which is wrong. Each case should be evaluated only when the matching condition is true, hence the need to use a block. Arguably the compiler should warn about not using a block as argument to ‘otherwise:'.
Perhaps a more Smalltalky way could be added if allowed binary and unary messages to cascade:
number = 0 => [24]; = 1 => [42]; else => ['hi']
Btw this is how things worked in Smalltalk-76/78:
- Bert -
Bert Freudenberg wrote
On 29.05.2016, at 10:59, marcel.taeumel <
Marcel.Taeumel@
> wrote:
marcel.taeumel wrote
Hi, there!
I cannot write this without the parser complaining:
number caseOf: { 0 -> 1. 1 -> 1. } otherwise: { ... }.
Because what I should write is this:
number caseOf: { [0] -> [1]. [1] -> [1]. } otherwise: { ... }.
I think that this is not for the parser to decide. Numbers do understand #value.
Only since recently. Still not sure it’s a good idea.
Any object does. So this is fine. Am I missing something?
It reminds me of this mistake our students typically make at least once:
(someBooleanExpression) and: (someOtherBooleanExpression) versus (someBooleanExpression) and: [someOtherBooleanExpression] versus [someBooleanExpression] and: (someOtherBooleanExpression) versus [someBooleanExpression] and: [someOtherBooleanExpression]
Sure, we can offer tool support to help in such situations. But the parser is just too naggy. :-)
Best, Marcel
Okay, this was stoopid. ;o) I assumed an implicit comparison:
number caseOf: { [number = 0] -> [1]. [number = 1] -> [1]. } otherwise: { ... }.
Still, no need to force the result also into a block? Why not just modify the implementation of #caseOf:otherwise: to make such comparisons if there is no block given?
This is exactly the reason we resisted adding Object>>value for a long time, because it hides errors. E.g. your use of {} in the otherwise-case, which is wrong. Each case should be evaluated only when the matching condition is true, hence the need to use a block. Arguably the compiler should warn about not using a block as argument to ‘otherwise:'.
Perhaps a more Smalltalky way could be added if allowed binary and unary messages to cascade:
number = 0 => [24]; = 1 => [42]; else => ['hi']
Btw this is how things worked in Smalltalk-76/78:
- Bert -
Screenshot 2016-05-30 12.48.12.png (4K) <http://forum.world.st/attachment/4898099/0/Screenshot%202016-05-30%2012.48.1...; smime.p7s (5K) <http://forum.world.st/attachment/4898099/1/smime.p7s%3E;
Hi Bert,
the debugger revealed my "otherwise: { ... }" mistake pretty quickly.
Thanks for the Smalltalk-72 example.
Best, Marcel
-- View this message in context: http://forum.world.st/caseOf-otherwise-Parser-is-way-too-cautious-tp4897986p... Sent from the Squeak - Dev mailing list archive at Nabble.com.
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
marcel.taeumel