Question about #caseOf:otherwise:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about #caseOf:otherwise:

marcel.taeumel
Hi all!

Why isn't the following example possible?

aNumber caseOf: {
   [:n | n even] -> ['That is an even number.'].
   [:n | n odd] -> ['That is an odd number.'].
}.

That is, why is the check "assoc key value = self" not configurable as "(x := assoc key cull: self) == true or: [x = self]"? :-)

... maybe it is a good thing that case-of statements in Smalltalk are not that powerful?

Best,
Marcel


Reply | Threaded
Open this post in threaded view
|

Re: Question about #caseOf:otherwise:

Christoph Thiede

Sounds very interesting :)


In the past I have been writing the following instead:


true caseOf: {

    [aNumber isEven] -> ['That is an even number.'].

    [aNumber isOdd] -> ['That is an odd number.']. 

}.


but your code is much more beautiful :)

I think both variants have a contrary semantic, but on the other hand it just reads intuitive:


aNumber caseOf: {
   [42] -> ['That is correct.'].
   [:n | n even] -> ['That is an even number.'].
   [:n | n odd] -> ['That is an odd number.'].
}.


This would also require some changes to the Parser. If your examples compiles, I would also expect the following to run:

aNumber caseOf: {
   #even -> ['That is an even number.'].
   #odd -> ['That is an odd number.'].
}.

Best,
Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Donnerstag, 15. August 2019 10:32:07
An: gettimothy via Squeak-dev
Betreff: [squeak-dev] Question about #caseOf:otherwise:
 
Hi all!

Why isn't the following example possible?

aNumber caseOf: {
   [:n | n even] -> ['That is an even number.'].
   [:n | n odd] -> ['That is an odd number.'].
}.

That is, why is the check "assoc key value = self" not configurable as "(x := assoc key cull: self) == true or: [x = self]"? :-)

... maybe it is a good thing that case-of statements in Smalltalk are not that powerful?

Best,
Marcel


Reply | Threaded
Open this post in threaded view
|

Re: Question about #caseOf:otherwise:

Jakob Reschke-2
Am Do., 15. Aug. 2019 um 11:20 Uhr schrieb Thiede, Christoph <[hidden email]>:

true caseOf: {

    [aNumber isEven] -> ['That is an even number.'].

    [aNumber isOdd] -> ['That is an odd number.']. 

}.

Lisp cond? ;-)



Reply | Threaded
Open this post in threaded view
|

Re: Question about #caseOf:otherwise:

Levente Uzonyi
In reply to this post by Christoph Thiede
On Thu, 15 Aug 2019, Thiede, Christoph wrote:

>
> Sounds very interesting :)
>
>
> In the past I have been writing the following instead:
>
>
> true caseOf: {
>
>     [aNumber isEven] -> ['That is an even number.'].
>
>     [aNumber isOdd] -> ['That is an odd number.']. 
>
> }.
>
>
> but your code is much more beautiful :)
>
> I think both variants have a contrary semantic, but on the other hand it just reads intuitive:
>
>
> aNumber caseOf: {
>    [42] -> ['That is correct.'].
>    [:n | n even] -> ['That is an even number.'].
>    [:n | n odd] -> ['That is an odd number.'].
> }.
>
>
> This would also require some changes to the Parser. If your examples compiles, I would also expect the following to run:
>
> aNumber caseOf: {
>    #even -> ['That is an even number.'].
>    #odd -> ['That is an odd number.'].
> }.
While you could expect that to compile, the Parser is strict about the
format, because everything (blocks, associations, the array) will be
inlined, so no objects will be created for them. Without inlining, such
construct would not be viable performance-wise.

Levente

>
> Best,
> Christoph
>
> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________
> Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
> Gesendet: Donnerstag, 15. August 2019 10:32:07
> An: gettimothy via Squeak-dev
> Betreff: [squeak-dev] Question about #caseOf:otherwise:  
> Hi all!
>
> Why isn't the following example possible?
>
> aNumber caseOf: {
>    [:n | n even] -> ['That is an even number.'].
>    [:n | n odd] -> ['That is an odd number.'].
> }.
>
> That is, why is the check "assoc key value = self" not configurable as "(x := assoc key cull: self) == true or: [x = self]"? :-)
>
> ... maybe it is a good thing that case-of statements in Smalltalk are not that powerful?
>
> Best,
> Marcel
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Question about #caseOf:otherwise:

Stéphane Rollandin
In reply to this post by marcel.taeumel
Le 15/08/2019 à 10:32, Marcel Taeumel a écrit :

> Hi all!
>
> Why isn't the following example possible?
>
> aNumber caseOf: {
> *[:n | n even]* -> ['That is an even number.'].
> * [:n | n odd]* -> ['That is an odd number.'].
> }.
>
> That is, why is the check "assoc key value = self" not configurable as
> "(x := assoc key cull: self) == true or: [x = self]"? :-)
>

The semantics would then change, because multiple tests could return
true, and then it would have to be clear if only one case is taken into
account, and which one (for example, the first), or if all cases are
considered and then all associated blocks are evaluated (sequencially?).

So while nice, it seems to me that this proposal opens a can of worms...

My 2 cents,

Stef

Reply | Threaded
Open this post in threaded view
|

Re: Question about #caseOf:otherwise:

Levente Uzonyi
On Thu, 15 Aug 2019, Stéphane Rollandin wrote:

> Le 15/08/2019 à 10:32, Marcel Taeumel a écrit :
>> Hi all!
>>
>> Why isn't the following example possible?
>>
>> aNumber caseOf: {
>> *[:n | n even]* -> ['That is an even number.'].
>> * [:n | n odd]* -> ['That is an odd number.'].
>> }.
>>
>> That is, why is the check "assoc key value = self" not configurable as
>> "(x := assoc key cull: self) == true or: [x = self]"? :-)
>>
>
> The semantics would then change, because multiple tests could return
> true, and then it would have to be clear if only one case is taken into
> account, and which one (for example, the first), or if all cases are
> considered and then all associated blocks are evaluated (sequencially?).
>
> So while nice, it seems to me that this proposal opens a can of worms...
No, it doesn't, because the semantics are clear: only the first matching
branch is considered.

| a b c d |
a := 1.
b := 2.
c := 1.
d := c caseOf: {
  [ a ] -> [ 'a' ].
  [ b ] -> [ 'b' ].
  [ c ] -> [ 'c' ] }.
self assert: d = 'a'

Levente

>
> My 2 cents,
>
> Stef
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Question about #caseOf:otherwise:

Christoph Thiede
In reply to this post by Levente Uzonyi
Why can't we apply the "hybrid" solution from #ifNotNil: here? Afaik the argument is inlined if it's a block, otherwise not. Specifying something inefficient is not recommended, but possible.


Von: Levente Uzonyi
Gesendet: Donnerstag, 15. August, 13:32
Betreff: Re: [squeak-dev] Question about #caseOf:otherwise:
An: The general-purpose Squeak developers list


On Thu, 15 Aug 2019, Thiede, Christoph wrote: > > Sounds very interesting :) > > > In the past I have been writing the following instead: > > > true caseOf: { > >     [aNumber isEven] -> ['That is an even number.']. > >     [aNumber isOdd] -> ['That is an odd number.'].  > > }. > > > but your code is much more beautiful :) > > I think both variants have a contrary semantic, but on the other hand it just reads intuitive: > > > aNumber caseOf: { >    [42] -> ['That is correct.']. >    [:n | n even] -> ['That is an even number.']. >    [:n | n odd] -> ['That is an odd number.']. > }. > > > This would also require some changes to the Parser. If your examples compiles, I would also expect the following to run: > > aNumber caseOf: { >    #even -> ['That is an even number.']. >    #odd -> ['That is an odd number.']. > }. While you could expect that to compile, the Parser is strict about the format, because everything (blocks, associations, the array) will be inlined, so no objects will be created for them. Without inlining, such construct would not be viable performance-wise. Levente > > Best, > Christoph > > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > Von: Squeak-dev im Auftrag von Taeumel, Marcel > Gesendet: Donnerstag, 15. August 2019 10:32:07 > An: gettimothy via Squeak-dev > Betreff: [squeak-dev] Question about #caseOf:otherwise:   > Hi all! > > Why isn't the following example possible? > > aNumber caseOf: { >    [:n | n even] -> ['That is an even number.']. >    [:n | n odd] -> ['That is an odd number.']. > }. > > That is, why is the check "assoc key value = self" not configurable as "(x := assoc key cull: self) == true or: [x = self]"? :-) > > ... maybe it is a good thing that case-of statements in Smalltalk are not that powerful? > > Best, > Marcel > >



Reply | Threaded
Open this post in threaded view
|

Re: Question about #caseOf:otherwise:

Levente Uzonyi
On Thu, 15 Aug 2019, Thiede, Christoph wrote:

> Why can't we apply the "hybrid" solution from #ifNotNil: here? Afaik the argument is inlined if it's a block, otherwise not. Specifying something inefficient is not recommended, but possible.

It is applied. If the argument is an array, it'll be inlined, if it's a
variable, it can't and won't be inlined.

Levente

>
>
> Von: Levente Uzonyi
> Gesendet: Donnerstag, 15. August, 13:32
> Betreff: Re: [squeak-dev] Question about #caseOf:otherwise:
> An: The general-purpose Squeak developers list
>
>
> On Thu, 15 Aug 2019, Thiede, Christoph wrote: > > Sounds very interesting :) > > > In the past I have been writing the following instead: > > > true caseOf: { > >     [aNumber isEven] -> ['That is an even number.']. > >    
> [aNumber isOdd] -> ['That is an odd number.'].  > > }. > > > but your code is much more beautiful :) > > I think both variants have a contrary semantic, but on the other hand it just reads intuitive: > > > aNumber caseOf: { >
>    [42] -> ['That is correct.']. >    [:n | n even] -> ['That is an even number.']. >    [:n | n odd] -> ['That is an odd number.']. > }. > > > This would also require some changes to the Parser. If your examples compiles, I
> would also expect the following to run: > > aNumber caseOf: { >    #even -> ['That is an even number.']. >    #odd -> ['That is an odd number.']. > }. While you could expect that to compile, the Parser is strict about the
> format, because everything (blocks, associations, the array) will be inlined, so no objects will be created for them. Without inlining, such construct would not be viable performance-wise. Levente > > Best, > Christoph > >________________________________________________________________________________________________________________________________________________________________________________________________________________________________
> _ > Von: Squeak-dev im Auftrag von Taeumel, Marcel > Gesendet: Donnerstag, 15. August 2019 10:32:07 > An: gettimothy via Squeak-dev > Betreff: [squeak-dev] Question about #caseOf:otherwise:   > Hi all! > > Why isn't the
> following example possible? > > aNumber caseOf: { >    [:n | n even] -> ['That is an even number.']. >    [:n | n odd] -> ['That is an odd number.']. > }. > > That is, why is the check "assoc key value = self" not
> configurable as "(x := assoc key cull: self) == true or: [x = self]"? :-) > > ... maybe it is a good thing that case-of statements in Smalltalk are not that powerful? > > Best, > Marcel > >
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Question about #caseOf:otherwise:

Jecel Assumpcao Jr
In reply to this post by Jakob Reschke-2
Jakob Reschke wrote on Thu, 15 Aug 2019 12:08:56 +0200

> Am Do., 15. Aug. 2019 um 11:20 Uhr schrieb Thiede, Christoph:
>
> true caseOf: {
>
>     [aNumber isEven] -> ['That is an even number.'].
>
>     [aNumber isOdd] -> ['That is an odd number.']. 
>
> }.Lisp cond? ;-)
> http://clhs.lisp.se/Body/m_cond.htm  

Or, closer to home, the fat right arrow in Smalltalk-72.

Here is a 10 page overview of Smalltalk-72:

> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.106.9352&rep=rep1&type=pdf

and the complete 137 page instruction manual:

> https://pdfs.semanticscholar.org/442f/0f5205c7d4674612204ecc8357367dabbf45.pdf

-- Jecel