From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 0CB53BC69 for ; Fri, 19 Oct 2007 03:21:07 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAKSjF0fLENaMnmdsb2JhbACOTgIBAQcEBhEY X-IronPort-AV: E=Sophos;i="4.21,297,1188770400"; d="scan'208";a="3322041" Received: from ipmail01.adl2.internode.on.net ([203.16.214.140]) by mail1-smtp-roc.national.inria.fr with ESMTP; 19 Oct 2007 03:21:05 +0200 X-IronPort-AV: E=Sophos;i="4.21,297,1188743400"; d="scan'208";a="213843218" Received: from ppp121-44-36-108.lns10.syd7.internode.on.net (HELO [192.168.1.201]) ([121.44.36.108]) by ipmail01.adl2.internode.on.net with ESMTP; 19 Oct 2007 10:46:44 +0930 Subject: Re: [Caml-list] Help me find this pdf From: skaller To: Jon Harrop Cc: caml-list@yquem.inria.fr In-Reply-To: <200710181818.31430.jon@ffconsultancy.com> References: <200710181457.58077.jon@ffconsultancy.com> <47176C28.1090509@janestcapital.com> <200710181818.31430.jon@ffconsultancy.com> Content-Type: text/plain Date: Fri, 19 Oct 2007 11:16:40 +1000 Message-Id: <1192756600.13520.49.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; 0100,:01 ocaml:01 recursion:01 bindings:01 caching:01 combinators:01 buys:98 sourceforge:01 wrote:01 caml-list:01 lazy:02 lazy:02 arbitrary:02 expression:02 expression:02 On Thu, 2007-10-18 at 18:18 +0100, Jon Harrop wrote: > Because you can't pattern match over lazy values, this solution is about as > beautiful as my first girlfriend. Hopefully both GF and wife class as 'eager' not 'lazy' .. :) > This is no freakishly theoretical problem either, it crops up whenever I want > to destructure a collection as a sequence. You can use an unfold but that > only buys you 1 element look ahead whereas the power of pattern matching > stems from its ability to dispatch based upon destructuring to arbitrary > depths. That's not quite right. Pattern matching in Ocaml has bound look ahead. Although the bound depends on the actual patterns, there is always a bound on the depth for any given match. The branch expression is evaluated lazily, so you can use recursion to unfold with bound lookahead. Actually it isn't necessary to cache the lookahead values, and indeed Felix does not: any bindings in the branch expression are actually re-evaluated, independently of the matching. Caching forced values isn't mandatory, and not necessarily efficient. > If it were possible to pattern match over lazy values, you would simply write > a to_lazylist function in the module of each container and pattern match over > its result to dissect any container with minimal copying. What it seems to come down to is the same as in Felix: it isn't enough to have lazy application: the alternation and product combinators have to be lazy too, in both their introduction and elimination parts. Hmm .. is this right? -- John Skaller Felix, successor to C++: http://felix.sf.net