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

Igor Stasenko siguctua at gmail.com
Thu Feb 17 01:16:22 CET 2011


On 17 February 2011 00:51, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> 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 ;)

I see it like following:
 - VM gets faster so language side could drop hacky optimizations

For instance, why #class or #== messages are early bound? What is a
tradeoff for having 0.005% faster system,
but unable to have good proxies?

As Eliot said before: you can cheat, but don't get caught. Apparently
things like above didn't took that into account. So why we should not
attempt to fix that?

>
> Nicolas
>
>>>

-- 
Best regards,
Igor Stasenko AKA sig.




More information about the Pharo-project mailing list