<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. 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>Selectors such as ifTrue: and to:do: are part of the language because they are inlined by the compiler.<br></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><div>
<br>
...<br><div id=":31o" class="">
<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 id=":31o" class="">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 id=":31o" class="">I am looking at this from the point of view of a compiler writer/generator and consider<br></div><div id=":31o" class="">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 id=":31o" class="">what I want is overly difficult for the interpreter to deliver but as you pointed out,<br></div><div id=":31o" class="">and you know much better than I, what I want causes serious problems for the VM.<br></div><div id=":31o" class="">
<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 id=":31o" class="">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 id=":31o" class="">Ralph<br></div></div></div></div>