Erlang hints from an CO junkie

Thomas Lindgren thomasl_erlang@REDACTED
Thu Aug 12 21:38:34 CEST 2004

--- Vlad Balin <vlad@REDACTED> wrote:

> > But abstract datatypes =/= objects. Objects have
> > state, identity and associated methods, while ADTs
> are
> > collections of functions that operate on and
> > encapsulate concrete data (and where the
> > implementation perhaps satisfies some laws
> formulated
> > on the ADT).
> Looking very strange to me.
> Lets dig into definitions. The world-known OOP
> definition consist of 3 properties:
> 1) encapsulation
> 2) polimorphism
> 3) inheritance.
> 2 property in particular (but not only) means that 
> you must be able to define generic functions working
> with any ADT conforming specified interface, in
> other 
> words it state that ADT instance must have a
> _value_,
> so you could pass it as a parameter to a function.
> Nothing is said about associated _methods_ - this is
> just one of the names for ADT functions. 

Not at all. One of the concrete differences between
abstract data types and objects is that methods are
associated with the object itself, while in an ADT
they are not. (OO proponents often consider this is an
advantage of OO.)

If you just happen across a Smalltalk object, you can
try to send it messages. Perhaps you can inspect the
object and see what messages it accepts.

If you instead are handed an Erlang term, there are no
programmer-defined, inherently associated operations
connected to it (let's ignore funs for now, and maybe
PIDs too). In particular, ADT operations only appear
in the program code, which is separate from the data.
That's a clear difference to me.

There are other differences as well. One of the
programming idioms that OO wanted to get rid of was
switching over types or patterns. So, what would in a
tree ADT look like

lookup({node, K, V, Left, Right}) -> ...
lookup(leaf) -> ...

would instead in OO become classes 'node' and 'leaf'
with an associated method 'lookup'. (Perhaps more
efficient idioms are used today, but that's not the

Furthermore, there's also the whole idea of proving
properties about the ADT _operations_. 

And finally the lack of state and identity of data, if
we are talking about pure functional languages.

> In some
> terms
> ADT interface functions are 'associated' with an
> instance - 
> yes, because in other case you will not be able to
> define
> generic function on it (it receives only the
> _value_!). 
> This is the main issue.

Sorry, I'm afraid I don't follow you.

> Here is nothing said about identity and state in
> definition.
... (big snip) ...
> Yes, some _implementations_ may add more specific 
> properties to objects such as state and identity,
> but
> terms 'class' and 'object' (class instance) has
> became
> quite common in whole context of OOP and can be 
> hardly associated with a particular langugae now.

Grady Booch told us an object has state, behaviour and
identity in 1991. This seems to be an accepted truth
in the OO community, as far as I can tell.

> Could you give a reference to the definition of
> object you operating with?

Objects as defined in Smalltalk, C++ or Java. Perhaps
Smalltalk is the best example here. (Common Lisp and
SELF muddy the waters, so I'll leave them out.)

Finally, here are a couple of references on ADTs, esp.
for functional languages.


Guttag's paper

Or Bird and Wadler's book on functional programming.

Allen's ANATOMY OF LISP introduced me to the concept,
though his is not a very explicit discussion.

Well, that's enough for this time. Hope it helped.


Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages! 

More information about the erlang-questions mailing list