On Wed, Oct 02, 2002 at 12:01:29PM +0900, William Djaja Tjokroaminata wrote:
> Hi Alan,
> 
> All your idea below seems good, but has anything like that been done
> before, in some other languages, perhaps?

In parts I know it's been done, but I don't know if its been
implemented all together.  C++ does some of it at compile time. And
the Java HotSpot VM does runtime optimization. The only real addition
to what I'm proposing is extra profiling logic to determine the class
of objects passing through functions and methods, and optimizing the
most frequent occurences of class parameter signatures. (for lack of a
better term).  Once the profiling logic has determined the "internal"
calling signatures, it could proceed like typical compiler in a more
statically typed language.

> Let me also try to understand further your idea.  Basically, are you
> saying that the type of the object referred to by a variable seldom
> changes?  In this case I agree.  So instead of using explicit typing on
> the variable itself, let the computer assigns the type to the variable
> based on the runtime type of the object referred to by the variable.  Am I
> correct?

Yes, I think we're on the same page here. And in the case of multiple
parameters, you would end up with function signatures much like any
language with overloading. Only these signatures are internal to the
compiler.  This entire process could be automated like Java, but I
would almose prefer a two stage process - profiling to identify
frequently used signatures then compiling. There could be many
variants to this too, maybe the programmer would like to provide
certain hand-written C-code with signatures accessible to the engine.
In that case, the programmer provided code would be used by the engine
if there was a match.

> As I got the impression that Dylan has both static and dynamic typing, I
> will also scan the language.
> 
> Regards,
> 
> Bill
> ============================================================================
> Alan Chen <alan / digikata.com> wrote:
> > My whole point was that you might want to consider exploring
> > optimizations with ruby as is. Optimizations may be more difficult,
> > but they are certainly possible. When you have application running a
> > ruby codebase, an optimizing ruby engine (ORE?).  In many cases,
> > parameters passed to function and method calls will be primarily of
> > the same type. Say function foo(x).  In the codebase, maybe x is never
> > anything but an Array. ORE then creates a block of optimized machine
> > code assuming x is an array with some detection logic to fallback to
> > the regular code if x is not an array. Maybe ORE has a "profile" mode,
> > builds up some run profiling data and them builds the optimized machine
> > code based on the profile. Or the programmer looks over the profile data
> > and picks which functions with what type signature to build optimized
> > code for -- all while keeping the Ruby language largely intact, and not 
> > intruducing static typing to function prototypes.
> 

-- 
Alan Chen
Digikata LLC
http://digikata.com