On 22 August 2013 16:32, David Jeske <[email protected]> wrote: > 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.
Ah, yes. So you would like whatever ecosystem bitc integrates into to support the declaration of these stable, compile-time interfaces. Sounds reasonable. It's not a difficult thing to implement, but depending on the choice of platform, code written to implement that interface could feel very artificial, and a number of optimisations required for good performance on that platform may no longer work. > 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. Very true. > AFAIK, these Ocaml modules you speak of are namespaces, not separate binary > compiled shared-libraries.. Ah. Yes, this can be the case. > ---- > > 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. On GC (aside): Co-operative GC tracing is an issue in the sense of (to borrow another pypy term) the 'lop'[0] problem as applied to GC implementations. It's not hard to write a bridge from python to C or ruby to java, but writing a bridge between a stack of languages is near impossible, and all the existing attempts really fail to make this useful (Parrot, CLI, JSR-292, Guile) because they often optimise for one 'style' at the expense of the rest. It's not even entirely about describing the right interface, explicit kernel support for managed runtimes is non-existant and yet it could be one of the primary things we'd want to describe in that interface. Additionally, because we've always had C, COM, and Objective C as the lowest common denominators, this is what we've aimed at. I suspect that ignoring flexibility in things like object representation, type systems, and modular code-loading mechanisms has really hurt large-scale development, by causing the same functionality to be written several times. The engineering problems for GC integration are not significant: distributed GC is sufficiently studied that we should be able to have interfaces that enable different object spaces to communicate about liveness, especially in a single process. I really think this is a social issue. On Topic: I think that bitc's target audience is people who want to be able to write those sort of extensively shared libraries, that this is a good time to bring that up, and being able to declare a stable link-level interface is a part of that. I don't really know how much that restricts the optimum of which platform bitc should target, mostly because from a distance it seems surmountable, and partially because I'm not working on bitc. Faith and Tater will probably go for whatever is easier to swallow, which is IMO as good as any metric I can see. Details, details. [0] writing l * o * p runtimes for l languages with o combinations of integrated features (such as JIT or Coroutines) on p platforms. -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely may reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to deny you those rights would be illegal without prior contractual agreement. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
