Erlang/OTP R10B-10 has been released

[Romain Lenglet]

> 	Another thing. A major use of the preprocessor is conditional
> 	compilation, e.g.
>
> 	  -ifdef(POLITICALLY_CORRECT)
> 	  pi() -> 3.0.
> 	  -else.
> 	  pi() -> 3.14159.
> 	  -endif.

Doesn't that look like a need for polymorphism / abstract 
delegation?

There are several ways to do that in Erlang:

- at clause-level (as suggested earlier):

-module(client).
-export([start/1]).
start(Alternative) -> pi:pi(Alternative).

- module(pi).
-export([pi/1]).
pi(us) -> 3.0;
pi(_) -> 3.14159.


- at module-level:

-module(client).
-export([start/1]).
start(Module) -> Module:pi().

-module(pi1).
-export([pi/0]).
pi() -> 3.0.

-module(pi2).
-export([pi/0]).
pi() -> 3.14159.


- at process level (I think, the most "Erlang-ish"):

-module(client).
-export([start/1]).
start(Pid) -> gen_server:call(Pid, pi).

-module(pi1).
...
handle_call(pi, From, State) ->
    {reply, 3.0, State}.

-module(pi2).
...
handle_call(pi, From, State) ->
    {reply, 3.14159, State}.


I just wanted to illustrate that the problem of choosing 
alternatives in an architecture can be solved by polymorphism / 
abstract delegation and depencency injection. Separating 
alternatives in different modules / processes and using an ADL 
solves such configuration problems.
No need for a pre-processor, or for a -D<feature>=<value> 
compiler option.
I admit that for the simple example above it is like using a 
hammer to kill a fly. ;-)
And they may not solve problems such as compiler / dialect 
differences as Richard A. O'Keefe described. But do such 
problems ever occur in Erlang?

-- 
Romain LENGLET