On 16/02/2011 20:13, Eliot Miranda wrote:
On Wed, Feb 16, 2011 at 12:04 PM, Stéphane Ducasse
<stephane.duca...@inria.fr <mailto:stephane.duca...@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.duca...@inria.fr <mailto:stephane.duca...@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.
Or have I totally misunderstood?
Of course, where caseOf: is kept afterwards another question :)
