From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q0KDTJcw006271 for ; Fri, 20 Jan 2012 14:29:19 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgECAP9qGU/RVaC2kGdsb2JhbABDgw2Bd6h0CCIBAQEBCQkNBxQEIYFyAQEBAwESAg8VCAEbHAIDAQsGBQsNAgIFFgsCAgkDAgECARERAQUBHBMIAQEeh1oIm2AKiyJIgm+Edz+IcQIBBAuBJIdbggaBFgSIPIxdhVWBN4cEPYQc X-IronPort-AV: E=Sophos;i="4.71,542,1320620400"; d="scan'208";a="140735069" Received: from mail-gy0-f182.google.com ([209.85.160.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 20 Jan 2012 14:29:14 +0100 Received: by mail-gy0-f182.google.com with SMTP id 10so290505ghy.27 for ; Fri, 20 Jan 2012 05:29:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=/mTgHeCsI/EVYMCyOYptbw73fKQ964cY2UNZ7k3MssU=; b=NW66ppqguRnaeFcqoDNNeMAXhVE4IoBoBG7yKLap5z8jizqinmj71QTfkbxKL12+0p bVP7gKNdrHL2nZK7KYn3NFN7q6nDScdJzbsDJD4MTJ6DEw7xzebVLrDlHpJymEIE39hc W9Wz8qeH9xwtCukEQ6lzqr2gUJaQDzVDY+dXU= Received: by 10.236.189.105 with SMTP id b69mr13509211yhn.90.1327066153133; Fri, 20 Jan 2012 05:29:13 -0800 (PST) Received: from [192.168.1.65] (99-121-78-10.lightspeed.lnngmi.sbcglobal.net. [99.121.78.10]) by mx.google.com with ESMTPS id 9sm8068522ans.15.2012.01.20.05.29.11 (version=SSLv3 cipher=OTHER); Fri, 20 Jan 2012 05:29:12 -0800 (PST) Message-ID: <4F196C25.7070402@gmail.com> Date: Fri, 20 Jan 2012 08:29:09 -0500 From: Edgar Friendly User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: caml-list@inria.fr References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] is there a more concise way to write this? On 01/20/2012 03:37 AM, David Allsopp wrote: > Actually, it's possible that with more cases it might be faster - > it's > eliminating the allocation (at some point) of all the tuples needed for > the match case, Doesn't the ocaml compiler not allocate the unnecessary tuples? https://ocaml.janestreet.com/?q=node/90 > it potentially eliminates a lot of linear comparisons to > find the correct match case (I don't think that the compiler would be > able to optimise that to a hash-based or index-based lookup) Isn't the compiler's compilation strategy for match cases able to build an optimized tree of comparisons in cases like this? I agree there's no easy index or hash strategy for this, but I'd expect it to turn this pattern matching into the equivalent of: if a then if b then [a;b] else [a] else if b then [b] else [] E.