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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id BEBA37EEF6 for ; Wed, 3 Jun 2015 18:52:47 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of romain.bardou@inria.fr) identity=pra; client-ip=87.98.172.249; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="romain.bardou@inria.fr"; x-sender="romain.bardou@inria.fr"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of romain.bardou@inria.fr) identity=mailfrom; client-ip=87.98.172.249; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="romain.bardou@inria.fr"; x-sender="romain.bardou@inria.fr"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@8.mo3.mail-out.ovh.net) identity=helo; client-ip=87.98.172.249; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="romain.bardou@inria.fr"; x-sender="postmaster@8.mo3.mail-out.ovh.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A7AwBKMG9Vm/msYldbh2DAQYJTAoFBPBABAQEBAQEBEQEBAQEBBgsLCSEuQQWDXQEBBCMVQBELGAICBRYLAgIJAwIBAgFFEwgCiC0Bt22jawEBAQcCIIEhiH+BI4UNFoJSgUUBBJ4zl0SEHoM0AQEB X-IPAS-Result: A0A7AwBKMG9Vm/msYldbh2DAQYJTAoFBPBABAQEBAQEBEQEBAQEBBgsLCSEuQQWDXQEBBCMVQBELGAICBRYLAgIJAwIBAgFFEwgCiC0Bt22jawEBAQcCIIEhiH+BI4UNFoJSgUUBBJ4zl0SEHoM0AQEB X-IronPort-AV: E=Sophos;i="5.13,547,1427752800"; d="scan'208";a="162526235" Received: from 8.mo3.mail-out.ovh.net ([87.98.172.249]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 03 Jun 2015 18:52:47 +0200 Received: from mail177.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo3.mail-out.ovh.net (Postfix) with SMTP id B4AE5FFA8BD for ; Wed, 3 Jun 2015 18:52:46 +0200 (CEST) Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 3 Jun 2015 18:52:46 +0200 Received: from amontsouris-652-1-27-201.w83-202.abo.wanadoo.fr (HELO ?192.168.1.15?) (romain@bardou.fr@83.202.178.201) by ns0.ovh.net with SMTP; 3 Jun 2015 18:52:43 +0200 Message-ID: <556F30D9.9010109@inria.fr> Date: Wed, 03 Jun 2015 18:52:41 +0200 From: Romain Bardou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: caml-list@inria.fr References: <20150602100015.E87D67EEF7@sympa.inria.fr> <556E2CE1.9040801@bioquant.uni-heidelberg.de> In-Reply-To: <556E2CE1.9040801@bioquant.uni-heidelberg.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 3520407535495383584 X-Ovh-Remote: 83.202.178.201 (amontsouris-652-1-27-201.w83-202.abo.wanadoo.fr) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekuddrgeekucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekuddrgeekucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-Validation-by: romain@bardou.fr Subject: Re: [Caml-list] pattern matching on mapped lists On 03/06/2015 00:23, Nils Becker wrote: > I find this syntax handy > > let [ii; jj] = List.map float_of_int [i; j] in > ... do stuff with the floats > > because it avoids repeating the function call. The compiler lets this > pass but warns that the matching is not exhaustive since [] is not > matched. This actually can't happen if I'm not mistaken. So, is this > considered good style, or is there a better idiomatic way to do multiple > assignments? If yes, should this be an enhancement request for the type > checker? > > n. The type-checker cannot find out that List.map returns a list of the same size. I think it would require dependent types. Maybe some GADT can encode this, but it would be a bit messy. If you use this idiom often, maybe you should define some map functions on tuples, whose length is known at compile-time: let map2 f (x, y) = f x, f y let (ii, jj) = map2 float_of_int (i, j) in ... Unfortunately you need to define map2, map3, map4... Cheers, -- Romain