[erlang-questions] Random newbie stuff

[Ulf Wiger]

2007/11/4, Brandon Black <blblack@REDACTED>:

> 1) "Inheritance"
>
> Forgetting for a moment OO <-> Erlang holy wars and battles about
> syntax and semantics, in a practical sense, is there any way to
> inherit code for re-use in Erlang?  I can imagine many scenarios where
> it would be useful, here's a concrete one for example:  Suppose one
> were writing an Erlang module that parsed list comprehension syntax
> and converted it into some sort of SQL equivalent as part of an Erlang
> <-> RDBMS interface.

Actually, the qlc module does more or less this. It allows you to plug
in different table generators, so that you can combine data from
different sources in a list comprehension.

The generator "plug-ins", are higher-order functions.

You can choose to either use modules as "classes", along the
lines of the OTP behaviours - gen_server, gen_event, etc. - or
"funs" that specialize certain aspects of a function.

Xmerl allows the user to provide funs that specialize nearly
every aspect of XML processing: one fun that fetches the file,
one that accumulates complete elements, one that closes
the file, etc.

On a smaller scale, the lists module exports functions that
can can be specialized using funs: lists:sort/2, lists:zipwith/3,
lists:foldl/3, etc.

You also have modules like ordsets, which define a data structure
with well-known semantics. Ordsets are ordered lists, by definition.
The ordsets module exports a number of functions that can be used
on sets (deliberatly identical to those of the sets module), but since
the data structures are documented as lists, you know that all
operations that are valid on lists are also valid on ordsets (although
some of them may turn the data into something that is no longer an
ordset.)

Inheritance is not a first-class citizen in Erlang, but there are many
ways to go about achieving code reuse through informal inheritance.
Some of these approaches could be made more automatic, but there
is always a cost to adding things - tools or syntax.

> 2) State Mutability...
>
> How important is it to maintain immutable state?  Are there classes of
> problems (classes of applications) which cannot be built without
> mutable state (for which one would use process dicts or [d]ets)?

One reasonably common problem is when you've designed an
interface with a strictly limited set of parameters, and then need
to extend the functionality in a way that forces data to be carried
across between subsequent calls. You will then need to invent
something that can maintain state between calls, unless you can
get the caller to do it for you (by passing an opaque parameter).

One way to solve this is of course to use a process. Note that the
process may well use immutable state internally, but to an outsider,
the state appears to change continuously. The thing that you get with
immutability is that a piece of data, once bound, is guaranteed not
to change. You have to create a new instance by (conceptually)
copying the data. Note that the runtime system is free to decide
that old data can be reused, just as it can choose to send data
by reference between processes sometimes.

The main advantage of immutable state is that a function that
doesn't "cheat" by using the process dictionary, ets, message
passing etc, is guaranteed to always produce the same result
every time it is called with the same set of parameters.

Of course, this isn't much of a guarantee, at least not to someone
used to Haskell. Haskell offers a way to clearly state that something
dirty is about to happen. This allows the compiler to know which
functions are guaranteed to have the nice property of being fully
predictable.

Erlang doesn't provide the same level of guarantees, but the
programmer can usually still rely on this, as long as some care is
taken to keep side-effects grouped together and separate from
the large parts of code that really doesn't need them, and which
should be 100% predictable.

BR,
Ulf W