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

Re: s-exprs + prototypes



On 2003.06.23 01:01 Anton van Straaten wrote:
> Correct me if I'm wrong, but assuming a dynamically-typed language that's
> capable of polymorphically dispatching messages on objects whose type isn't
> known in advance, there's no way the dispatch mechanism can be as trivial as
> it is for nested closures, where polymorphism is not an issue and directly
> indexed access can be used.

It's not polymorphism that inflicts the main cost, it's late binding.  Any
dynamically typed language is going to involve some runtime mechanism
for binding types.  Inheritance adds to the cost, and so does polymorphism,
but it can (with the right set of rules) be a very small cost.

> A lexically scoped language that has some kind of compile phase (even at
> runtime) doesn't have to look up a name - all it needs is an offset (or two,
> e.g. rib+offset, depending on the design).

When polymorphic objects can be bound early, you can compile their bindings
as well (of course one of the main purposes of polymorphism is to postpone
binding decisions, in case some sort of lookup is inevitable).

> It's polymorphism across objects of different types that introduces the
> burden.

Again, I think that late binding is the real albatross.  Consider a
lexical-scoping interpretation of polymorphism: lexical scopes may be
typed; functions defined in a typed lexical scope which share the name
of functions defined by that type are polymorphic.  Every reference to
a function may be characterized by a tree of lexical scopes which,
according to the language's rules of scope and inheritance, are potential
owners of the function's definition.  Resolving a polymorphic reference
consists of searching the tree in a particular order for a definition of
the given name.  Some of searching can be done at "compile time", and
sometimes the reference can be definitively resolved.  The rest of the
time, the runtime part of the search can be reduced to a generally short
sequence of lookup operations.

Yes, this is a burden, but a minor one IMHO.  
> Sounds promising - do you have any example languages in mind?  Is the answer
> going to have something to do with Japanese food containers?

You must be psychic :)

Michael

-----------------------------
Michael St. Hippolyte
http://www.bentodev.org