[erlang-questions] The Erlang Rationale
Wed Oct 1 05:50:06 CEST 2008
On 1 Oct 2008, at 2:30 am, Robert Virding wrote:
> OK, OK, OK, enough already! :-) I will fix the next version in PDF.
> And I thought this was a bunch of computer savvy people who would
> just laugh at Word format.
I take software piracy seriously,
so I do not laugh when I see people giving financial
support to a large company convicted of software piracy,
especially when there are free alternatives (AbiWord,
OpenOffice) and when an open format (HTML) would have
done just as good a job.
"i.e. large switches" should be "i.e., large switches".
"handle large number" should be "handle a large number"
Immutable data structures: (1) they eliminate the classic
OO problem "what happens when you are iterating over a
collection and the collection changes" because it can't;
(2) just today in Haskell-Café someone was complaining about
a data structure in C# (hence in F#) not being thread-safe
for no apparent reason, immutable data structures means you
can't make a thread-unsafe data structure.
"all messages sent were complete, no partial messages"
-- if you are using two or more node, what exactly stops
a message sent from one node to another arriving only in
part? Communications networks are unreliable, after all.
"The level of security in the message protocol" -- I think
you need to explain why asynchrony avoids problems with
this, it's certainly not obvious to me.
"I still think is was" s/is/it/
"distribution were nodes were" s/were nodes/where nodes/
"Generic requests to an i/o server"
"while the with" s/the //
I never did get my head around the I/O protocol, not least
because it didn't seem to be written down anywhere. I am
very happy indeed to see this discussion of I/O requests.
Being a Bear of Very Little Brain, I *still* don't get how
to do the continuation stuff.
It might be worth while splitting this out as a separate
document and putting in enough idiot-level examples so that
I finally get it. [Beg beg.]
The first straightforward explanation of the idea I've ever
seen. Are there any plans to extend this feature or its use?
'It would be good to have some example programs' -- you took
the words out of my keyboard.
"SHAPE \* MERGEFORMAT" I take to be an artefact of the way
the PDF was produced.
"the '=' operator"
What you do not mention, and what would strengthen your position,
is that in those languages that have 'let', the '=' sign is usually
an essential part of the syntax.
ML let val <pattern> = <expression> in <expression> end
Haskell let <pattern> = <expression> in <expression>
<function bodies> where <pattern> = <expression>
['let' and 'where' were in ISWIM, if I recall correctly.]
So there is nothing in the least unusual in the functional world
about <pattern> = <expression>.
"take apart you cake" s/you/your/
The thing that *is* rather unusual is allowing '=' inside
function calls and having the bindings percolate out. The
introduction of 'fun' and list comprehensions has also done
bad things to the simple 'the scope of a variable is the
entire clause it occurs in' rule.
Named constants should have been <pattern> = <guard expression>
at top level. I've tried rewriting some modules that way to see
what it looks like and it's beautiful. I grant the utility of
-include, but that's not macros. If I want M4 I know where to
find it. I have CScout to help me cope with C code that's full
of macros, but unless I can talk Diomidis Spinellis into it (and
he has other maddened grizzly bears to stun) there isn't and won't
be an EScout. Macros make maintenance *harder*.
"en Erlang point of view" s/en/an/
"Variable scoping and 'let'"
This is the perfect opportunity to mention LFE and point out
that people who want to try an alternative approach to scoping
have something they can play with.
I note that 'begin' ... 'end' were originally introduced in the
form "begin <bindings> within <expressions> end".
I take these lines at the end to be another artefact of the
Weird->PDF conversion process.
More information about the erlang-questions