[erlang-questions] Erlang 3000?

[Robert Virding]

This is a comment to lots of stuff, not just Kevins post.

2008/11/16 Kevin Scaldeferri <kevin@REDACTED>

>
> With regards to my point (3), what I am saying is that in languages with a
> "normal" if-statement, one often writes something like:
>
> if (thing = lookup(foo)) {
>   ... do stuff with the thing...
> } else {
>  ... it wasn't there
> }
>

Normal in this case means false/nil/0/whatever and everything else is true.
This may be practical but it is really not an 'if'. I personally think that
this is better expressed by:

case lookup(foo) of
    {yes,Thing} -> ...;
    no -> ...
end

Most of the collection modules support this type of return value.

Of course, this relies on (a) having an if-statement that works like this,
> and (b) nil/undef/null being false in boolean context.  Neither is the case
> in Erlang, so one instead tends to use a case, and it doesn't really matter
> if the return value of lookup is useful in boolean context.
>

Yes, and I think that is better. It is much more explicit what you mean.

I absolutely agree that the collection modules we have have an appalling
lack of consistency in their API's, most of it completely unnecessary. This
is a result of how erlang was developed and grew. One could say the downside
of having such a need driven development. The upside being of course that
things you develop and add are really significant. This is something I will
have to expand on later.

There are many different levels at which Erlang could be modified/enhanced,
one of course would be to "just" rewrite the libraries and make them more
consistent. This would be a big win just in itself.

Changing the funsdamentals of the language is more difficult. (duh!)

One problem is to decide what is the language and where the libraries
starts. My opinion has always been that the BIF's, not necessarily just
those written in C, are part of the language. Many are as fundamental as !
and receive except that they don't have a special syntax and look like
normal function calls. So the module erlang is really part of the language,
well much of it anyway.

Another problem, which somoeone also pointed to, is that many features of
the language are very tightly integrated with each other and once you start
poking at one you end up affecting them all. A simple example is, of course,
pattern matching which is used everywhere and has the same behaviour
everywhere. A much more subtle example is concurrency, messages,
links/signals, receive, immutable data, error handling, ports, ... which all
interact with each other and, in most cases, work coherently together and
affect each other. Fiddling with them is much more difficult than at first
it may seem.

This is one of the points I try to make in my (as yet incomplete) Erlang
Rationale. Will it ever be complete? Here I see a definite problem for an
Erlang 2. Not insurmountable of course, but finally someone will have to put
their foot down.

Syntax is another problem, maybe practically even more difficult, but in one
respect actually not too difficult. The main point is that the syntax and
the semantics must "fit together" and support each other. This is one reason
why I am not too keen on using a C/Java like syntax, it was designed for
completely different semantics.

More thoughts later,

Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20081116/c3995233/attachment.htm>