C[omp]ute

From: "andrew cooke" <andrew@...>

Date: Sun, 15 Apr 2007 12:18:37 -0400 (CLT)

I have been playing around with Erlang this weekend.

While I haven't yet used the threading stuff I have written a parser
combinator library (although Erlang does include some kind of yacc-like
tool).

Some random observations:

- Apart from the message sending and infrastructure, it's a very simple,
pure functional language.  There's no mutable state (no Monads, no mutable
references) except for (i) global process namespace (thanks to Kragen for
pointing this one out) and (ii) an integrated "object" database.

- The hot code replacement stuff makes working in the shell a pain (I
couldn't work out how to force recompiled code to load!), so the best
thing to do is use the emacs mode fully (which includes an embedded shell
and forces reload on recompile).

- Dependencies aren't recompiled automatically.  There is a make-like
tool, but I haven't used it and don't know how well it's integrated with
the emacs edit/compile/run cycle.

- Error messages could be a little less cryptic.  Syntax errors in
particular give you just the line number to work with.

- For a functional language the handling of higher order functions is very
clumsy.  While functions can be invoked on arguments via the usual syntax:
  foo(...)
  module:foo(...)
they cannot be referred to as such:
  lists:map(foo, [...]) % error
  lists:map(module:foo, [...]) % error
instead you need to use a {module, name} tuple;
  lists:map({module, foo}, [...])
And if an expression evaluates to a function it cannot be applied
directly.  Instead, the whole thing must be enclosed in parens:
  hof(...)(...) % error
  (hof(...))(...)

- In general the docs are good.  However I couldn't find anything that
described inline operators (++, --, arithmetic, others?).  Partly because
these are difficult to search for...

- For some reason (strange compatibility with shell stadards) the regexp
(which is much more limited than perl5) will not match " *" against the
empty string(!).

- There are a couple of language extensions that seem a bit "ad-hoc" and
poorly integrated.  One is support for records (named access to tuple
fields).  The other is a kind of ADT (called "behaviours").  Don't have
more specific criticism of these yet as I haven't used them.

Andrew