[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Smalltalk Compiler, was Re: Objective-C Generation



Dear Dana,

I'm not feeling specialized on this topic, so just a few comments of
mine:


"Dana S. Wheeler" wrote:
> 
> Marcel Weiher wrote:
> 
> > > From: "Jeff Szuhay" <jeffs@pstnet.com>
> > > Is anybody working on generating Objective-C code
> > > from Squeak?
> >
> > [raises hand]
> >
> > Yes.
> 
> Remainder of original message deleted
> 
> Since you have obviously thought deeply about this I was hoping to ask
> you a couple of questions. I am new to smalltalk so please have
> patience. Being frustrated with the speed of smalltalk compared to
> languages that compile to native code I have been thinking about how
> smalltalk could be optimized. It seems to me that :
> 
>     1. All classes can be decomposed to  primatives.
>     2. Methods ultimatly can be decomposed to operations on those
> primatives.
> 

If this is possible depends on what you mean here: Smalltalk is not a
typed language!

> This would seem to imply that any valid smalltalk program could be
> expressed in any language the primatives could be expressed in.

You are able to write a Smalltalk-Interpreter in every language with
Turing-machine capabilities... ;-)

> The
> monkey wrench in the works is that at this point you don't know what
> class will be passed as an argument in a message to a given class.
> However if the initial message that starts the application has no
> arguments (CheckBookInterface new; open.) or the argument(s) to the
> message can be decomposed into primatives then the you start a chain of
> logic with which you can determine which objects are passed as arguments
> in any message the application uses.

Not at compile-time (see below). But at run-time.

With the actual VM it is possible in a primitive (at run-time) to fetch
the class of an object, which is passed as argument to this primitive.
So I don't understand the problem here.

And if you have some kind of user or world interaction (e.g. reading a
file), then you have taken some randomness into account: A typical
program isn't fully deterministic!

> Therefore you can determine which
> message is being called since it depends upon the class.

Dynamically (at run-time) this is true. But at compile time there is a
problem, I try to express it in ST code:

Userclass>>giveMeAnObject: userInputFromSomewhere
^ userInputFromSomewhere
	ifTrue: [OrderedCollection new.]
	ifFalse: [Set new.]

Here you don't know at compile-time, which object will be returned by
this method.

> I've tried this
> manually on a couple of small programs and while it was tedious it did
> seem to work. However I have not done an exaustive trial, I am a newbie
> and I am reminded of the saying "Logic is a way of going wrong with
> confidence."
> 
> On the other hand if this works the possibilites are exciting. It also
> seems to imply that any message that does not have arguments could be
> compiled into native code and used by the object engine. This would
> increase speed not only by using native code but also eliminates many
> method look-up's by the object engine (virtual machine?).

If you have arguments or not is not an issue:
An object can have instance variables with values set by other methods
as the current one. So you don't need any arguments to compute the same
result as with arguments, if you make the object having inst vars
containing just these args.

Your argument eventually applies for constants, but they are not the
majority of methods, because if you want to compute something, you
normally use some instance variables or args.

> 
> If this works you would need only a library of primatives in your
> favorite language. The translator would be able to trace the messages
> from the application through the smalltalk library. Therefore you are
> not tied to any one implementation of the smalltalk library.

It is not so simple: A VM has some capabilities, which are defined in
'sqVirtualMachine.h'. These are heavily used in primitives of itself
(the interpreter) or in plugin primitives. You have to inline these
calls or use them as a library.

> 
> Just imagine. The translation code could be written in smalltalk, then
> run on itself and you would have a Just-In-Time compiler.

Actually this approach has been taken for the interpreter! It is written
in Slang, compiled into C code, translated by a C compiler and finally
used as squeak executable...

I hope I have given you some ideas for further thinking (I'm not a
specialist for this topic).


Greetings,

Stephan

> 
> Actually this sounds to good to be true. Or is someone already doing
> this. I heard that something like this is done in self but I have no
> details.
> 
> My question is this: What situation would this not work and where am I
> going wrong. I feel like I'm missing something.
> 
> Thanks
> 
> --
> Dana S. Wheeler
> dwheeler@gte.net
> 
> Maintain a humble awe in all things of God and a cynical skepticism in all
> things of man.

-- 
Stephan Rudlof (sr@evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3