<br><font size=2 face="sans-serif">Hello Ulf,</font>
<br>
<br><font size=2 face="sans-serif">If you have a function that is 100%
predictable, couldn't there be some serious performance gains given that
the function is frequently passed the same message?  In other words,
why put a core to work calculating the result you gave last time someone
sent you a given message?  It would be better to use this function
to spawn a process that could use the process dictionary as a cache (one
that would never expire).  </font>
<br>
<br><font size=2 face="sans-serif">Unless ... are gets and puts to the
dictionary thread safe?</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>"Ulf Wiger" <ulf@wiger.net></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/04/2007 06:26 AM</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">"Brandon Black" <blblack@gmail.com></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</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">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [erlang-questions] Random newbie
stuff</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>2007/11/4, Brandon Black <blblack@gmail.com>:<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>
Actually, the qlc module does more or less this. It allows you to plug<br>
in different table generators, so that you can combine data from<br>
different sources in a list comprehension.<br>
<br>
The generator "plug-ins", are higher-order functions.<br>
<br>
You can choose to either use modules as "classes", along the<br>
lines of the OTP behaviours - gen_server, gen_event, etc. - or<br>
"funs" that specialize certain aspects of a function.<br>
<br>
Xmerl allows the user to provide funs that specialize nearly<br>
every aspect of XML processing: one fun that fetches the file,<br>
one that accumulates complete elements, one that closes<br>
the file, etc.<br>
<br>
On a smaller scale, the lists module exports functions that<br>
can can be specialized using funs: lists:sort/2, lists:zipwith/3,<br>
lists:foldl/3, etc.<br>
<br>
You also have modules like ordsets, which define a data structure<br>
with well-known semantics. Ordsets are ordered lists, by definition.<br>
The ordsets module exports a number of functions that can be used<br>
on sets (deliberatly identical to those of the sets module), but since<br>
the data structures are documented as lists, you know that all<br>
operations that are valid on lists are also valid on ordsets (although<br>
some of them may turn the data into something that is no longer an<br>
ordset.)<br>
<br>
Inheritance is not a first-class citizen in Erlang, but there are many<br>
ways to go about achieving code reuse through informal inheritance.<br>
Some of these approaches could be made more automatic, but there<br>
is always a cost to adding things - tools or syntax.<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>
One reasonably common problem is when you've designed an<br>
interface with a strictly limited set of parameters, and then need<br>
to extend the functionality in a way that forces data to be carried<br>
across between subsequent calls. You will then need to invent<br>
something that can maintain state between calls, unless you can<br>
get the caller to do it for you (by passing an opaque parameter).<br>
<br>
One way to solve this is of course to use a process. Note that the<br>
process may well use immutable state internally, but to an outsider,<br>
the state appears to change continuously. The thing that you get with<br>
immutability is that a piece of data, once bound, is guaranteed not<br>
to change. You have to create a new instance by (conceptually)<br>
copying the data. Note that the runtime system is free to decide<br>
that old data can be reused, just as it can choose to send data<br>
by reference between processes sometimes.<br>
<br>
The main advantage of immutable state is that a function that<br>
doesn't "cheat" by using the process dictionary, ets, message<br>
passing etc, is guaranteed to always produce the same result<br>
every time it is called with the same set of parameters.<br>
<br>
Of course, this isn't much of a guarantee, at least not to someone<br>
used to Haskell. Haskell offers a way to clearly state that something<br>
dirty is about to happen. This allows the compiler to know which<br>
functions are guaranteed to have the nice property of being fully<br>
predictable.<br>
<br>
Erlang doesn't provide the same level of guarantees, but the<br>
programmer can usually still rely on this, as long as some care is<br>
taken to keep side-effects grouped together and separate from<br>
the large parts of code that really doesn't need them, and which<br>
should be 100% predictable.<br>
<br>
BR,<br>
Ulf W<br>
_______________________________________________<br>
erlang-questions mailing list<br>
erlang-questions@erlang.org<br>
http://www.erlang.org/mailman/listinfo/erlang-questions<br>
</font></tt>
<br>