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

Douglas Brebner squeaklists at fang.demon.co.uk
Thu Feb 17 22:02:16 CET 2011

On 17/02/2011 18:08, Eliot Miranda wrote:
> On Thu, Feb 17, 2011 at 1:59 AM, Douglas Brebner 
> <squeaklists at fang.demon.co.uk <mailto:squeaklists at fang.demon.co.uk>> 
> wrote:
>     On 16/02/2011 20:13, Eliot Miranda wrote:
>>     On Wed, Feb 16, 2011 at 12:04 PM, Stéphane Ducasse
>>     <stephane.ducasse at inria.fr <mailto:stephane.ducasse at inria.fr>> wrote:
>>         On Feb 16, 2011, at 6:15 PM, Eliot Miranda wrote:
>>         >
>>         >
>>         > On Tue, Feb 15, 2011 at 11:50 PM, Stéphane Ducasse
>>         <stephane.ducasse at inria.fr
>>         <mailto:stephane.ducasse at inria.fr>> wrote:
>>         > Eliot a final question.
>>         > So how will you handle OPAL compiler change in Cog?
>>         > Do you require that marcus and jorge have to deal with
>>         decompiler of caseOf: in addition to all the rest?
>>         > Is it a strong requirement? Because then this is clear that
>>         Opal will be delayed. But may be it is not that important
>>         after all.
>>         > Just curious.
>>         >
>>         > OPAL is a Smalltalk compiler.  I can therefore assume that
>>         it will compile Smalltalk.  caseOf: is valid Smalltalk and so
>>         will be compiled by OPAL.  Whether Marcus chooses to optimise
>>         caseOf: or not is up to him.
>>         This is exactly my point.
>>     No it's not.  Your point was to raise two straw-=man arguments:
>>     1. that Marcus and Jorge would have to deal with the decompiler
>>     (not an issue; the decompiler already deals with optimized
>>     caseOf: and the new decompiler will deal with optimized caseOf:
>>     just as it'll deal with optimized ifTrue: ifNotNil: et al).
>>     2. that supporting caseOf: in optimized form will delay Opal (not
>>     an issue; Opal will optimize certain constructs, this is just one
>>     more and won't add a lot of time).
>>     So your point appears to be to try and justify removing caseOf:
>>     on spurious grounds by spreading FUD.
>>     This is so unlike you I'm having a hard time really understanding
>>     what's going on.
>     Correct me if I'm wrong but isn't Stephane essentially saying that
>     Opal will just demote #caseOf: from inlined special form to normal
>     method? (Possibly so it can be unloadable instead of being pinned
>     in the system by the compiler support).
>     It seems to me that this shouldn't affect caseOf: use in Cog since
>     the inlining there is handled by the SLang translator.
> It certainly won't affect the production Cog since indeed that goes 
> through Slang to emerge as C.  However it will affect developing in 
> Cog, which is done by rnning the simulator, and as I've shown case 
> statements are used in some performance-critical parts of the system 
> (byte access).

Wasn't there mention of Opal having optimisations as extensions so you 
can have an optimised caseOf: without having it hardwired into the compiler?

>     Or have I totally misunderstood?
>     Of course, where caseOf: is kept afterwards another question :)
> I don't see why one would want to get rid of this useful 
> functionality.  There is nothing inherrently wrong with a flexible 
> case statement.  Its certainly far more preferrable than a 
> performance-equivalent set of nested ifTrue:ifFalse:'s.  Further, the 
> dictionary/perform or multiple classes approaches only make sense at a 
> certain scale (that's especially true of the dictionary/perform 
> alternative since maintaining the dictionary is painful).  So for me 
> it makes absolutely no sense for a Squeak-derived Smalltalk dialect to 
> eliminate a construct that is really useful in certain circumstances. 
>  That kind of thinking eliminates things like contexts and that's a 
> slippery slope to eliminating the essential flexibility of the system.
I wasn't arguing for getting rid of it entirely, I prefer it to 
dictionary/perform which I dislike for some reason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110217/5b7a8d98/attachment.htm>

More information about the Pharo-project mailing list