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

[Michael Radford]

Richard O'Keefe writes:
> > I'm sure that there's a simple and convincing answer to this.
> 
> Because Erlang was designed for systems that are
> supposed to be running all the time, even when you
> want to install upgraded software with *different*
> types.
> 
> There have been several attempts to provide type systems
> for Erlang.  It took a long time to get one that was
> found to be satisfactory in practice, but it's there now
> in documentation and in the Dialyzer and Typerl.

I'm not familiar with Typerl, but Dialyzer only does static analysis
for a single version of each module, right?  (It provides no way
to check the correctness of a code_change handler between two versions?)

It seems to me that static typing in Erlang could work if there were a
way to load multiple modules atomically.  All exported functions would
be annotated with the types of their arguments and return values, and
all inter-module calls would be annotated with the types of the
arguments passed and uses of return values.  It could be illegal to
perform a module load that resulted in badly typed inter-module calls.
And when a load failed due to a type error, the previous version could
continue running -- whereas today there will be a transient failure when
an exception is raised.

Other than the expense of all that type analysis (which could be done in
advance for the versions involved, and just recorded in the compiled
code), is there a flaw in this scheme?

Sometimes the type inference would be intractable I guess.  In those
cases, a manual annotation could override the checking, and we'd be back
to the possibility of a runtime exception.  Still, this seems like an
improvement over the current situation.

Mike