From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <hendrik@topoi.pooq.com>
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 D7D227EEBF
	for <caml-list@sympa.inria.fr>; Tue, 18 Aug 2015 20:57:54 +0200 (CEST)
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  hendrik@topoi.pooq.com) identity=pra;
  client-ip=69.165.131.134;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="hendrik@topoi.pooq.com";
  x-sender="hendrik@topoi.pooq.com";
  x-conformance=sidf_compatible
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  hendrik@topoi.pooq.com) identity=mailfrom;
  client-ip=69.165.131.134;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="hendrik@topoi.pooq.com";
  x-sender="hendrik@topoi.pooq.com";
  x-conformance=sidf_compatible
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@april.topoi.pooq.com) identity=helo;
  client-ip=69.165.131.134;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="hendrik@topoi.pooq.com";
  x-sender="postmaster@april.topoi.pooq.com";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DTBAATf9NV/4aDpUVdhDTGKAKCBAEBAQEBAYELhCQBAQQ6PxALGAklDwUYMYhB0lUBAQEBAQUBAQEBHotThQoHgxiBFAWVIYxpA0+ZYCaEGSKCfwEBAQ
X-IPAS-Result: A0DTBAATf9NV/4aDpUVdhDTGKAKCBAEBAQEBAYELhCQBAQQ6PxALGAklDwUYMYhB0lUBAQEBAQUBAQEBHotThQoHgxiBFAWVIYxpA0+ZYCaEGSKCfwEBAQ
X-IronPort-AV: E=Sophos;i="5.15,703,1432591200"; 
   d="scan'208";a="173996478"
Received: from topoi.pooq.com (HELO april.topoi.pooq.com) ([69.165.131.134])
  by mail2-smtp-roc.national.inria.fr with ESMTP; 18 Aug 2015 20:57:53 +0200
Received: by april.topoi.pooq.com (Postfix, from userid 1001)
	id 6998F1A1214; Tue, 18 Aug 2015 14:57:51 -0400 (EDT)
Date: Tue, 18 Aug 2015 14:57:51 -0400
From: Hendrik Boom <hendrik@topoi.pooq.com>
To: Kenneth Adam Miller <kennethadammiller@gmail.com>
Cc: caml users <caml-list@inria.fr>
Message-ID: <20150818185751.GC650@topoi.pooq.com>
References: <CAK7rcp_DfDdW94HWhuPsnKE-eg3ncvLTDfk7vcg9R+toKMkZhg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAK7rcp_DfDdW94HWhuPsnKE-eg3ncvLTDfk7vcg9R+toKMkZhg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [Caml-list] Type Encoding Format Control

On Tue, Aug 18, 2015 at 01:06:55PM -0400, Kenneth Adam Miller wrote:
> I was wondering if cases where format control is possible in typing
> constructs can allow things like restricting the implementation size after
> compilation of a specific variant type. Say, for instance that I wanted to
> have a malloc implementation instead of returning a Some 'a | None type
> that compiles down to a boxed case of first a word and then the subsequent
> 'a instance, down to the 'a instance, where in the values of the word enum
> (or tag) are not present in the possibilities of the 'a instance.
> 
> Maybe it sounds silly, but in really tight loops you want to squeeze for
> efficiency. So I was wondering if maybe the same actual code be used with
> the same sanity of type checking, but some annotation provided at the type
> declaration to allow such optimization to take place.

Let's see.  OCaml steals a bit to indicate whether a valus is a pointer 
or not, right?  Could that bit see duual usage for the option type?  So 
that if it's an optional pointer type, the bit is left off, and if it's 
an optional nonpointer type, it's turned on (and set to point to 
location zero, which the GC couls check for)?

THe proble I see with this is if the 'a is passed to a generic function 
where iti isn't statically known where it's a pinter or not.  The 
conpiler will not know whether to test for absence or presence of the 
bit.

-- hendrik