On Tue, Jul 14, 2015 at 4:57 AM, Keean Schupke <[email protected]> wrote: > Okay, I think this is a good point. As systems languages like BitC are not > interpreted (byte code) either there needs to a hole in the type system like > addrToHValue# in Haskell (which I have used to implement dynamic module > loading) or you need two things: > > - run time type information > - a way to associate the RTTI with a shared object that is loaded. > > All you would need to do is write a data table with the required type > information as part of the output to the shared object, and then check on > loading that the expected static types match the types in the method table > added to the shared object in a runtime loader. > > However this would require runtime support, and I think systems languages > should have no runtime (or as minimal as possible). I think the Haskell > solution is better. Include an unsafe address to value function, and allow > external 'C' functions to be called. Then you can write the type-safe > dynamic loader as a library.
But Haskell's solution is a pragmatic concession, and it generally compromises the soundness of the type system. Better to be honest and admit that native libraries _are_ extended runtime support, and programs need to trust them. Unless you use some safe FFI mechanism, though that may make non-fragile-interfaces-through-native-library impractical. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
