On Thu, Feb 17, 2011 at 1:59 AM, Douglas Brebner <squeaklists@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@inria.fr> wrote:
This is exactly my point.
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@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.
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).
I wasn't arguing for getting rid of it entirely, I prefer it to dictionary/perform which I dislike for some reason
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.