You don't want to have a large runtime for a systems language. For example when writing an operating system kernel, you don't want invisible code added to the kernel that may be insecure. In general, if I write a program that does 1 + 2, I expect the binary to do exactly that, without needing to load a large runtime to do that. Further I would like to write any dynamic loading code in my language.
If there is no way to do the unsafe pointer conversion in the language then you cannot write the runtime in your language, and will have to write it in assembly, or 'C'. This potentially makes all programs in the language unsafe, rather than just those explicitly using the unsafe address conversion primitive. Keean. On 14 Jul 2015 10:34 pm, "Matt Oliveri" <[email protected]> wrote: > 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 >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
