[Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:
eliot.miranda at gmail.com
Thu Feb 17 19:08:56 CET 2011
On Thu, Feb 17, 2011 at 1:59 AM, Douglas Brebner <
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> 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> 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).
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-project