[Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guards loops]
Richard A. O'Keefe
ok at cs.otago.ac.nz
Tue Jul 16 04:49:27 CEST 2013
On 15/07/2013, at 8:23 PM, J. Stutterheim wrote:
> The OS dependency for dynamics stems from the fact that the Clean dynamics are quite a bit more powerful than Haskell's. For example, using dynamics, it is possible to send arbitrary functions to another Clean application, which can then dynamically link these functions in at runtime and immediately execute them. It doesn't even need to be the same program, which Cloud Haskell does require (and theoretically, it can even be another OS). This advanced dynamic linking feature requires intimate knowledge of the target OS' binary representation.
There is no obvious reason why it should.
Imagine a programming language implementation where a function
is compiled to some abstract representation (like Kistler's Juice)
and a native representation is added on loading or on first use.
For Oberon, Kistler found that transmitting compressed abstract
syntax trees and generating native code on reception took less
time and yielded better code than sending native code. Even when
reading from a local disc, loading compressed ASTs and generating
native code on the fly was faster than a conventional dynamic linker.
A major issue here, of course, is that "Windows" could be 32-bit or
64-bit, x86 or ARM, and even if you restrict attention to one of
these combinations, there are things like exactly what SIMD
instructions are available.
> (I would actually really like to see Haskell's dynamics system to become as powerful as Clean's; it also supports polymorphism, for example)
Perhaps you could say something about the following problem:
I have a data structure that includes some functions.
These functions use version X of module M.
I send that data structure to another application,
which is using version Y of module M, where Y /= X.
What happens? This is the primary reason why Erlang has not
imitated Kali Scheme, which could also send functions.
For that matter, what happens if the function is sent to another
application (on a remote machine) that doesn't have _any_
version of module M and doesn't know where to find one?
I am _not_ suggesting that these are problems that Clean could not solve
or has not solved. On the contrary, I'm saying that it would be very
interesting to hear how Clean has solved them.
From a security point of view, of course, failing to practice Safe Hex
is a bit worrying, but proof-carrying code and signatures can go some
way towards addressing that concern.
More information about the Haskell-Cafe