<br><font size=2 face="sans-serif">Here are some answers to #2.  http://notdennisbyrne.blogspot.com/2007/10/psst-erlang-has-mutable-state.html</font>
<br>
<br><font size=2 face="sans-serif">In short, mutable state limits how concurrent
the application can be.</font>
<br><font size=2 face="sans-serif">____________________________________________<br>
Dennis Byrne<br>
ThoughtWorks - Chicago<br>
312-505-7965<br>
<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>"Brandon Black"
<blblack@gmail.com></b> </font>
<br><font size=1 face="sans-serif">Sent by: erlang-questions-bounces@erlang.org</font>
<p><font size=1 face="sans-serif">11/03/2007 06:37 PM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">erlang-questions@erlang.org</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">[erlang-questions] Random newbie stuff</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>Hi,<br>
<br>
I'm new to Erlang and to FP in general, but I have a fair amount of<br>
experience in various non-FP languages.  I've gotten about halfway<br>
through "Programming Erlang" so far (and skipped ahead on a few<br>
things), and I've got some questions I hope someone can answer...<br>
<br>
1) "Inheritance"<br>
<br>
Forgetting for a moment OO <-> Erlang holy wars and battles about<br>
syntax and semantics, in a practical sense, is there any way to<br>
inherit code for re-use in Erlang?  I can imagine many scenarios where<br>
it would be useful, here's a concrete one for example:  Suppose one<br>
were writing an Erlang module that parsed list comprehension syntax<br>
and converted it into some sort of SQL equivalent as part of an Erlang<br>
<-> RDBMS interface.<br>
<br>
My first instinct (thinking in regular OO terms) would be to write a<br>
well-structured module with a only a few public functions exported,<br>
with many little private functions involved in the generation of<br>
ANSI-standard SQL92.  Then I would write another module for each of<br>
the vendor dialects I was going to support.  These would<br>
inherit/import/whatever most of the functionality from the base SQL92<br>
module, and override a few key small "private" functions here
and<br>
there to work around that vendor's quirks.<br>
<br>
Since there is no apparent concept of things like classes and<br>
inheritance, how does one accomplish this sort of code reuse?  Do
I<br>
have to export all of the guts in the base module, and then provide<br>
explicit stubs to call all of them from the upper-layer module?<br>
<br>
2) State Mutability...<br>
<br>
How important is it to maintain immutable state?  Are there classes
of<br>
problems (classes of applications) which cannot be built without<br>
mutable state (for which one would use process dicts or [d]ets)?<br>
<br>
Does an external interface to a relational database (or even mnesia)<br>
"count" as mutable state, or is that ok since it's not in my
Erlang?<br>
<br>
Does the previous answer change depending whether my code makes<br>
decisions based on state from the database (like case statements on<br>
variables that were populated via a SQL call)?<br>
<br>
If I decide an app needs mutable state somewhere, what's the fallout<br>
(can't be analyzed / proven by some tools that actually exist? Just<br>
more difficult to debug?).<br>
<br>
I keep turning this "mutable state" thing over and over in my
head and<br>
getting nowhere.  These are the kinds of things going through my head:<br>
 The outside world is full of mutable state.  Does that mean that
any<br>
code with real inputs has mutable state by definition?  Input is<br>
technically mutable state is it not?  If I had an Erlang-based web<br>
server which takes different code paths depending on http inputs it<br>
loops on, does this not make for mutable state?  It would seem that
if<br>
you take that sort of ultra-conservative view, then the only software<br>
one can write that's completely free of mutable state would be one<br>
with no inputs (like say, an application that just generates digits of<br>
Pi).<br>
<br>
-- Brandon<br>
_______________________________________________<br>
erlang-questions mailing list<br>
erlang-questions@erlang.org<br>
http://www.erlang.org/mailman/listinfo/erlang-questions<br>
</font></tt>
<br>