[erlang-questions] OOlang (was "some language changes")

Jason Dusek jsnx@REDACTED
Mon Jun 4 23:12:38 CEST 2007


Object orientation and concurrency overlap when we talk about servers.
A server is a process with a start up sequence, a protocol for
messages and an optional tail call or terminator -- we could also call
these three things a constructor, an interface and a destructor. It
would be great to see the server emerge as a fundamental primitive in
a new Erlang, so that a developer could compose (inherit from)
servers, override matches in the parents and extend the interface.

What do we have to add to the language to make this possible? I think
three new operations are necessary:

    inherit(x) :: marks self as an 'x', whatever that is
    compose(x) :: imports all of 'x' into this server definition
    tail(x) :: marks the tail recursive call or calls that keep this
server going

An x might be an atom or (mod, func, [a|rgs]), like spawn.

The distinction between inherit and compose is important -- we may
want to aggregate the code and message matchers of a 'foo' but not
actually mark the server as one, and likewise we may want to advertize
the fact that our server is a 'foo' but not import anything.

The tail operation is similarly important -- there may be multiple
ways to go to the next iteration of the server -- we should be able to
simply mark them and go. It would be really cool if we could write
'tail(x) ! {A, Message}' to insure that our next iteration started
with '{A, Message}' first in its queue.

In principle, we can map the server concept to standard Erlang as follows:

    1.  Every server is its own module, with some obfuscated name and one
        (or many) 'go' functions that stand in for the different ways
to initialize
        the server.
    2.  The tails calls are sorted out through some trickery, yet to be devised.
    3.  Inherit is ignored, whereas compose amounts to textual inclusion with
        some variable renaming and some rules about rewriting the 'receive'
        statement in the event of match collisions (probably need some help
        from the BEAM compiler for this).

Servers are not the end all and be all of concurrency -- I don't want
OOlang to do to Erlang what Java did too C++ -- but I see no reason
not to have clear, concise syntax for such a pervasive programming
pattern.

-- 
_jsn



More information about the erlang-questions mailing list