Hi!<br><br><div class="gmail_quote">On Tue, Jun 24, 2008 at 4:23 PM, Sven-Olof Nystr|m <<a href="mailto:svenolof@it.uu.se">svenolof@it.uu.se</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I have written down some thoughts and ideas on the future development<br>
of Erlang.<br>
</blockquote><div><br>
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.
 <br>
</div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Main topics:<br> 
- some notes on implementation and backward compatibility<br> 
- an alternative to Erlang's selective receive<br> 
- a simple language mechanism to allow function in-lining across<br>
   module boundaries<br> 
- a new mechanism for introducing local variables with a more cleanly<br>
   defined semantics<br> 
- a mini-language to allow the efficent implementation of low-level<br>
   algorithms</blockquote><div><br>
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. <br>
<br>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?<br>
<br>----<br>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. <br>
<br>This is just a teaser for an improvement to my previous attempt at
<a href="http://www.erlang.org/pipermail/erlang-questions/2007-May/026467.html">http://www.erlang.org/pipermail/erlang-questions/2007-May/026467.html</a>
:-) <br>
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)<br>
<br>For example,<br>    tk:find(".", "*.erl") => tk:lines() => tk:grep("-author('me').") => tk:print()<br>is similar to<br>    find . -name "*.erl" | grep "-author('me')." <br>
tk:lines() for example is a process conceptually running<br>  fun(OutPid) -> <br>     receive <br>       stop -> OutPid ! stop;<br>       {data, FileName} -><br>         X = file:readfile(FileName),<br>         L = lists:split(X, "\n"),<br>
         [OutPid ! {data, Row} || Row <- L]<br>    end<br>  end.<br><br>Or we could even have<br>    lists:seq(1,100) => fun(X) -> {X, X*X} end => []<br>where the last element in the pipe means "turn the stream into a list and return it", as an alternative to<br>
    lists:map(fun(X) -> {X, X*X} end, lists:seq(1, 100))<br>The framework would wrap <br>    lists:seq(1,100) <br>into a process running<br>    fun(OutPid) -> <br>      [OutPid ! {data, X} || X <- lists:seq(1, 100)], <br>
      OutPid ! stop <br>    end <br>, chain together all the processes and wait for the end result. <br><br>Of course this is only a sketch, we'd want flow control and things like that.<br>  <br>best regards,<br>
Vlad<br>
<br> 
<br></div></div>