RE: s-exprs + prototypes

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

Michael St . Hippolyte wrote:
> The dispatch mechanism for an OO language, properly constructed,
> can be trivial.

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.

> 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.

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).

> Even inheritance doesn't have to impose a significant burden
> -- if the inheritance is based on a lazily-evaluated dynamic
> type system.

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

> > A function in a scope is only accessible within that scope.
> > If a programmer wants to expose a function more widely, that
> > can be done by any appropriate means - it doesn't have to involve
> > a predefined and unmodifiable dispatch mechanism which may not
> > be appropriate to the task.
>
> Well, yes it does, whether the programmer is aware of it or not.
> As soon as you have scopes, you have to have a way of differentiating
> one scope from another, and calling the code associated with the
> imminent scope -- a dispatch mechanism, whatever you may choose to
> call it.

I don't see this as comparable to OO dispatch - it can only be simpler.  If
you want to build a more complex mechanism on top of it, to support
polymorphism or whatever, you can.

> I agree with you that OO systems usually come with a lot of baggage,
> but I disagree that this needs to be the case.  In particular, if
> objects *are* atomic functions, you get the best of both worlds --
> trivial overhead (like functional languages) and encapsulation/
> inheritance/polymorphism (like OO languages).  Think of it as an
> OO language where the only methods are constructors, and all
> variables are immutable.
>
> (I suggest calling this genre FOOP, for Functional Object-Oriented
> Programming.)

Sounds promising - do you have any example languages in mind?  Is the answer
going to have something to do with Japanese food containers?

Anton