Re: [Haskell-cafe] Apparently, Erlang does not have a static type system, since with hot code loading, this is intrinsically difficult.
Jason Dusek wrote: 2010/04/03 Casey Hawthorne cas...@istar.ca: 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 :) Well, so long as you get the hot-loaded component all at once, you can do analysis on the static code before you try running it. Just because some code arrives after the program started running doesn't mean that code needs to be interpreted and have dynamic safety checks inserted. Now, if you don't get your code in nice cohesive chunks, but have it streaming in all willy nilly, then you'd need something like gradual typing or what Epigram does in order to do partial-analysis of what static code is available, even if it has holes in it. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Apparently, Erlang does not have a static type system, since with hot code loading, this is intrinsically difficult.
2010/4/4 Casey Hawthorne cas...@istar.ca: 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. ;) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Apparently, Erlang does not have a static type system, since with hot code loading, this is intrinsically difficult.
caseyh: 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? It certainly adds a phase in that you need to type check code before executing it. Which means you'll need to keep *some* types around at the splice/hot loading points. That is all. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Apparently, Erlang does not have a static type system, since with hot code loading, this is intrinsically difficult.
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Apparently, Erlang does not have a static type system, since with hot code loading, this is intrinsically difficult.
Check out Hint [1]. [1] http://hackage.haskell.org/package/hint On 4/3/10, Casey Hawthorne cas...@istar.ca wrote: 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Apparently, Erlang does not have a static type system, since with hot code loading, this is intrinsically difficult.
2010/04/03 Casey Hawthorne cas...@istar.ca: 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
