|
Message-ID: <20130423213346.GC12689@port70.net> Date: Tue, 23 Apr 2013 23:33:46 +0200 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: Best place to discuss other lightweight libraries? * Daniel Cegie?ka <daniel.cegielka@...il.com> [2013-04-23 21:24:57 +0200]: > 2013/4/23 Strake <strake888@...il.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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.