From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id BC5D47EE4B for ; Fri, 27 Sep 2013 17:25:30 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of yotambarnoy@gmail.com) identity=pra; client-ip=209.85.128.53; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of yotambarnoy@gmail.com designates 209.85.128.53 as permitted sender) identity=mailfrom; client-ip=209.85.128.53; receiver=mail3-smtp-sop.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 (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-qe0-f53.google.com) identity=helo; client-ip=209.85.128.53; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-qe0-f53.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoEAH6iRVLRVYA1m2dsb2JhbABahBGNUAOyeIEUCBYOAQEBAQEGCwsJFCiCJQEBBAFAARseAwELBgkHOyIBEQEFARIKBogGAQMJBpwRjFKDCoNASgoZJw1kiQABBQyPTIQgA5d/kA4YKYRpIA X-IPAS-Result: AmoEAH6iRVLRVYA1m2dsb2JhbABahBGNUAOyeIEUCBYOAQEBAQEGCwsJFCiCJQEBBAFAARseAwELBgkHOyIBEQEFARIKBogGAQMJBpwRjFKDCoNASgoZJw1kiQABBQyPTIQgA5d/kA4YKYRpIA X-IronPort-AV: E=Sophos;i="4.90,994,1371074400"; d="scan'208";a="28340102" Received: from mail-qe0-f53.google.com ([209.85.128.53]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 27 Sep 2013 17:25:29 +0200 Received: by mail-qe0-f53.google.com with SMTP id jy17so1876822qeb.40 for ; Fri, 27 Sep 2013 08:25:28 -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 :content-type; bh=olNTztScPZrM/b4gBARh3Ujn38rUcxczcma+AGvIel4=; b=vOArBqr2yLqlxDC8MlzuoMz0li7zaJ5C+78nobTQvKfcOh7NARzQQAd/uK8oOK6J5n lI3gP1K1+jkJVrCBpWqNKM7VH99RimjgQkGg5u68jIYUXkEhWTZQHjZ3Z9nXaM/EGkxw ufnGUXyRT7KsoLZWhvWjEA4y25laupqN4PgTpchF/2vkW8Dn5FqtIL/mwUSUT9xsX5+T FCB1SUeq2iA8vHYhYoI/pJyjHAkp4RDxmGlVoWMTmsd7rAVj0omoh/zSif6smtCJdYeB 3wJwFsggZ+voq/NgTzPZuxbV7Iask2VDROTIEJuTLIJjrEvUhX3UHuBWHEqV/LqtyR6Q LB+A== X-Received: by 10.49.131.132 with SMTP id om4mr9845902qeb.2.1380295528435; Fri, 27 Sep 2013 08:25:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.139.20 with HTTP; Fri, 27 Sep 2013 08:25:08 -0700 (PDT) In-Reply-To: References: From: Yotam Barnoy Date: Fri, 27 Sep 2013 11:25:08 -0400 Message-ID: To: Ocaml Mailing List Content-Type: multipart/alternative; boundary=047d7beb9a46a907a704e75f18ee Subject: [Caml-list] Fwd: Proposal: re-design of ocaml headers --047d7beb9a46a907a704e75f18ee Content-Type: text/plain; charset=ISO-8859-1 > > Can you please share your experience of writing bindings to some C > libraries for ? How it compares to writing > bindings for OCaml? (this is a thread about runtime values > representation, I suppose.) > > This isn't really relevant to this topic, since this discussion is just about ocaml headers, rather than the ocaml C FFI. The FFI would remain largely the same. > Why will anyone ever need more than 200 constructors of a sum type? > (also note the presence of polymorphic variant types.) > I thought so too, but as mentioned in the previous discussion thread (entitled 'Expanding the Float Array Tag'), code generators can easily run out of 200 constructors. However, it's possible that 65,000 constructors is really excessive, in which case some bits can be shifted around. I'd be happy to get some feedback on this. > > random access to this data is never needed > > mkay... :[ > This is only talking about automatic ocaml functions, which work without any type information. Proper ocaml code is typed, so it doesn't need this information. But internal mechanisms such as the GC, marshal module, and polymorphic comparison are 'dumb' in the sense that they're missing all of the crucial type information. For these functions, there needs to be some basic type information within the data structure itself. Currently, floats are stored in their own independent data structure with a 'double_tag' header, or otherwise they're in a 'double_array'. Having some information in the header about internal floats and pointers is much more efficient, but it doesn't need to have random access -- the internal ocaml functions that use this information process the entire data structure at once. Yotam --047d7beb9a46a907a704e75f18ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


=A0 Can you please share your experience of writing bindings to some C
libraries for <your preferable language>? =A0How it compares to =A0wr= iting
bindings for OCaml? =A0(this is a thread about runtime values
representation, I suppose.)


This isn't really relevant t= o this topic, since this discussion is just about ocaml headers, rather tha= n the ocaml C FFI. The FFI would remain largely the same.

=A0
=A0 Why will anyone ever need more than 200 constructors of a sum type?
(also note the presence of polymorphic variant types.)

I thought so too, but as mentioned in the previous di= scussion thread (entitled 'Expanding the Float Array Tag'), code ge= nerators can easily run out of 200 constructors. However, it's possible= that 65,000 constructors is really excessive, in which case some bits can = be shifted around. I'd be happy to get some feedback on this.
=A0
> r= andom access to this data is never needed

=A0 mkay... =A0:[

This is o= nly talking about automatic ocaml functions, which work without any type in= formation. Proper ocaml code is typed, so it doesn't need this informat= ion. But internal mechanisms such as the GC, marshal module, and polymorphi= c comparison are 'dumb' in the sense that they're missing all o= f the crucial type information. For these functions, there needs to be some= basic type information within the data structure itself. Currently, floats= are stored in their own independent data structure with a 'double_tag&= #39; header, or otherwise they're in a 'double_array'. Having s= ome information in the header about internal floats and pointers is much mo= re efficient, but it doesn't need to have random access -- the internal= ocaml functions that use this information process the entire data structur= e at once.

Yotam
=A0


--047d7beb9a46a907a704e75f18ee--