<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"><<a href="mailto:rpboland@gmail.com" target="_blank">rpboland@gmail.com</a>></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>> Hi Ralph,<br>
...<br><br>
> ><br>
> > I was aware of caseOf: in Squeak. I always found it awkward to use and<br>
> > felt a true case statement would be simpler. Alas, it's impossible to<br>
> > have a true case statement added to Smalltalk now I think.<br>
<br>
> So what's a "true" case statement? For me, at least, the Squeak one *is*,<br>
> and is more general than one limited to purely integer keys, as for example<br>
> is C's switch statement. A number of languages provide case statements<br>
> that are like Squeak's. What do you consider a "true" 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'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'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't be reduced to a language, becaue the anguage doesn'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's caseOf: is more general than C'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 '=' message by an arbitrary binary operator such as includes: or '>'.<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>
> > But I wouldn't want to be forced to implement my FSMs this way.<br>
> > It might be acceptable for small FSMs.<br>
> > I want to avoid sequential search and<br>
> > even binary search might be rather expensive.<br>
> > I look at computed gotos as the solution but,<br>
> > as you pointed out, computed gotos pose problems for JIT.<br>
> > Admittedly, for large FSM's, it might be best or necessary to<br>
> > use a FSM simulator anyway, as I do now.<br>
<br>
<br>
> Nah. One should always be able to map it down somehow. Tis will be easier<br>
> with the Spur instruction set which lifts number of literals and length of<br>
> branches limits.<br><br></div><div>Good to hear.<br><br><br>
> > Again, for my FSM, case this would often be considered to be good.<br>
> > But if the state transition tables are sparse then Dictionaries<br>
> > might be preferable to Arrays.<br>
><br>
<br>
> Yes, but getting to the limit of what the VM can reasonably interpret.<br>
> Better would be an Array of value. pc pairs, where the keys are the values<br>
> the switch bytecode compares top of stack against, and the pcs are where to<br>
> jump to on a match. The JIT can therefore implement the table as it sees<br>
> 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'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>
> > My expection is that at: be sent to the collection object<br>
> > to get the address to go to. Knowing that the collection<br>
> > is an array though makes it easier for the compiler/VM to<br>
> > ensure that the addresses stored in the collection are valid.<br>
> > Actually, the compiler will be generating the addresses.<br>
> > Does the VM have absolute trust in the compiler to generate valid<br>
> > addresses?<br>
<br>
<br>
> 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>