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 38DB57EEBF for ; Tue, 18 Aug 2015 21:01:18 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of kennethadammiller@gmail.com) identity=pra; client-ip=209.85.218.41; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of kennethadammiller@gmail.com designates 209.85.218.41 as permitted sender) identity=mailfrom; client-ip=209.85.218.41; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@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-oi0-f41.google.com) identity=helo; client-ip=209.85.218.41; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="postmaster@mail-oi0-f41.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BpAgBKgNNVmynaVdFdhFgGgx6vGZNHAoEwB0wBAQEBAQESAQEBAQEGCwsJIS6EIwEBAQMBEhEdARsdAQMBCwYFBAcNKgICIgERAQUBHAYTCBqHdgEDCgiuSYEvPjGLQIFsgnmLFAoZJw1XhQABAQEBAQEEAQEBAQEBFgEFDotFhQoHgmmBQwWVIYxsmGMSI4EXF4QoIjOCTAEBAQ X-IPAS-Result: A0BpAgBKgNNVmynaVdFdhFgGgx6vGZNHAoEwB0wBAQEBAQESAQEBAQEGCwsJIS6EIwEBAQMBEhEdARsdAQMBCwYFBAcNKgICIgERAQUBHAYTCBqHdgEDCgiuSYEvPjGLQIFsgnmLFAoZJw1XhQABAQEBAQEEAQEBAQEBFgEFDotFhQoHgmmBQwWVIYxsmGMSI4EXF4QoIjOCTAEBAQ X-IronPort-AV: E=Sophos;i="5.15,703,1432591200"; d="scan'208";a="143087758" Received: from mail-oi0-f41.google.com ([209.85.218.41]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 18 Aug 2015 21:01:17 +0200 Received: by oiev193 with SMTP id v193so105824801oie.3 for ; Tue, 18 Aug 2015 12:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DjCQVklAYOrBVZGhTtNawjjd7uu2ze2Yo2TAba0YX8E=; b=t0y4N1P1FjMGDgeGS5aKSJPOWfvl+cbplovg9p2875fGm0GVVxZx84DEQf4uA4vg4O S6s7t3mR64pO007Kl3FpeH5yyPUONcolCMvHEyjCtTlVIdG0tIwq1b3gSAaNtjdKbIFk ElpSTsRuFDJCn9hQdBrt7ZYrN3KbbDtVeemXp+SwcgszA98QskgcwGSFjkFw4/+oyymU A2tcNifXSr44PXLXJxOWFCjf6Wf2udarMotuigWBU5TIGzmuH4BlEWr3x5RIaJkRR+2A 9SC3qiEFZs0jWxSBdBa6GYQ+o/20C2ksvxIEk9+/sVA3hXPZYtgZ+We9+Mh8U4JUxhl7 CN0w== MIME-Version: 1.0 X-Received: by 10.202.206.135 with SMTP id e129mr7062379oig.132.1439924475786; Tue, 18 Aug 2015 12:01:15 -0700 (PDT) Received: by 10.202.191.8 with HTTP; Tue, 18 Aug 2015 12:01:15 -0700 (PDT) In-Reply-To: <20150818185751.GC650@topoi.pooq.com> References: <20150818185751.GC650@topoi.pooq.com> Date: Tue, 18 Aug 2015 15:01:15 -0400 Message-ID: From: Kenneth Adam Miller To: Hendrik Boom Cc: caml users Content-Type: multipart/alternative; boundary=001a113d31bce1fadf051d9a8af8 Subject: Re: [Caml-list] Type Encoding Format Control --001a113d31bce1fadf051d9a8af8 Content-Type: text/plain; charset=UTF-8 Well, it's not restricted to pointers - In general I would think that the type annotation for Some | None would be left alone. I just used pointer as an example because pointers exclude a value, 0x0, from the valid set. In which case None is encoded as 0x0. Thanks for the bit about polymorphism in the context of what a compiler would see - clients that do not see the hypothetical additional annotation for that specific type to allow a format wouldn't have the augmented operational needs to work on such an instance correctly. Got it! On Tue, Aug 18, 2015 at 2:57 PM, Hendrik Boom wrote: > 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 > --001a113d31bce1fadf051d9a8af8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, it's not restricted to pointers - In general I w= ould think that the type annotation for Some | None would be left alone. I = just used pointer as an example because pointers exclude a value, 0x0, from= the valid set. In which case None is encoded as 0x0.=C2=A0

<= div>Thanks for the bit about polymorphism in the context of what a compiler= would see - clients that do not see the hypothetical additional annotation= for that specific type to allow a format wouldn't have the augmented o= perational needs to work on such an instance correctly. Got it!=C2=A0
=

On Tue, Aug= 18, 2015 at 2:57 PM, Hendrik Boom <hendrik@topoi.pooq.com> wrote:
On Tue, Aug 18, 2015 at 01:06:55PM -0400, Kenneth Adam Miller wr= ote:
> I was wondering if cases where format control is possible in typing
> constructs can allow things like restricting the implementation size a= fter
> compilation of a specific variant type. Say, for instance that I wante= d 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 subseq= uent
> 'a instance, down to the 'a instance, where in the values of t= he word enum
> (or tag) are not present in the possibilities of the 'a instance.<= br> >
> Maybe it sounds silly, but in really tight loops you want to squeeze f= or
> efficiency. So I was wondering if maybe the same actual code be used w= ith
> the same sanity of type checking, but some annotation provided at the = type
> declaration to allow such optimization to take place.

Let's see.=C2=A0 OCaml steals a bit to indicate whether a v= alus is a pointer
or not, right?=C2=A0 Could that bit see duual usage for the option type?=C2= =A0 So
that if it's an optional pointer type, the bit is left off, and if it&#= 39;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.=C2=A0 = The
conpiler will not know whether to test for absence or presence of the
bit.

-- hendrik

--001a113d31bce1fadf051d9a8af8--