RE: s-exprs + prototypes

["Anton van Straaten" <address@hidden>]

Steve Dekorte wrote:
> On Sunday, June 22, 2003, at 10:01 PM, 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.
>
> Ah, but are you now imposing your own limitations on how
> lookups are done? And worse, doing so in a way that is
> not changeable at runtime.

No, I was responding to this statement from Michael St. Hippolyte:

> The dispatch mechanism for an OO language, properly constructed,
> can be trivial.  With a simple enough language, it's just a lookup
> of a name in a context -- exactly what any lexically scoped
> language has to do anyway.

I was responding in part to the "lookup of a name in a context" bit, since a
lexically-scoped  language doesn't have to do that at runtime.  With
appropriate optimizations, even a dynamically typed lexical language can
optimize to a direct machine-level function call - equivalent to the case in
a statically-typed OO language invoking a "non-virtual" method (to use C++
terminology).  In the worst lexical case, e.g. Scheme code in which
functions are being replaced at runtime and cannot be optimized to a direct
function call, a directly indexed lookup can be used.

The brief summary is that the worst case for a lexically-scoped non-OO
language is the best case for all OO languages, except for the one special
case of non-virtual methods in a statically typed OO language mentioned
above.  And the best case for OO languages is not easily achieved without
either static typing or significant & complex runtime optimizations.

But my concern here has little to do with performance, or the complexity
which the language implementor has to deal with, and much more to do with
whether the programmer has the choice and support from the language to
invoke named functional abstractions directly, rather than only through an
arbitrary, often baroque, and subtly limiting dispatch mechanism chosen by
the language implementor.

Anton