Erlang improvement?

[Kostis Sagonas]

Dear Erlang users,

The HiPE group, besides developing a faster implementation of Erlang,
is also aiming at cleaning up the language from some (occasionally
unfortunate) constructs which were once upon a time added to the
language (perhaps for a good reason) but are arguably not so useful
anymore, ugly, or add unnecessary overhead to some operations.

Today, we stumbled upon one of these "remains of the past", and
decided that it is probably not worth our while to support this, in
our opinion weird, construct in HiPE.  We instead think that it is
probably a better idea to discontinue its support from future
releases of Erlang/OTP.

We would like to use this forum to conduct a poll on whether Erlang
users really use this "feature" and whether there are applications out
there that depend on this.  So, if you do have an application that
uses this construct, please do speak up at this point.


In Erlang, it is currently possible to write the following:

%%===============================================================
-module(erlang_is_a_fun_language).
-export([test/0,f/2]).

test() ->
  t2(?MODULE,f).

t2(M,F) ->
  {M,F}(bar,42).   %% WEIRD SYNTAX FOR "funs"

f(_,_) ->
  ok.
%%===============================================================

Instead, we think that the following syntax is a much better way to
write the above:

%%===============================================================

t2(M,F) ->
  M:F(bar,42).

%%===============================================================

I hope that everybody is in agreement up to this point.


Of course, there would not be any problem if it were always possible
to syntactically recognize these uses.  Then the e.g. BEAM compiler
could apply this transformation automatically.  Unfortunately, it is
currently possible to write the following:

t1(PAIR_AS_FUN) ->
  PAIR_AS_FUN(foo,42).

and at runtime call t1/1 as

  t1({?MODULE,f}).

In other words, one can create a "fun" out of a 2-element tuple which
of course implies a runtime check everytime a fun_call is encountered.
Notice that probably the only reason to use this feature is so as to
be able to pass only one argument that is not deconstructed when using
it as a fun.

Questions:

 1. Are there actual uses of this thingie?

 2. Will you feel deprived of something if the support for this
    "feature" is discontinued?

 3. Will you object if this happens soon?


Your input is appreciated.

Best regards,

Kostis Sagonas (for the HiPE group).