🚀 go-pugleaf

Summary:

Expires:

Sender:

Followup-To:


In article <9000007@uiucdcsp> johnson@uiucdcsp.CS.UIUC.EDU writes:
>Even if the compiler performs some optimizations, it will still have
>to implement some Smalltalk programs pretty much the same as it does
>now, using method look-up.

... at least if the code wasn't doing what the compiler thought it would
do when it compiled the code.  One the biggest wins of a ST type system
will be the ability to eliminate many of the dynamic method lookups
that occur, at least if the programmer has hinted the compiler in the
right direction. 

>> What if I wanted to
>> make a subclass of ByteArray that masqueraded as a Float but had
>> infinite precision (similar to LargeIntegers) - would this be a type
>> clash, or would I have to cast the LargeFloat as a regular Float?
>
>The subclass of ByteArray is not a Float.  However, it acts like a Float.
>You should not usually write code that requires objects to be in a
>particular class.  Instead, you should require that objects have certain
>behavior.

That's of course true, and it points to one of the hardest problems in
adding a type system/optimizing compiler to ST.  To do any reasonable
amount of optimization, one needs to get rid of many dynamic method lookups,
and to do this necessitates finding the actual code executed by other
message sends.  This requires knowing the classes of message receivers,
since this is what descriminates the method executed at run-time.  This is why
every ST type system that I have heard of has been class/set of classes
oriented.  This is in conflict with the progamming practice of 
``progamming by protocol'', that is, not caring about classes per se, but
only on the messages responded to.


	-bob atkinson	
	BAtkinson.pa@Xerox.com