[erlang-questions] Why isn't erlang strongly typed?

[Jason Ganetsky]

Dynamic typing also helps a lot with Erlang style message passing. If you
want to see a statically typed language with almost-Erlang-like message
passing, check out Phillip Wadler's Links.

Erlang-style selective receive can't be done in Links (because its receive
statement must exhaustively cover all patterns in order to type-check). In
order to get similar functionality in a static typing environment, message
passing must be replaced with a more complicated concurrency paradigm like
join-calculus.

Also, message passing complicates the typing system. Functions have a more
complicated type (instead of A -> B... A ~ C -> B... which means the
function can receive a message of type C while executing). All other
statements have an implicit message type which depends on the context of the
statements around it. It gets harder for the programmer to mentally
type-check the program.

Another issue with static typing arises when handling process death.
Monitoring a process would require the type of the reason to match up with
the code receiving the {'EXIT',...} message. So, every process is of type
process (m, d)... where m is the type of message it can receive, and d is
the type of the death reason. You would link() would only be able to called
from process (a, _) onto process (_, a). It's restrictive.

Anyway, I like static typing, but these issues would have to get solved.
They are necessarily simple.

2008/10/21 Robert Virding <rvirding@REDACTED>

> I think a lot of confusion here among different issues:
>
> - Erlang is strongly typed, you cannot get around the type system and
> functions complain (generate exceptions) when they don't get the right types
> - It is, however, dynamically typed and not statically typed in that the
> types are checked at run time and not at compile time
> - If you deem the documentation and function arguments/returns to be
> confusing this has absolutely nothing to do with typing, whether strong,
> weak, static or dynamic.
>
> That it is dynamically typed really does help with hot code loading.
> Otherwise you either have static and unchangeable module interfaces or you
> could get a system which is *really* unsafe, a function is called with one
> data type and thinks it is getting another and doesn't check as it knows the
> compiler has checked. Distribution makes this problem worse.
>
> I will freely admit that some of the functions don't always have intuitive
> arguments, are inconsistent or otherwise don't uphold the principle of least
> surprise. One reason for this is that the system evolved rather freely over
> time and many things (useful) things were just added to the system without
> much consideration for consistency and such. And, as everyone who has tried,
> knows changing things afterwards is *not trivial*.
>
> Robert
>
> 2008/10/21 Steve Davis <steven.charles.davis@REDACTED>
>
> On Oct 21, 9:45 am, Rapsey <rap...@REDACTED> wrote:
>> > I don't understand. What does this have to do with the language being
>> > strongly typed?
>>
>> Well, the way I think about it is that types let you define what the
>> function expects, and what you can expect in return. So it would
>> provide a contract or agreed protocol in a far more cohesive way that
>> is possible right now in erlang (cf. "spec" and "record"). Types would
>> speed up coding as it would avoid you having to dig around in every
>> function's source to see what you should expect in return. There's
>> probably some fatal flaw in this thinking -- which is why I asked the
>> question :)
>>
>> /s
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20081021/b0258746/attachment.htm>