random thoughts on language design etc.

[Chris Pressey]

I'm leaving on vacation tomorrow, and I just wanted to get down a few
unsolicited and not particularly reasoned thoughts on Erlang... :)

First, I want to make a clarification.  Once upon a time I remarked that
Erlang was like a combination of a high-level language and a low-level
language.  A better way to say what I meant at the time would be to say
that Erlang is a language which tries to make it easy to reason about the
correctness of a program *and* to reason about its performance.  For a
language which is used to program network hardware, this is a treasure.

Although it does make for awkward programs sometimes - all I can say is
that they are *much* less awkward than trying to do the equivalent thing
in C or Perl.  As I've stated before, for using Erlang for scripting,
prototyping, and such where soft-real-time isn't a primary concern, I
think it would be great to loosen the restrictions a bit and be able to
use arbitrary boolean functions in guards.  Perhaps it's possible to
transform them into case statements and issue a warning - unless they're
actually used in a 'receive', there really shouldn't be any concurrency
issues with them operating in constant time, etc - should there???

I'm probably missing something here.  I've only ever used 'if' once. 
'case' is easier for me to understand.

Function heads & selecting alternatives by pattern matching are great, but
(a) they're grouped sequentially in source code order, perhaps forcing you
to place helper functions far away from the code they're supposed to help,
*while* (b) they force you to repeat the function name anyway, even though
that can clearly be implied *if* they are in sequential source code order.
(Every clause before the '.'...)

An alternative approach to selecting which clause of the function to use
could be to order the patterns based on their specificity.  As long as
there exists a specific notion of specificity within the patterns in
Erlang, this would allow for functions which are defined over several
modules and/or extended ad hoc - and is generally 'what you mean' anyway.

e.g.

f(a,b) -> most specific (two atoms).
f(X,b) -> less specific (one atom one var).
f(X,Y) -> less specific (two vars).
f(X,_) -> less specific (one var one don't-care).
f(_,_) -> least specific (two don't-cares).

For more information, see the language Aardappel, which is very
interesting in this respect (and several others:)

http://wouter.fov120.com/aardappel/index.html

The impression I get from non-Erlang programmers is that they see Erlang
as a Prolog descendant - which it is, but it really lacks the feature that
makes Prolog *Prolog*: full-out variable unification (backtracking).

Non-programmers usually assume that it runs on cell phones.

Even though it's not strictly correct, I tend to call the io functions
io:fwrite/2 and io_lib:format/2 just because it makes their roles clearer
(one formats and writes, the other just formats.)

And I'm pretty sure even Pascal allowed an extraneous semicolon before an
'end'... :)  Still my most common syntax error.

Lastly, I want to thank everyone for all their efforts that have gone into
making Erlang the beautiful thing that it is.

Regards,
-Chris