Alexandre-

I don't think it would be trivial thing to do, true.

But in general, when you go from Smalltalk to a static language you get a
speed boost at the cost of reflection and dynamic debuggability. You shift
from using full featured objects (with reflective introspective abilities)
and using full featured stack frame entries (garbage collectible to support
full blocks) to using only limited objects which just do exactly what you
specify and using only a stack which is linear (not fractal, like Smalltalk)
and so can be optimized to use the stack of the real machine (or virtual
machine) more easily.

But since Scala supports a higher level of abstraction than Java (or C/C++),
while still having close to the same speed, I think perhaps less compromises
might need to be made in some areas.

This book includes some example Scala program code related to Smalltalk's
forte, "Discrete Event Simulation", defining "A Language for Digital Circuits":
   "Scala By Example"
   http://www.scala-lang.org/docu/files/ScalaByExample.pdf

It just seems once could imagine a system that does a fairly easy mapping
from Smalltalk to produce something like this:

"""
class Wire {
  private var sigVal = false
  private var actions: List[Action] = List()
  def getSignal = sigVal
  def setSignal(s: Boolean) =
    if (s != sigVal) {
      sigVal = s
      actions.foreach(action => action())
    }
  def addAction(a: Action) {
    actions = a :: actions; a()
  }
}
""""

or:

""""
def andGate(a1: Wire, a2: Wire, output: Wire) {
  def andAction() {
    val a1Sig = a1.getSignal
    val a2Sig = a2.getSignal
    afterDelay(AndGateDelay) { output setSignal (a1Sig & a2Sig) }
  }
  a1 addAction andAction
  a2 addAction andAction
}
"""

Or:

"""
  abstract class Simulation {
    case class WorkItem(time: Int, action: Action)
    private type Agenda = List[WorkItem]
    private var agenda: Agenda = List()
    private var curtime = 0

   private def insert(ag: Agenda, item: WorkItem): Agenda =
     if (ag.isEmpty || item.time < ag.head.time) item :: ag
     else ag.head :: insert(ag.tail, item)

   def afterDelay(delay: Int)(block: => Unit) {
     val item = WorkItem(currentTime + delay, () => block)
     agenda = insert(agenda, item)
   }
"""

Anyway, I'm not saying that completely answers your question. And it would
not be automatic for all Smalltalk code and there would no doubt be various
issues to resolve (including perhaps interoperation).

But if you look at the kind of OO and functional code Scala can accept, then
I think that *some* types of Smalltalk code (written with translation in
mind) might translate very smoothly to it. And I might expect that the
amount of such code might be quite a bit larger than what translated
smoothly to C. Or even C++ (given GC in Scala). :-)

I don't expect people would want to translate entire systems to Scala or
Java, just the bottlenecks,and usually the bottlenecks are fairly
straightforward things like arrays of numbers to be multiplied, or some
recursive or iterative or choice-making algorithm which is mostly
self-contained (like BitBlit, sound primitives, matrix manipulation, fractal
generation, and so on) although might have callbacks into Smalltalk (a hard
part).

So overall, I'm guessing a translator that can do a enough of
Smalltalk->Scala which might be useful in practice for bottleneck
optimization might not be that hard to write, and one could expand from
there. Obviously, as with the C translator, things might start to fall apart
quickly for complex cases (using "perform:", or some fancy uses of blocks,
or reliance on many features of Smalltalk base classes beyond ones that map
easily to Scala libraries, or places where Scala's functional emphasis like
with immutable objects by default mismatches Smalltalk's OO emphasis
somehow). But for the kind of things I'm interested in -- typically having a
bunch of straightforward classes that just do simple but repetivie
mathematical manipulation (like to simulate water percolating through soil
layers), I would think the translation might work well. And even developing
new Virtual Machines might fall in that category. :-)

Because Scala has removed some of the warts of Java, like by not requiring
all exceptions be declared or caught for every function, or by not requiring
all types be declared if the compiler can deduce them, I would think the
translation process from Smalltalk might be easier than to Java and
requiring less Smalltalk programmer effort to restrict oneself to only
simple types or think about Java exceptions. So, if, say, you needed to
supply type annotations in the Smalltalk code somehow to make this work
smoothly (in comments?) then you might need to supply less of them.

Another big advantage over translating to C or even C++  (or even Java) is
that, given Scala's support of GC and classes and function references, the
resulting code in Scala might simply look prettier and be able to
understand. Because there is less clutter compared to C, it might also be
easier to make small tweaks by hand, with the tweaks then eventually moving
back to improving the translator or the Smalltalk source for the application.

Anyway, that's my gut feeling. It might not prove out in practice. And I
don't even know how to program in Scala yet. :-)

--Paul Fernhout

Bergel, Alexandre wrote:
>> I think I'd rather write Smalltalk->Scala and let the Scala team worry
>> about
>> optimization. That's the kind of stuff they like to do. :-)
> 
> Scala is statically typed. How would you map a dynamically typed
> language into a static one? This far from being automatic...
> 
> I am probably missing something here.