To clarify, I was not criticising Java, C#, Swift or other similar languages. I was trying to discuss how dynamic loading might be done in a general purpose systems language like BitC.
If I were to criticise Swift, it would be for its proprietary nature. Although it is now open source, its design is still under proprietary control. It really needs independent control of its specification, whether the implementation is open source is far less important. An openly specified modern safe dynamic language taking the best ideas from Java, C# and Swift would be great. Apple and Microsoft can compete with their proprietary implementations and make sure the dynamic loading abstraction is well implemented on their respective architectures. Keean. On 15 Jul 2015 6: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. For example the compiler can > write a table into binaries allowing lookup if methods and fields and > cryptographically sign it. When you dynamically load the shared object you > check the method type in the table with the static type you are expecting. > This is done in a library you can include with your program if you want to > do dynamic loading. > > As for fragile interfaces, you just need to confirm you are loading the > correct version of the library, again a cryptographic hash or similar can > be used for this. > > 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. > > Keean. > On 15 Jul 2015 6:25 am, "Matt Oliveri" <atma...@gmail.com> wrote: > >> 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 >> >
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
