Algorithmic lists

[Simon Bennett]

Is this what is known as lazy evaluation in functional programming
terms?
i.e. it allows you to define a possibly infinite list, and the values in
the list are only evaluated and returned as and when they are required?

If this is the case, it brings Erlang closer to the idea of an
executable specification (which people were discussing in the context of
"Who is a Programmer?") as you can define a set by intension rather than
by extension.

Simon Bennett
___________________________________________________________________

 Simon Bennett            E-mail:     simonb@REDACTED
 Ericsson Intracom        http://www.ericsson.co.uk/UK/intracom
 1 Bede Island Road       Voice (UK)  0116 2542400
 Leicester                Voice (int) +44 116 2542400
 England                  Voice ECN:  832 707 ext 232
 LE2 7EU                  Fax:        +44 (0)116 2046111
___________________________________________________________________


Ulf Wiger wrote:
> 
> Here's a thought:
> 
> We (a few lunatics at AXD 301) would like to see the lists module
> support an alternative formulation of lists.
> 
> A list could be expressed in the following manner:
> 
> [Head | fun(Head, F)]
> 
> Example:
> 
> -module(alglists).
> -author('etxuwig@REDACTED').
> 
> -export([seq/2, foreach/2]).
> 
> %%-export([Function/Arity, ...]).
> 
> seq(Start, Stop) when Start < Stop ->
>     [Start | fun(N, F) when N == Stop ->
>                      [];
>                 (N, F) ->
>                      [N+1 | F]
>              end].
> 
> foreach(F, []) ->
>     [];
> foreach(F, [H|T]) when list(T) ->
>     F(H),
>     foreach(F, T);
> foreach(F, [H|T]) when function(T) ->
>     F(H),
>     foreach(F, T(H, T)).
> 
> Eshell V4.8.2.7  (abort with ^G)
> 
> 1> lists:foreach(fun(X) -> io:format("-- ~p~n", [X]) end,
> lists:seq(1,5)).      -- 1
> -- 2
> -- 3
> -- 4
> -- 5
> ok
> 2> c(alglists).
> {ok,alglists}
> 3> alglists:foreach(fun(X) -> io:format("-- ~p~n", [X]) end,
> alglists:seq(1,5)).
> -- 1
> -- 2
> -- 3
> -- 4
> -- 5
> ok
> 
> (Perhaps to avoid breaking half the Erlang programs in the universe,
> functions in lists should not return lists on this form, but should be
> able to process them.)
> 
> Let me briefly tell you why we'd like to do this:
> 
> On several occasions, we've rewritten code that generates a large
> list on the heap and then traverses it. It's a shame from one
> perspective, because the new code (which usually uses ets:next/2) is
> not FP-style, and less elegant -- but it is more well behaved from a
> memory management perspective, which is its one (but vital) merit.
> We'd like to keep the concept of list processing, but avoid the large
> lists, which cause havoc in the GC.
> 
> What'ya think? Awful? Elegant?
> 
> BTW, Joe already posted something like this on the erlang-questions
> list in March '99, but he was using zero-argument funs.
> 
> http://www.erlang.org/ml-archive/erlang-questions/199903/msg00013.html
> 
> /Uffe
> --
> Ulf Wiger                                    tfn: +46  8 719 81 95
> Strategic Product & System Management        mob: +46 70 519 81 95
> Ericsson Telecom AB,              Datacom Networks and IP Services
> Varuvägen 9, Älvsjö,                    S-126 25 Stockholm, Sweden