Re: Best place to discuss other lightweight libraries?

[Szabolcs Nagy <nsz@port70.net>]

* Daniel Cegie?ka <daniel.cegielka@gmail.com> [2013-04-23 21:24:57 +0200]:
> 2013/4/23 Strake <strake888@gmail.com>:
> > So on that note, I deem Haskell would be a categorical category killer (^_^)
> 
> Haskell and musl - has anyone tried this combination? :) GHC is a
> pretty big package.

as far as i know haskell has no well defined semantics
about its interaction with the c runtime eventhough it
has an ffi that can use c libraries directly
(eg how haskell managed threads interact with c threads)

(the same is true for most high level languages that also
try to do system level things)

it would be nice to look at these issues systematically

in c it's reasonably clear what the runtime does and what
it doesnt do and how the application can interact with
the system through the c runtime

in a high level language you interact with the system
through high level abstractions (implemented by the
language runtime that almost always goes through the
c runtime) *and* through the c runtime when external
c libraries are used which interact with the system
as well

if you only go through the high level language runtime
then in theory it can shield you from ugly details of
the system (in practice it's not so: you can call
exec, fork, etc from python/php/perl.. and they dont
fully protect the abstractions of the language:
destructors are not called when you exit with
os.exec('/bin/true'))

when the high level language runtime is mixed with the
c runtime through ffi that's a problem: you need
'c level' guarantees about the implementation of the
language runtime and those are the things language
designers want to hide from you