On Wed, Aug 21, 2013 at 10:15 PM, William ML Leslie < [email protected]> wrote:
> ...the only things that matter are the object code and the declared > interface. Is there anything about this that I'm missing? > I'd flip that around and say that what matters is that for the type of interface you would like to express and an interesting set of library changes, a new binary object can be supplied for which applications compiled against the old binary can run-time link and run against the new binary. C's ABI compatibility model is only sufficient for the kinds of simple things expressed in C APIs. More complex system libraries and interfaces have since moved past the binary-compatibility capabilities of C-style ABIs. Some of those capabilities include Generics, Interface programming, parametric instantiation, and automatic memory management. > ...because, C++ has no encapsulation, D has a trait mechanism relying > on uncompiled code at import time iirc, Haskell relies heavily on > inlining across module boundaries and tree shaking, Exactly. > not really sure about Ocaml (because module interfaces is one thing ML got > right IMO), and I don't know anything about Go. > AFAIK, these Ocaml modules you speak of are namespaces, not separate binary compiled shared-libraries.. It might be possible for Go to admit modular compilation some-day, though they will have to draw some tough lines between structural compatibility and inference (row-polymorphism?) in their modular boundary definitions. > > From the list above, > > you can see it's basically C, Objective-C, CLR, and Dalvik/JVM -- with > > Microsoft's recent CX compiler the latest entry. > > Except when they don't really work that way - for example, you can't > write (windows) shell extensions in "managed" code, because different > extensions may rely on different CLRs; Actually, .NET 4.0 now allows side-by-side CLR runtimes of different versions in the same process. In theory this means you *can* write shell extensions in managed code and end up loading multiple CLRs into the same process without colliding. However, they still recommend you don't because the CLR is a heavy runtime and you don't want even one bogging down explorer, let alone several of them. I'd like to think this could be improved over time. http://blogs.msdn.com/b/oldnewthing/archive/2013/02/22/10396079.aspx and you can't run all your Java services in the same app server because > some of them depend on a different version of the j.l.String class. > JVM is a big mess, and this is why I specifically listed Dalvik instead. The JVM is too heavy to run extra copies (no precompiled shared libraries at all), yet naming is so weak everything clashes. It doesn't even need to be as fundamental as j.l.String. String collision of app-included modules will suffer the same death. Dalvik tries to do better, by preloading the system library, then forking to create a sort of "copy-on-write" form of shared core code. At least this prevents trivial clashes of application included modules, since they each live in their own separate Dalvik process. Android could also have multiple Dalvik "system cores" ready for different system library versions. There is no in-process extension model in Android, so that shell-extension problem is sidestepped for now. ---- Pulling away from these details, the fact remains that there is no successful model for having two different GC tracing systems coordinate to determine reachable resources. This forces us to express all boundaries out of the GC systems in terms of non-tracing memory management contracts. In practice this isn't a huge problem, as end-user operating systems seem content to choose a single dominant object-interface runtime. However, it does force other runtimes into a second-class-citizen situation. As an interesting case, Mono/Xamarin has done some exceptional work allowing Mono/CLR to interface pleasantly with Mac Objective-C. However, there are still memory-safety issues because some of the memory-management contracts in Cocoa/AppKit are simply manual. I'm curious, what conclusions do you draw from this? My conclusion is that we should continue to evolve one or two very capable cross-language runtimes, like CLR, because things are easier if we only have one managed runtime in the mix.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
