Lambda the Ultimate

Before I start whining, let me make it clear that I have only just started using Erlang, and have written a total of 30 lines of code. This is just my initial impression.

Erlang is giving me a bad taste in my mouth for two reasons.

The first reason I don't like Erlang is that the syntax is reminiscent of Prolog, but the semantics are lacking everything that made Prolog interesting. Fine, there's no backtracking -- I can live without that. But what I miss most is that Erlang variables are not logic variables. What I mean by this is that you can't pass around unbound variables. The only time you can use an unbound variable is on the left-hand-side of an assignment, where it will be bound immediately thereafter.

This means that Erlang functions cannot be bidirectional, the way Prolog functions can. In Prolog, you can call a function foo(A, B) in such a way that either A or B can be the input variable, and the other can be the output variable. This feature lets you do all kinds of neat things: for example, using the same function for both creating and traversing a tree structure. [Aside: In the Oz language, unbound variables are used to provide an excellent mechanism for synchronizing with worker threads.]

The second reason I don't like Erlang is its anonymous function syntax. I have yet to find a way to write them that doesn't feel exceedingly clunky. For example, here is my first cut at a function to invert an ets table:

% This function takes an ets table SrcIdx, inverts it, and stores 
% the result in the ets table DestIdx.
invert_ets(SrcIdx, DestIdx) ->
        ets:foldl(fun({Key, Vals}, _) ->
                        lists:map(fun(Val) ->
                                        [{Val, Keys}]=ets:lookup(SrcIdx, Val),
                                        ets:insert(DestIdx, {Val, [Key|Keys]})
                                  end,
                                  Vals)
                  end,
                  unused, SrcIdx),
DestIdx.

This function is way too indented. I would have liked to move the inner fun up a level like this:

invert_ets(SrcIdx, DestIdx) ->
        InsertPair = fun(Key, Val) ->
                             [{Val, Keys}]=ets:lookup(SrcIdx, Val),
                             ets:insert(DestIdx, {Val, [Key|Keys]})
                     end,
        ets:foldl(fun({Key, Vals}, _) ->
                        lists:map(InsertPair(Key), Vals)
                  end,
                  unused, SrcIdx),
DestIdx.

... but unfortunately this version won't work, because it requires currying, which Erlang doesn't support. The only way for "Key" to be in scope is if the InsertPair fun is nested inside the other fun.

Erlang's implementation also loses some points for having exceedingly cryptic error messages. For example, this error message is trying to tell me that the function shell_default:lookup() is not defined:

10> lookup(Q, foo).
** exited: {undef,[{shell_default,lookup,[18,foo]},
                   {shell,local_func,4},
                   {erl_eval,exprs,4},
{shell,eval_loop,2}]} **

To be fair though, the error messages aren't really any worse than some of the type-related error messages from hugs (a haskell implementation), and I'm sure I would become well trained at decoding them in time.

One thing I really do like about Erlang is its use of atoms pretty much everywhere. For example, in the error message above, every single word in the error message is an atom, instead of a string. I like how lots of functions return 'ok' as their result, instead of a boolean value. I'm not sure why I like atoms so much -- it's probably just a style thing.

At this point in its development, it's very obvious that Erlang grew organically, in directions that were not envisioned from the beginning. Case in point: the fact that records require header files and a preprocessor.

Yes, the preprocessor implementation of records and other funky aspects struck me funny too.

I came to the conclusion that Erlang is not to be loved for its sequential functional programming as much as for its concurrent programming aspects.

Although I do like the pattern matching and single assignment. (Would prefer a better lambda syntax and a "let" syntax instead of single assignment. I didn't expect logic variables I think because I had been programming a bit in Haskell just prior to picking up Erlang around 1999.

I discontinued using Erlang for these reasons, being fond of the achievements in concurrency patterns more than the language per se.

But I have to agree that logical variables are about as un-Icky as you can get. One related question - is there any practical use for difference lists with two "real" lists (ie where the second list is more than just an unbound variable)?

Also, anyone got time to dig up whether there's a Scheme or Lisp implementation of logic variables (I don't mean a Prolog-like emulation, but something that switches the basic language syntax - or is that a naive distinction)?

PS That looks like a stack trace, not an error message.

Yes there are those. Google should turn up something, try Dan Friedman's page at Indiana.

You want Prolog syntax implemented in Scheme or Lisp? Maybe you can find one. The syntax is not too complex, so a translator to an existing Lisp syntax and implementation should not be too hard if you really want it.

Also there is a Python implementation that also implements a Prolog like syntax. I happen to be deep into Python at the moment so I have this link handy...

http://christophe.delord.free.fr/en/pylog/index.html

Unfortunately for Erlang, I had relatively high expectations for the language, and those were largely based on the mistaken belief that it was a logic language instead of a functional language. My current understanding is that Erlang excels at concurrent programming, not algorithmic programming. I may someday get around to exploring its concurrent features, but that's not the goal of my current language exploration project.

P.S. It's actually both a stack trace and an error message.

Look at what happened to Paul, for example. 8^)

One connection to Prolog which I was happy to discover is that the first proto-implementation of Erlang was based on a meta-circular Prolog interpreter.

http://lambda-the-ultimate.org/classic/messagx6200

It is currently being maintained as part of CLOCC:

http://clocc.sf.net

Chris.

Erlang *experts* might even have some insights for completing the Inverted Index task using Erlang.

After finishing a batch of Win32 Shootout programs in Ada (sorry Ehud!) it was obvious that I would need to learn much more before I could write "the Ada way". Fortunately, I did enough to encourage someone with Ada experience to take on the task.

Ada is Icky ?
Well that would have been just a tad presumptious ;-)

Sequential Erlang, from my point of view, provides the dynamism of Python and Lisp, but in a more modern functional setting. Interestingly, Erlang scores significantly higher than Python on most sequential benchmarks (by 2-4x in many cases). Erlang: The functional scripting language?

invert_ets2(S, D) ->
    foreach(fun({Key, Vals}) -> foreach(pair_inserter(S, D, Key), Vals) end,
	    ets:tab2list(S)).


pair_inserter(S, D, Key) ->
    fun(Val) ->
	    [{Val, Keys}] = ets:lookup(S, Val),
	    ets:insert(D, {Val, [Key|Keys]})
    end.

(with foreach/2 imported from the lists module..)

Or maybe there is just a Better Way - what's the function's specification?

Then we can write the invert function in three lines. Here's a module with a simple test case.

-module(invert).
 
-export([test/0, invert/2, lookup/2]).
-import(lists, [foreach/2, sort/1]).
 
%% Insert the inverse mapping of table S into table D.
invert(S, D) ->
    foreach(fun({Key, Val}) -> ets:insert(D, {Val, Key}) end,
	    ets:tab2list(S)).
 
%% Lookup the mappings from Key in Tab.
%% Returns: [Value]
lookup(Tab, Key) ->
    [Val || {_, Val} <- ets:lookup(Tab, Key)].
 
test() ->
    ets:new(a, [named_table, public, bag]),
    ets:new(b, [named_table, public, bag]),
    ets:insert(a, {bar, foo}),
    ets:insert(a, {baz, foo}),
    invert(a, b),
    %% Assert that "bar -> foo; baz -> foo" inverts to "foo -> bar, baz"
    true = sort(lookup(b, foo)) == [bar, baz].