On Wed, Jul 15, 2015 at 12:24 AM, Keean Schupke <ke...@fry-it.com> wrote: > 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.
I agree with the stuff above, but I don't see how it argues against what I said. The fact is that if you want non-fragile interfaces, you need the language to somehow support non-fragile interfaces, even if that means you need more runtime support. You are only pointing out that the requirements of a systems programming language and the requirements of a modular application programming language are somewhat at odds. (Also, I don't see why runtime support for non-fragile interfaces would have anything to do with the implementation of (1 + 2).) > Further I would like to write any dynamic > loading code in my language. That's pretty hard, I think, if you want any sort of safety property for your 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. No, not if I'm understanding you. Whether the language directly supports unsafe pointer conversion, or supports calling native code, it's an unsafe escape hatch. Any program using an unsafe escape hatch may be unsafe. Programs that stick to the safe part of the language are safe, assuming the language implementation is correct. The only real choice is whether non-fragile interfaces are supported by the safe part of the language. It seems like a bad idea to allow fragile interfaces in a safe language, because then linking a wrong version makes your program not so safe after all. (I am assuming breaking fragile interfaces is unsafe. This isn't necessarily true of all languages, but seems true for the languages we're thinking of.) I'm starting to think that you're not aiming for a safe language, and this is causing a miscommunication. If the language is not meant to be safe, then I can see that your approach might be better. _______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
