Erlang (was Re: Good introduction to functional programming with Python?)

[Alex Martelli]

"Tim Peters" <tim.one at home.com> wrote in message
news:mailman.977984412.30211.python-list at python.org...
    [snip]
> I haven't used Erlang at all, so that makes it an excellent battlefield:
no
> unpleasant haggling over facts <wink>.  I'll hazard a guess based on the

Right!

> In the absence of higher-order functions, I can believe programmers don't
> have much trouble reasoning about types without declarations.  They don't

The _scarcity_ (not _absence_:-) of HOF in typical Erlang use may be a
cultural issue (or maybe they just don't buy one all that much in its
typical use cases); and from that may follow the relative lack of
interest in its (existing, but 'add-on') type-inferencing possibilities.

It's not hard to find examples of Erlang HOF's on the web though --
right on http://www.erlang.org/white_paper.html we get a typically
simple one:
"""
As another an example we can write:
  > Adder = fun(N) -> fun(X) -> X + N end end.
  #Fun
  > G = Adder(10).
  #Fun
  > G(5).
  15
"""

No big fuss, and the explicit "fun(...) -> Expr end" syntax with
which, it says, "function objects are introduced"... it *does*
read better than 'lambda', methinks, but this is just a sugary
issue, of course.

Part of the 'cultural' explanation may be that not a little 'typical
FP stuff' was added relatively recently to Erlang, so it's not in
the book; http://www.erlang.org/doc/r7b/pdf/extensions-5.0.1.pdf
summarizes the additions, though, including 'Funs'.  As this doc
says,
"""
Higher Order Functions
Funs encourages us to encapsulate common patterns of design into
functional forms called higher order functions. These functions
not only shortens programs, but also produce clearer programs
because the intended meaning of the program is explicitly rather
than implicitly stated.
"""
and I suspect that the emphasis on 'explicitly rather than
implicitly stated' may charm you enough to convince you to
go easy on the author's obvious difficulty with s-endings
in English verb forms with plural subjects:-).

The typical example of HOF in this doc is:
"""
map(F, [H|T]) -> [F(H)|map(F, T)];
map(F, []) -> [].
We can now express the functions double and add_one in terms
of map as follows:
double(L) -> map(fun(X) -> 2*X end, L).
add_one(L) -> map(fun(X) -> 1 + X end, L).
"""

Actually, of course, 'map', along with several other typical
HOF's, is exported from a 'lists' module.


List comprehensions (aka 'Zermelo-Frankel', aka ZF, ones:-)
are also introduced in the same docs, with rather Haskellish
syntax if I may say so:

> [X || X <- [1,2,a,3,4,b,5,6], integer(X), X > 3].
[4,5,6]

Here, 'explicit is better than implicit' seems to have been
slightly put aside -- each qualifier is either a generator,
if it includes a '<-', or else a filter; Python's choice of
expressing this as:

>>> [X for X in [1,2,'a',3,4,'b',5,6] if type(X)==type(0) if X > 3]
[4,5,6]

looks more explicit to me (not necessarily more readable:-).


> use the static type checker because it's more trouble than it's worth!

Because the HOF's, while present, are not widely used?  Maybe.

> Fine by me.  I must say, though, that Erlang appears to occupy an extreme
> corner of the FP universe.

It sure looks unique to me for its emphasis on concurrency (if there
are other FP's that are similarly concurrency-oriented, I have not seen
them yet).  But Scheme (albeit impure) and Erlang (albeit 'culturally
not highly HOF-prone') together surely make up for a substantial share
of functional-programming use, and just as surely form a solid case for
static-typing NOT being central to FP (just as, say, Smalltalk and
Python together form a solid case for static-typing not being central
to OO, no matter how much Eiffel'ers may rant otherwise:-).


> I *like* the attitude of the Erlang developers.  Looks like a very useful
> language for its target domain.  Even better, according to FAQ 5.7.11
> there's a Python binding (if you really need some higher-order functions
> after all <wink>).

It looks to me as if the Python/Erlang interface is based on an older
(perhaps now-removed) external-functions layer of Erlang, and was only
release at a '0.1' level.  Still, Erlang's current external-functions
approaches, http://www.erlang.org/doc/current/doc/tutorial/part_frame.html,
appear to offer ample scope for such interfacing -- there's a mention
of an IDL compiler, which, as usual, sounds more interesting to me than
'point-to-point' approaches to interlanguage-operation (even when one
of the languages is Python!-).  The barely-mentioned 'IC' IDL compiler
seems to be part of OTP, the Open Telecom Platform framework for Erlang,
so I'm not going to dig into this further at this time (as I don't do
telecom programming:-), but, conceptually, it makes sense...!-)


Alex


>
> if-we-don't-act-fast-i'm-afraid-python-may-lose-the-industrial-
>     control-market-ly y'rs  - tim
>
>