From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 2F77F7EE4B for ; Fri, 27 Sep 2013 20:42:24 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of yotambarnoy@gmail.com) identity=pra; client-ip=209.85.128.46; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of yotambarnoy@gmail.com designates 209.85.128.46 as permitted sender) identity=mailfrom; client-ip=209.85.128.46; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-qe0-f46.google.com) identity=helo; client-ip=209.85.128.46; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-qe0-f46.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEDAETRRVLRVYAulGdsb2JhbABbhBHATIEZCBYOAQEBAQcLCwkSKoIlAQEEAUABGx0BAwELBgUEAQYDOCEBAREBBQEcBhMbh1gBAwkGm1aMUoMKhBMKGScNZIkAAQUMjFqCaweEIAOWFoFpjESDShgphGkg X-IPAS-Result: AiEDAETRRVLRVYAulGdsb2JhbABbhBHATIEZCBYOAQEBAQcLCwkSKoIlAQEEAUABGx0BAwELBgUEAQYDOCEBAREBBQEcBhMbh1gBAwkGm1aMUoMKhBMKGScNZIkAAQUMjFqCaweEIAOWFoFpjESDShgphGkg X-IronPort-AV: E=Sophos;i="4.90,994,1371074400"; d="scan'208";a="34668108" Received: from mail-qe0-f46.google.com ([209.85.128.46]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 27 Sep 2013 20:42:18 +0200 Received: by mail-qe0-f46.google.com with SMTP id x7so2096419qeu.5 for ; Fri, 27 Sep 2013 11:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Lo+NsCEOXUND7O1BTo9KoRaAvkdgzVBHLdQST1pnA4Q=; b=D5jNLi14QRwhz+d6XawylJiwj43xRynPcbWj3usc6/U5F8C5CWddaGKESIznep9LZV DE/QjhIA5pm9H2HJxI5lWIHWzYT6wo/MIMvK/RQeL48NfN55Jah4W3m1IX8fkZ5s7MYK Zl1ChEtaPN+26ywgxaYTxi1H+S+EP/2gOw+A2m6upnxycmQbwdJjBffu5Wy5A0onV08C 4jOLLnfFJZ2zGbLNeuZI+EbQPjZmvkJ/fXOInAjYDswnRVT6nwqLsAXKC5+P6aa9mi1x UamJX9ZVbA/g+Xa0o8P6h11EOEM+RNPmSzctDMttnV512txK8zcVvRBT5NJkNNAtQ1YP GdfQ== X-Received: by 10.229.244.8 with SMTP id lo8mr11041309qcb.20.1380307338301; Fri, 27 Sep 2013 11:42:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.139.20 with HTTP; Fri, 27 Sep 2013 11:41:58 -0700 (PDT) In-Reply-To: References: From: Yotam Barnoy Date: Fri, 27 Sep 2013 14:41:58 -0400 Message-ID: To: Paolo Donadeo Cc: OCaml mailing list Content-Type: multipart/alternative; boundary=001a11c2be1e9498fb04e761d855 Subject: Re: [Caml-list] Fwd: Proposal: re-design of ocaml headers --001a11c2be1e9498fb04e761d855 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 27, 2013 at 2:15 PM, Paolo Donadeo wrote: > Many bindings deal with memory allocation. The binding of Lua deeply > interacts with the garbage collector and inspects the actual type > (tag) of OCaml value passed. > > In principle you are right but the reality is that there is no much > "abstraction" in C :-) > > It's true that coming from the C side, abstraction is a problem. However, the kind of bindings you're describing (Lua) essentially inhibit any improvement to the GC (such as parallelization, which is bound to happen some day) or to the runtime. It seems like it would be much better if bindings from C (Lua, for example) called more general functions or bindings present in the runtime's C code aka an API. Given that it seems like some bindings currently don't use an API but inspect values closely, I don't see any solution other than adapting the things that require changes. Hopefully the majority of C bindings (at least from the ocaml side) can be moved to ctypes, and can therefore be made more generic. -Yotam --001a11c2be1e9498fb04e761d855 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Fri, Sep 27, 2013 at 2:15 PM, Paolo Donadeo <p.donadeo@gmail.com&= gt; wrote:
Many bindings deal with memory allocation. T= he binding of Lua deeply
interacts with the garbage collector and inspects the actual type
(tag) of OCaml value passed.

In principle you are right but the reality is that there is no much
"abstraction" in C :-)

It's true that coming from the C side, abstraction is a problem= . However, the kind of bindings you're describing (Lua) essentially inh= ibit any improvement to the GC (such as parallelization, which is bound to = happen some day) or to the runtime. It seems like it would be much better i= f bindings from C (Lua, for example) called more general functions or bindi= ngs present in the runtime's C code aka an API. Given that it seems lik= e some bindings currently don't use an API but inspect values closely, = I don't see any solution other than adapting the things that require ch= anges. Hopefully the majority of C bindings (at least from the ocaml side) = can be moved to ctypes, and can therefore be made more generic.

-Yotam
=A0

--001a11c2be1e9498fb04e761d855--