<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
    <title></title>
  </head>
  <body text="#000000" bgcolor="#ffffff">
    On 16/02/2011 20:13, Eliot Miranda wrote:
    <blockquote
      cite="mid:AANLkTinYbDkGYC_W1wd0MMQaRR4ygpkmx2S7QSUZ7ZWo@mail.gmail.com"
      type="cite"><br>
      <br>
      <div class="gmail_quote">On Wed, Feb 16, 2011 at 12:04 PM,
        St&eacute;phane Ducasse <span dir="ltr">&lt;<a moz-do-not-send="true"
            href="mailto:stephane.ducasse@inria.fr">stephane.ducasse@inria.fr</a>&gt;</span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          <div class="im"><br>
            On Feb 16, 2011, at 6:15 PM, Eliot Miranda wrote:<br>
            <br>
            &gt;<br>
            &gt;<br>
            &gt; On Tue, Feb 15, 2011 at 11:50 PM, St&eacute;phane Ducasse &lt;<a
              moz-do-not-send="true"
              href="mailto:stephane.ducasse@inria.fr">stephane.ducasse@inria.fr</a>&gt;
            wrote:<br>
            &gt; Eliot a final question.<br>
            &gt; So how will you handle OPAL compiler change in Cog?<br>
            &gt; Do you require that marcus and jorge have to deal with
            decompiler of caseOf: in addition to all the rest?<br>
            &gt; 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.<br>
            &gt; Just curious.<br>
            &gt;<br>
            &gt; OPAL is a Smalltalk compiler. &nbsp;I can therefore assume
            that it will compile Smalltalk. &nbsp;caseOf: is valid Smalltalk
            and so will be compiled by OPAL. &nbsp;Whether Marcus chooses to
            optimise caseOf: or not is up to him.<br>
            <br>
          </div>
          This is exactly my point.<br>
        </blockquote>
        <div><br>
        </div>
        <div>No it's not. &nbsp;Your point was to raise two straw-=man
          arguments:</div>
        <div>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).&nbsp;</div>
        <div>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).</div>
        <div><br>
        </div>
        <div>So your point appears to be to try and justify removing
          caseOf: on spurious grounds by spreading FUD.</div>
        <div><br>
        </div>
        <div>This is so unlike you I'm having a hard time really
          understanding what's going on.</div>
        <div><br>
        </div>
      </div>
      <br>
    </blockquote>
    <br>
    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).<br>
    It seems to me that this shouldn't affect caseOf: use in Cog since
    the inlining there is handled by the SLang translator.<br>
    <br>
    Or have I totally misunderstood?<br>
    <br>
    Of course, where caseOf: is kept afterwards another question :)<br>
  </body>
</html>