From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA19300; Thu, 22 Jul 2004 17:39:08 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA19742 for ; Thu, 22 Jul 2004 17:39:07 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i6MFd1SH008265; Thu, 22 Jul 2004 17:39:01 +0200 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA19891; Thu, 22 Jul 2004 17:39:01 +0200 (MET DST) Date: Thu, 22 Jul 2004 17:39:01 +0200 From: Pierre Weis To: Jon Harrop Cc: caml-list@inria.fr Subject: Re: [Caml-list] kprintf with user formatters Message-ID: <20040722173901.A18239@pauillac.inria.fr> References: <200407211552.RAA04351@pauillac.inria.fr> <200407212141.45191.postmaster@jdh30.plus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200407212141.45191.postmaster@jdh30.plus.com>; from postmaster@jdh30.plus.com on Wed, Jul 21, 2004 at 09:41:45PM +0100 X-Miltered: at concorde with ID 40FFDF95.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; pierre:01 weis:01 pierre:01 weis:01 caml-list:01 kprintf:01 formatters:01 expr:01 expr:01 match'':01 -ary:01 lazyness:01 realised:01 lazily:01 thunks:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk [...] > Is "match pred with true -> expr1 | false -> expr2" not > equivalent to "if pred then expr1 else expr2"? If so, isn't pattern > matching a fourth lazy construct? Yes indeed, if you consider ``match'' as an operator, which is a bit hairy, since match would be a (2n+1)-ary operator (for any given positive integer n), taking as input 1 expression (the one to be matched) and n (pattern, expression) pairs to match the expression. Given that there is no notion of evaluation semantics associated to a pattern (in the sense of the evaluation of expression) this would be strange. However, the very match expression you mentioned has indeed something of a lazyness behavior, since it is indeed equivalent of an ``if ... then ... else ...'' construct, as I know you know :) > Just after I wrote that last post I realised that this approach > could actually be useful in numerical contexts. As a trivial > example, integer multiply could lazily evaluate its second argument > (only when it is pure, if conventional semantics are to be > preserved), not needing it if the first argument is zero. I don't think the gain would overcome the cost of having to create thunks in practice. On the other hand, taht would lead to evaluate the operation 0 * expr to 0, even if the computation of expr would lead to divergence (never terminates or fails). It's mathematically kind of weird, I think. For instance, you would have a hard time to persuade a matematician that 0 * ln (0) is well-defined and evaluates to 0, ``because ln (0) has not to be considered at all given the left operand''. Hence, as far as I know, arithmetics operators are always considered strict in lazy languages. > This may be useful in more complicated settings, i.e. when dealing > with data structures rather than primitive types and when predicates > over the data structure can be evaluated much more quickly than the > corresponding expression. I'm a bit lost here. Could you explain a bit ? > Such functionality can, of course, be implemented in vanilla > OCaml. But I'd like to see a language which allowed mathematics to > be expressed in a notation as close to conventional written form as > possible (although I prefer type distinctions, like "+" vs "+.") > whilst retaining efficiency (I'd also like to see deforesting, > e.g. in vector expressions without having to resort to maps, folds > etc.). Yes, we all want such a language. Caml is the best approximation I know, wrt a perfect match between efficiency and notational facility. > Perhaps an OCaml -> OCaml optimising compiler would be a good > project for someone? That way implementation details and their > benefits can be examined without having to touch the OCaml > compilers. I think it could be quite fun to play with such a > thing... > > Cheers, > Jon. Yes, many people have dreamed upon (or even have planned to do) such a tool in the past. These days, the availability of the camlp4 tools would help a lot to perform such a goal... Best regards, Pierre Weis INRIA, Projet Cristal, http://pauillac.inria.fr/~weis ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners