[erlang-questions] List to proplist?

[Richard O'Keefe]

On 30 Oct 2008, at 1:58 am, Richard Carlsson wrote:
> I was going to comment on this before, but didn't get around to it.
> Please don't use the return convention above;

namely, [] to represent an empty list and [Head|Tail] to
represent a non-empty list.

> it is not normal
> Erlang programming style, and introduces an improper list for no
> really good reason.

You don't think that representing a list cell is a good reason
to use a list cell?  If the Dialyzer cannot represent the type
[] + [T | seq(T)], so much the worse for the Dialyzer.

As it happens, I tried a more usual Erlang style at first,
and decided it was pointlessly un-mnemonic (as well as
pointlessly inefficient).

      unfold(State, Splitter) ->
          Splitter(State, [],
              fun (X, State1) -> [X|unfold(State1, Splitter) end]).

where we have

     unfold :: state -> 			   % initial state
               (state ->			   % current state
		result ->		   % what to do if empty
		(item -> state -> result) % what to do if not empty
		-> result)		   % result of splitter
	      -> result			   % result of unfold

For counting, splitter might be

     fun (N, Nil, Cons) ->
	if N > Limit -> Nil
          ; N =< Limit -> Cons(N, N+1)
         end.

[Note Return of Cons] Cons here is a function, but it's
basically playing the role that [_|_] did in the previous
version.

The problem with the type given for 'unfold' above is
'item'.  Dealing with it seems to require advanced type
system machinery like existential types (or possibly
dependent types) so unfold is _really_

	unfold :: state -> (E item . state -> result ->
		  (item -> state -> result) -> result) -> result

Somehow, returning a pair to represent a pair just doesn't seem
so evil.

> A more traditional return convention would
> use e.g., {Item,State1} | 'none'.

Where the use of 'none' rather than 'empty' or 'end' or
'finished' or 'false' is rather arbitrary.  The use of []
to represent an empty list is not arbitrary.

Frankly, when the idea of using [] to represent [] and
[_|_] to represent [_|_] struck me, I was pleasantly
surprised at the naturalness of the result.

But then I am a Bear of Very Little Brain.

What _really_ matters is that _some_ form of unfold/2
be adopted, and if it uses a lengthier, less readable,
and less efficient (but Dialyzer-friendlier) style,
sobeit.

I shall think of a Hum to comfort myself.