From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id EE3A57EE94 for ; Fri, 28 Dec 2012 02:41:32 +0100 (CET) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of pjfrey@sympatico.ca) identity=pra; client-ip=65.55.116.35; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="pjfrey@sympatico.ca"; x-sender="pjfrey@sympatico.ca"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of pjfrey@sympatico.ca designates 65.55.116.35 as permitted sender) identity=mailfrom; client-ip=65.55.116.35; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="pjfrey@sympatico.ca"; x-sender="pjfrey@sympatico.ca"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@blu0-omc1-s24.blu0.hotmail.com) identity=helo; client-ip=65.55.116.35; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="pjfrey@sympatico.ca"; x-sender="postmaster@blu0-omc1-s24.blu0.hotmail.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwBAEH43FBBN3QjlGdsb2JhbAA7CYY6s1mCeVgWDgEBAQEJCwkJFAMkgh4BAQUjBFIQCxgCAiYCAlcGDgIeh3ikSJF3gSKLNQUNgx4yYQOIYod/iwEVjW8 X-IronPort-AV: E=Sophos;i="4.84,366,1355094000"; d="scan'208";a="187761378" Received: from blu0-omc1-s24.blu0.hotmail.com ([65.55.116.35]) by mail1-smtp-roc.national.inria.fr with ESMTP; 28 Dec 2012 02:41:32 +0100 Received: from BLU0-SMTP86 ([65.55.116.9]) by blu0-omc1-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Dec 2012 17:41:31 -0800 X-EIP: [4/DG88+/etQwtCXXGDO5vYwq4FBSdv1G] X-Originating-Email: [pjfrey@sympatico.ca] Message-ID: Received: from [192.168.2.11] ([70.27.1.137]) by BLU0-SMTP86.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Dec 2012 17:41:30 -0800 From: Peter Frey To: "Eric Jaeger (ANSSI)" CC: caml-list@inria.fr In-Reply-To: <50D59147.3000201@ssi.gouv.fr> References: <003801cddcfa$f66325c0$e3297140$@jaeger@ssi.gouv.fr> <50D59147.3000201@ssi.gouv.fr> Content-Type: text/plain; charset="UTF-8" Date: Thu, 27 Dec 2012 20:41:28 -0500 MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Dec 2012 01:41:30.0195 (UTC) FILETIME=[758F0230:01CDE49C] Subject: Re: [Caml-list] Function returning recursive lists On Sat, 2012-12-22 at 11:53 +0100, Eric Jaeger (ANSSI) wrote: > On 21/12/2012 20:55, Peter Frey wrote: > > It sometimes helps to read read the various libraries. > > For example, this thing is a variation of Batteries.BatList.Append: > > > > module Cycle = struct > > type 'a mut_list = { hd: 'a; mutable tl: 'a list } > > external inj : 'a mut_list -> 'a list = "%identity" > > external jni : 'a list -> 'a mut_list = "%identity" > As far as I know, the use of "%identity" is a trick which is similar to > Obj, telling the compiler to do nothing. You would not be allowed to do > that with standard, typed OCaml identity. In this sense, it is not the > sort of solution I'm looking for. > > Regards, Eric For what it's worth: Obj.ml, contains the line: ... external magic : 'a -> 'b = "%identity" ... That type allows anything, including 'unifying' any two types. (The compiler does not do nothing: it assigns the argument of type 'a to be the result which is of type 'b and is perfectly willing to produce code that instantly causes a segmentation fault) inj and its inverse jni seem to have a type at least a bit more friendly since they control the usage of the individual fields. As long as you trust Ocaml lists to always have the layout above, this seems a lot saver to me than type 'a -> 'b. You wanted, in effect, something like: # let rec l = [1;2;3;l];; Error: This expression has type int list but an expression was expected of type int The type 'a list is built into the system; it is not recursive and if there was a way to force it to be so (without hacks), the type system would not be sound. You know the following, of course: # type 'a aRec = {mutable hd: 'a; mutable tl:'a aRec};; type 'a aRec = { mutable hd : 'a; mutable tl : 'a aRec; } # let rec a = {hd=1; tl=a};; val a : int aRec = {hd = 1; tl = {hd = 1; tl = {hd = 1; tl = {hd = 1; tl = The problem with docycle is not its coding style but that it produces in fact a cyclic list, which is not very useful: Almost all functions, such as List.rev are undefined. Peter