<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 8, 2014 at 11:21 AM, Ralph Boland <span dir="ltr">&lt;<a href="mailto:rpboland@gmail.com" target="_blank">rpboland@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr"><div><div>&gt; Hi Ralph,<br>
...<br><br>
&gt; &gt;<br>
&gt; &gt; I was aware of caseOf: in Squeak.  I always found it awkward to use and<br>
&gt; &gt; felt a true case statement would be simpler.  Alas, it&#39;s impossible to<br>
&gt; &gt; have a true case statement added to Smalltalk now I think.<br>
<br>
&gt; So what&#39;s a &quot;true&quot; case statement?  For me, at least, the Squeak one *is*,<br>
&gt; and is more general than one limited to purely integer keys, as for example<br>
&gt; is C&#39;s switch statement.  A number of languages provide case statements<br>
&gt; that are like Squeak&#39;s.  What do you consider a &quot;true&quot; case statement?<br><br></div>I mean that:  caseOf: is not part of the language itself but rather part of the<br>standard library or set of packages that one finds in the IDE.  To be part of the<br>language it would need to be something the compiler is aware of. </div></div></blockquote><div><br></div><div>Ah OK.  I see what you mean. But you&#39;re wrong on a few counts.  First, there are *no* control structures in the language beyond closures and polymorphism.  ifTrue:, to:do:, and: whileTrue: et al are all defined in the library, not by the compiler.  Second, tehse structures, /including/ caseOf: are understood by the compiler and compiled to non-message-sending code.  So none of the blocks in caseOf:, ifTrue: and: whileTrue: et al, the optimized selectors, are created and all are inlined by the compiler.  So a) by your criterion of being in the compiler caseOf: is in the language, but b) it all control structures in Smalltalk are defined in the library, and some are optimized by the compiler.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> That is to<br>day the Smalltalk language is not very much.  Smalltalk (Squeak) the language<br>would not include Sets or Dictionaries but would include (some) Array classes<br>because some aspects of Arrays are dealt with directly by the compiler.<br></div></div></blockquote><div><br></div><div>There is a syntactic form for creating Array, but really the notion that the Smalltalk compiler defines the language is a limited one.  It&#39;s fair to say that language is defined by a small set of variables, return, blocks, an object representation (ability to create classes that define a sequence of named inst vars and inherit from other classes), and message lookup rules (normal sends and super sends), and a small number of literal forms (Array, Integer, Float, Fraction, ByteArray, String and Symbol literals), and a method syntax.  The rest is in the library.  What this really means is that Smalltalk can&#39;t be reduced to a language, becaue the anguage doesn&#39;t defne enough.  Instead it is a small language and a large library.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Selectors such as  ifTrue: and  to:do:  are part of the language because they are inlined by the compiler.<br></div></div></blockquote><div><br></div><div>No.  One can change the compiler to not inline them.  This is merely an optimization.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>Put another way,  if I could get my doBlockAt: method incorporated into the Squeak IDE<br></div><div>it would nevertheless NOT be part of Squeak the language.<br></div><div>The consequence of  caseOf:  not being part of the language is that the compiler/VM<br></div><div>cannot perform optimizations when caseOf:  is run into but must treat it as<br></div><div>user written code.<br><br></div><div>Squeak&#39;s  caseOf:  is more general than C&#39;s switch statement but it could be more<br>general in that there is a hard coded message (=).  I would like to be able to replace<br></div><div>the &#39;=&#39; message by an arbitrary binary operator such as  includes:  or &#39;&gt;&#39;.<br><br></div><div>I have to backtrack here:  I looked at the code and it looks like the compiler inlines <br></div><div>caseOf:  and caseOf:otherwise.  If so then these selectors are part of the language<br></div><div>by my definition.<br></div></div></blockquote><div><br></div><div>Well, live and learn :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div><div>
<br>
...<br><div>
<br>
&gt; &gt; But I wouldn&#39;t want to be forced to implement my FSMs this way.<br>
&gt; &gt; It might be acceptable for small FSMs.<br>
&gt; &gt; I want to avoid sequential search and<br>
&gt; &gt;  even binary search might be rather expensive.<br>
&gt; &gt; I look at computed gotos as the solution but,<br>
&gt; &gt; as you pointed out, computed gotos pose problems for JIT.<br>
&gt; &gt; Admittedly, for large FSM&#39;s, it might be best or necessary to<br>
&gt; &gt; use a FSM simulator anyway, as I do now.<br>
<br>
<br>
&gt; Nah.  One should always be able to map it down somehow.  Tis will be easier<br>
&gt; with the Spur instruction set which lifts number of literals and length of<br>
&gt; branches limits.<br><br></div><div>Good to hear.<br><br><br>
&gt; &gt; Again, for my FSM, case this would often be considered to be good.<br>
&gt; &gt; But if the state transition tables are sparse then Dictionaries<br>
&gt; &gt; might be preferable to Arrays.<br>
&gt;<br>
<br>
&gt; Yes, but getting to the limit of what the VM can reasonably interpret.<br>
&gt; Better would be an Array of value. pc pairs, where the keys are the values<br>
&gt; the switch bytecode compares top of stack against, and the pcs are where to<br>
&gt; jump to on a match.  The JIT can therefore implement the table as it sees<br>
&gt; fit, whereas the interpreter can just do a linear search through the Array.<br><br></div><div>I am looking at this from the point of view of a compiler writer/generator and consider<br></div><div>your proposal as inadequate for my needs.  You, I think, are looking at this from<br>the point of view of a VM writer and what can reasonably be delivered.  I don&#39;t think<br></div><div>what I want is overly difficult for the interpreter to deliver but as you pointed out,<br></div><div>and you know much better than I, what I want causes serious problems for the VM.<br></div><div>
<br>
&gt; &gt; My expection is that  at:  be sent to the collection object<br>
&gt; &gt;  to get the address to go to.  Knowing that the collection<br>
&gt; &gt; is an array though makes it easier for the compiler/VM to<br>
&gt; &gt; ensure that the addresses stored in the collection are valid.<br>
&gt; &gt; Actually, the compiler will be generating the addresses.<br>
&gt; &gt; Does the VM have absolute trust in the compiler to generate valid<br>
&gt; &gt; addresses?<br>
<br>
<br>
&gt; Yes.  Generate bad bytecode and the VM crashes.<br> <br></div><div>This is what I expected to hear but wanted it to be clear for compilers generated<br>by my parser generator tool as you did.<br><br></div><div>Ralph<br></div></div></div></div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>