On Wed, Jul 15, 2015 at 1:39 AM, Keean Schupke <ke...@fry-it.com> wrote: > I want a language that is as safe as possible and can be self hosting, hence > you can write the compiler, runtime and operating system in it. > > Just because you include unsafe conversion does not make all programs > unsafe. You can use unsafe conversion safely.
Yes, but the language is of no help in determining whether a use is safe. Back to the topic of fragile interfaces, if every program that uses non-fragile interfaces needs to depend on a library using unsafe conversion, then either: - The library should be considered part of the language implementation. - The language is unsafe. or - The language doesn't support non-fragile interfaces. Note that saying a language is unsafe doesn't mean that every program written in it is unsafe, of course. It just means it doesn't make claims about the safety of programs written in it. So if non-fragile interfaces are a requirement, then a language that will not attest the safety of programs using non-fragile interfaces should be considered unsafe. > ... > This is done in a library you can include with your program if you want to > do dynamic loading. Right, see above. > To assume there are no bugs in a program written in a unsafe language, and > then to claim the language written in this is safe seems strange. It just > means you will never see the backdoors, remember the concept of the > backdoored compiler that inserts a backdoor into every program it compiles. > A false sense of security is worse than a realistic appraisal. Much better > to make the bsckdoor (unsafe conversion) visible, as it has to be there in > any case. A mature language runtime is not any old piece of machine code. It's carefully made, and well-tested. I am under no delusion that putting something in the language implementation makes it automatically safe. But putting the things that need to be trusted into the language implementation discourages an ever-growing TCB. You need to trust the language implementation in any case, so you might as well put as much of what you need to trust as you feasibly can in with the language. The alternative, of letting any and every library add unsafe code to the system, is the thing that's harder to trust. But really, neither the big trusted language implementation nor explicit unsafe operations are very good, which is why it probably is worth it in the long run to use type/proof systems strong enough to prove the safety of language runtimes. _______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
