From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q0KDoMHg007072 for ; Fri, 20 Jan 2012 14:50:23 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQCAGZwGU/RVdK2kWdsb2JhbABDrXkIIgEBAQEJCQ0HEieBcgEBAQQSAiwBOAEDDAEFBQsDCi4hARIBBQEcBhMioycKjlmEdokwAgULjBsElRmLAYMPPYFPgjA X-IronPort-AV: E=Sophos;i="4.71,542,1320620400"; d="scan'208";a="128236121" Received: from mail-iy0-f182.google.com ([209.85.210.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 20 Jan 2012 14:50:22 +0100 Received: by iagz16 with SMTP id z16so1498569iag.27 for ; Fri, 20 Jan 2012 05:50:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AroHSzDY1DJDKMqB5zSciCBl7mf8TyO2TYbZxNNA5x0=; b=Q5dK2TrRS3pZYFKRLv6eF/4riQoqdhs8iFnHaWl/TqjmgEbXWV1P2viu/R9gTIXW4H MKmcvcx7J1PUIxrky0IIoXvWVNhkAx+ObyhloE0UNo0TTwqo1n/i5r7SC+ndUNzOZ9Ez UKfmWFXGlJsXMlYdRnGWDWm2ARJB8RItbQVl8= MIME-Version: 1.0 Received: by 10.42.152.65 with SMTP id h1mr18453709icw.50.1327067421327; Fri, 20 Jan 2012 05:50:21 -0800 (PST) Sender: fabrissimo@gmail.com Received: by 10.42.155.1 with HTTP; Fri, 20 Jan 2012 05:50:21 -0800 (PST) In-Reply-To: <4F196C25.7070402@gmail.com> References: <4F196C25.7070402@gmail.com> Date: Fri, 20 Jan 2012 14:50:21 +0100 X-Google-Sender-Auth: 44TPhg20xO00xO1c2QJl_OhWv3w Message-ID: From: Fabrice Le Fessant To: Edgar Friendly Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q0KDoMHg007072 Subject: Re: [Caml-list] is there a more concise way to write this? On Fri, Jan 20, 2012 at 2:29 PM, Edgar Friendly wrote: >> 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 [] Indeed, the four line pattern-matching is turned into two consecutive tests. In many cases, the pattern-matching compiler only generates the optimal number of tests, so never be scared of creating big complex patterns... Regards, Fabrice