[erlang-questions] Random newbie stuff

[Dennis Byrne]

Here are some answers to #2. 
http://notdennisbyrne.blogspot.com/2007/10/psst-erlang-has-mutable-state.html

In short, mutable state limits how concurrent the application can be.
____________________________________________
Dennis Byrne
ThoughtWorks - Chicago
312-505-7965





"Brandon Black" <blblack@REDACTED> 
Sent by: erlang-questions-bounces@REDACTED
11/03/2007 06:37 PM

To
erlang-questions@REDACTED
cc

Subject
[erlang-questions] Random newbie stuff






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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20071103/539a9824/attachment.htm>