[Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Thu Feb 17 00:51:31 CET 2011


2011/2/17 Igor Stasenko <siguctua at gmail.com>:
> On 16 February 2011 22:00, Stéphane Ducasse <stephane.ducasse at inria.fr> wrote:
>> Ok this is my last mail on that topic.
>>
>
> apparently not ;)
>
>>
>>> yes now do not think that I'm implying that you are not able to implement a decompiler.
>>> Now we have something else to do that dealing with the optimisation of a stupid method.
>>> This is all my point.
>>> Let us focus on the real problems. eliot is crying for caseOf: but we have 3 users.
>>>
>>> Did you know that there are several uses of caseOf: in the Opal compiler?
>>
>>
>> (selector := aMessageNode selector)
>>                caseOf:
>>                        {([ #ifNil: ]
>>                                -> [ self isValueTranslator ifTrue: [ methodBuilder pushDup ] ]).
>>                        ([ #ifNil:ifNotNil: ]
>>                                -> [ args last arguments ifNotEmpty: [ args last arguments first binding emitStore: methodBuilder ] ]).
>>                        ([ #ifNotNil: ]
>>                                -> [ args first arguments ifNotEmpty: [ args first arguments first binding emitStore: methodBuilder ] ]).
>>                        ([ #ifNotNilDo: ]
>>                                -> [ args first arguments ifNotEmpty: [ args first arguments first binding emitStore: methodBuilder ] ]).
>>                        ([ #ifNotNil:ifNil: ]
>>                                -> [ args first arguments ifNotEmpty: [ args first arguments first binding emitStore: methodBuilder ] ])}.
>>
>>
>
> yikes... so Opal already polluted (as being non-pure) by premature
> optimizations :)
>
> You see the tendency: one premature optimization drags other after itself.
>
> I would suggest to make full & working compiler suite which doing no
> any optimizations/inlining,
> and only then, when everything works, add a code with inlining
> optimizations as a plugin.
> So, people will know, that this is _optional_ not mandatory and not
> hardwired into smalltalk compiler.
> This is the message a good compiler should pass to developers:
> optimizations are useful but not essential.
> But i am not analyzed Opal code deeply, maybe its already like that.
>
>

Sure, if it's just a proof of concept.... but wasting 10x factor when
Eliot spent so many efforts to gain 3x would sound like a denial of
his own utility in this community.
I can understand his reticence quite easily ;)

Nicolas

>>
>>>  Do you have such an encyclopaedic knowledge of all the packages ever written in Pharo and Squeak that you know* you have only 3 users?  Of course you don't.  You are being ridiculous.
>>
>> Now when opal will arrive people should be prepared that probably caseOf: will not be inlined.
>>
>> Stef
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>




More information about the Pharo-project mailing list