[erlang-questions] Ideas for a new Erlang

[Vlad Dumitrescu]

Hi!

On Tue, Jun 24, 2008 at 4:23 PM, Sven-Olof Nystr|m <svenolof@REDACTED>
wrote:

> I have written down some thoughts and ideas on the future development
> of Erlang.
>

FWIW, I agree wholeheartedly to the motivation of this work. The language
must evolve and we'll have to try to explore all the possible futures.


> Main topics:
>   - some notes on implementation and backward compatibility
>   - an alternative to Erlang's selective receive
>   - a simple language mechanism to allow function in-lining across
>   module boundaries
>   - a new mechanism for introducing local variables with a more cleanly
>   defined semantics
>   - a mini-language to allow the efficent implementation of low-level
>   algorithms


A general comment is that I think it would be useful with more realistic
examples. The counter process gives little insight into why channels would
be useful, and the examples for the new binding mechanism are only of the
form "Var = expr" instead of more general pattern matches.

Maybe we should have a place where such suggestions could be presented? Not
everything is ready for an EEP. Searching the list archives is slightly
tedious and it's difficult to keep the discussion in the right thread. Maybe
at trapexit?

----
Regarding channels, there are several other paradigms that might be
interesting to explore. One is the "process as stream processor" one, where
processes work just like the UNIX toolkit programs by processing input
messages and sending them forward. This allows piping of processes to
compose functionality. With an appropriate syntax and machinery, the
programmer need only specify the relevant functionality desired.

This is just a teaser for an improvement to my previous attempt at
http://www.erlang.org/pipermail/erlang-questions/2007-May/026467.html :-)
I will try to make available a presentation, with more details, examples and
implementation proposals. (Since it's vacation time, it may take a few
weeks)

For example,
    tk:find(".", "*.erl") => tk:lines() => tk:grep("-author('me').") =>
tk:print()
is similar to
    find . -name "*.erl" | grep "-author('me')."
tk:lines() for example is a process conceptually running
  fun(OutPid) ->
     receive
       stop -> OutPid ! stop;
       {data, FileName} ->
         X = file:readfile(FileName),
         L = lists:split(X, "\n"),
         [OutPid ! {data, Row} || Row <- L]
    end
  end.

Or we could even have
    lists:seq(1,100) => fun(X) -> {X, X*X} end => []
where the last element in the pipe means "turn the stream into a list and
return it", as an alternative to
    lists:map(fun(X) -> {X, X*X} end, lists:seq(1, 100))
The framework would wrap
    lists:seq(1,100)
into a process running
    fun(OutPid) ->
      [OutPid ! {data, X} || X <- lists:seq(1, 100)],
      OutPid ! stop
    end
, chain together all the processes and wait for the end result.

Of course this is only a sketch, we'd want flow control and things like
that.

best regards,
Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080625/be596a7d/attachment.htm>