[erlang-questions] Random newbie stuff

[Paul Mineiro]

Hey Brandon.

I am also a beginner.  I have noticed how to do the "inheritence" bit, it
was one of the first things I figured out since the code reuse story
bothered me as well.  I have yet to use this strategy for anything real,
however, so maybe that indicates it's not such a problem in practice.

Anyway you could piece together the following:

1. Erlang supports a Module:foo (Args) syntax, where Module can be a
variable that has an atom value.  This suggests thinking of a tuple
{ Module, Implementation } as the run-time representation of something
doing inheritence.

2. Erlang allows you to query a module at run-time, a form of reflection,
via the (automatically generated) module_info/0 and module_info/1 methods.
So you can add annotations like

-super ([ foo, bar, baz ]).

into your module and you can inspect at run-time.

3. Erlang allows you to totally rewrite the function call resolution
strategy by making your own error_handler.  So you could create an
error_handler which would walk the super list of modules depth-first
left-to-right until it found something matching the method being invoked.

Now back to the "is this a good idea" question.  I think one thing that
objects achieve in OO languages is code reuse and I would like to see some
nice way of doing more code reuse in Erlang.  So maybe this is good for
that (although the fact that the arguments cannot be "cast" limits the
utility ... reminscent of perl objects' arbitrary implementation
strategy).

If your goal is "objects as containers of mutable state", I think
processes are a better fit, with messages being methods.  Mutable state
looks naturally like a recursive loop in FP and so fits the Erlang
process model nicely.

-- p

On Sat, 3 Nov 2007, Brandon Black wrote:

> Hi,
>
> I'm new to Erlang and to FP in general, but I have a fair amount of
> experience in various non-FP languages.  I've gotten about halfway
> through "Programming Erlang" so far (and skipped ahead on a few
> things), and I've got some questions I hope someone can answer...
>
> 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.
>
> My first instinct (thinking in regular OO terms) would be to write a
> well-structured module with a only a few public functions exported,
> with many little private functions involved in the generation of
> ANSI-standard SQL92.  Then I would write another module for each of
> the vendor dialects I was going to support.  These would
> inherit/import/whatever most of the functionality from the base SQL92
> module, and override a few key small "private" functions here and
> there to work around that vendor's quirks.
>
> Since there is no apparent concept of things like classes and
> inheritance, how does one accomplish this sort of code reuse?  Do I
> have to export all of the guts in the base module, and then provide
> explicit stubs to call all of them from the upper-layer module?
>
> 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)?
>
> Does an external interface to a relational database (or even mnesia)
> "count" as mutable state, or is that ok since it's not in my Erlang?
>
> Does the previous answer change depending whether my code makes
> decisions based on state from the database (like case statements on
> variables that were populated via a SQL call)?
>
> If I decide an app needs mutable state somewhere, what's the fallout
> (can't be analyzed / proven by some tools that actually exist? Just
> more difficult to debug?).
>
> I keep turning this "mutable state" thing over and over in my head and
> getting nowhere.  These are the kinds of things going through my head:
>  The outside world is full of mutable state.  Does that mean that any
> code with real inputs has mutable state by definition?  Input is
> technically mutable state is it not?  If I had an Erlang-based web
> server which takes different code paths depending on http inputs it
> loops on, does this not make for mutable state?  It would seem that if
> you take that sort of ultra-conservative view, then the only software
> one can write that's completely free of mutable state would be one
> with no inputs (like say, an application that just generates digits of
> Pi).
>
> -- Brandon
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>

Optimism is an essential ingredient of innovation. How else can the
individual favor change over security?

  -- Robert Noyce