#caseOf:otherwise: -> Parser is way too cautious

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

On 29.05.2016, at 10:59, marcel.taeumel <[hidden email]> 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.

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?

smime.p7s (5K) Download Attachment

Bert Freudenberg wrote

> On 29.05.2016, at 10:59, marcel.taeumel <[hidden email]> 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.12.png>
smime.p7s (5K) <http://forum.world.st/attachment/4898099/1/smime.p7s>