On 22 August 2013 14:00, David Jeske <[email protected]> wrote:
> On Wed, Aug 21, 2013 at 6:40 PM, William ML Leslie
> <[email protected]> wrote:
>>
>> I really can't figure out what you're trying to say here, can you
>> elaborate on the problem?
>
>
> I'm talking about systems runtimes and libraries for end-user operating
> systems.
>
> Userland backward-compatible shared-libraries are heavily used, both because
> userland is often the fastest place for shared functionality to live, and
> also because binary module updates can fix system library bugs and isolate
> applications from systems issues.

The mechanism to provide this in C is twofold: firstly, there is
sufficient specification in header files to describe a stable ABI, and
there is small enough reliance on cross-module inlining (and it is
obvious enough when it occurs) that clients won't rely on features of
the library that are not specified within its object code.  That is:
the only things that matter are the object code and the declared
interface.  Is there anything about this that I'm missing?

> Examples of such userland shared system
> core code includes:
>
> Windows C (win32, GDI, Winforms, COM, ATL), CLR (Windows.Forms, WPF)
> Win8/WP CX (WinRT), CLR (WinRT)
> MacOS C (posix/bsd, carbon) Objective-C (Cocoa/Appkit)
> Android C (NDK) Dalvik (java sdk)
>
> C++, Ocaml, Haskell, D, Google Go, and others are not missing from this list
> because nobody has gotten around to building a system based on them, but
> because they are whole-program embedded systems compilers.

...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, not really sure
about Ocaml (because module interfaces is one thing ML got right IMO),
and I don't know anything about Go.

> My point was that contrary to comments made that JVM and CLR have not made
> headway in this type of systems programming, I'm pointing out that they are
> the some of the *only* runtimes that have made headway. 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; 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.

-- 
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

Reply via email to