From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3166 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Best place to discuss other lightweight libraries? Date: Tue, 23 Apr 2013 23:33:46 +0200 Message-ID: <20130423213346.GC12689@port70.net> References: <5175D52D.3050107@gentoo.org> <1366683267.18069.155@driftwood> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1366752836 31063 80.91.229.3 (23 Apr 2013 21:33:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Apr 2013 21:33:56 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3170-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 23 23:34:00 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UUkqd-0000wm-JQ for gllmg-musl@plane.gmane.org; Tue, 23 Apr 2013 23:33:59 +0200 Original-Received: (qmail 21763 invoked by uid 550); 23 Apr 2013 21:33:58 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 21755 invoked from network); 23 Apr 2013 21:33:58 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3166 Archived-At: * Daniel Cegie?ka [2013-04-23 21:24:57 +0200]: > 2013/4/23 Strake : > > 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