[erlang-questions] List to proplist?

[Richard O'Keefe]

On 1 Nov 2008, at 12:05 am, Zvi wrote:
>
> I think compiler shouldn't be dependent on standard library, it  
> should be
> vice versa.

I don't see the 'language' and 'library' as being fundamentally
distinct.  Within fairly broad limits, the less that's "language"
the better.

Nothing prevents the "library" including *advice* for the compiler.
(Anyone else old enough to remember compiler macros for Lisp?)
To this day, GHC lets a library include special hints for the
compiler.  Nobody said that the special compiler knowledge about
library functions had to be *built-in*.

>
> I for example don't like special treatment of lists:reverse. If  
> there is
> some optimized feature in the compiler it should be made first-class  
> citizen
> in the language via special syntax or new keyword or reusing already
> existing syntax/keywords if it's possible and make sense.

Well, that's an interesting fact about your likes and dislikes.
>
> For example instead of of writing lists:reverse(L) - you write ~L or
> something like this.

Yeek!  I'd rather use APL!

> When you see how frequently is lists:reverse used in
> the tail-recursive functions it really make sense.

Arguably a better way would be to remove the limitation
on tail recursion that has been using reverse so much.
>
> Why there should be multiple variants for '<-' ?

And isn't that the point of what I just wrote?

> After all Erlang has
> dynamic typing, recognizing which collection type is T at run-time  
> should
> cost just one compare

You are making the unwarranted and false assumption that there
is a one-to-one correspondence between Erlang data types and
abstract sequence types.  For example, it would be nice to
iterate over gb_sets.  How do you propose to tell the difference
between gb_sets:new() -- a set with no elements -- and
{0,nil} -- a tuple with two elements -- using Erlang's dynamic
typing?  (Hint: the result of gb_sets:new() IS {0,nil}.)

> . And if type guards or type spec is present, then it
> may be recognized at compile-time.

There are no type guards for recognising gb_sets.