Apparently, Erlang does not have a static type system, since with hot code loading, this is intrinsically difficult. "Erlang Programming", Francesco Cesarini & Simon Thompson, June 2009, O'Reilly, page 31. If Haskell allows hot code loading, would this throw a wrench into the static type system? -- Regards, Casey

2010/04/03 Casey Hawthorne :

Apparently, Erlang does not have a static type system, since with hot code loading, this is intrinsically difficult.

It is doubtless hard to statically check a program that is not statically available :)

If Haskell allows hot code loading, would this throw a wrench into the static type system?

One can not "gloss over" the difference between statically verified and not; dynamic loading becomes essentially "dynamic compiling and type-checking". You ship a statically checked Haskell program that is run to construct new Haskell programs. With `hint-server', for example, you have a statically checked master process which is shipped with the GHC inside and you load subprograms into their own environment; if type checking works then, hurray, it did and you run the subprogram. If not, well, you handle the error. The master process is static while the modules governed by it are not. I wonder, is it possible in Erlang to dynamically reload the entire runtime, stem-to-stern? -- Jason Dusek

2010/4/4 Casey Hawthorne :

Apparently, Erlang does not have a static type system, since with hot code loading, this is intrinsically difficult.

Apparently, this is doable with proper engineering even for such an unsafe language as C: http://www.cs.umd.edu/projects/PL/dsu/

"Erlang Programming", Francesco Cesarini & Simon Thompson, June 2009, O'Reilly, page 31.

I think this is opinion from the time of Erlang design and initial prototypes which gets speaken repeatedly over and over again without (re)checking of facts.

If Haskell allows hot code loading, would this throw a wrench into the static type system?

The code that is loaded most often is the code of "state transformer" that operate on completely specified types of state and incoming messages. Behaviours (high level program composing "combinators" for Erlang) are pretty stable (and, as far as I can tell, are hard to reload - but I can be wrong). Again, one example of code reloading implemented for Bluetail Mail Robustifier actuall stops the system for complete code update and need special conversion code to update old state to new state invariants and back. I think that it is even easier in the presence of strong type system. And again: most of Erlang library code is annotated with type specifications for dialyzer. So I don't think that contemporary Erlang is dynamically typed. It's just static types does not used much. ;)