From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 7FD35BC88 for ; Sat, 5 Feb 2005 02:49:24 +0100 (CET) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j151nM2B011201 for ; Sat, 5 Feb 2005 02:49:23 +0100 Received: from [192.168.1.200] (ppp212-197.lns2.syd3.internode.on.net [203.122.212.197]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id j151nFKd082086; Sat, 5 Feb 2005 12:19:16 +1030 (CST) Subject: Re: [Caml-list] Estimating the size of the ocaml community From: skaller Reply-To: skaller@users.sourceforge.net To: Oliver Bandel Cc: caml-list@yquem.inria.fr In-Reply-To: <20050204160023.GE498@first.in-berlin.de> References: <891bd33905020213315a2ebb18@mail.gmail.com> <009a01c50a1e$f6c92080$0100a8c0@mshome.net> <200502040233.40444.jon@jdh30.plus.com> <20050204094129.GB15155@furbychan.cocan.org> <20050204160023.GE498@first.in-berlin.de> Content-Type: text/plain Organization: Message-Id: <1107568154.14589.449.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 05 Feb 2005 12:49:14 +1100 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 42042622.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 sourceforge:01 oliver:01 bandel:01 wrote:01 ocaml:01 lazy:01 syntax:01 syntax:01 compiler:01 semantics:01 glebe:01 061:98 nsw:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: On Sat, 2005-02-05 at 03:00, Oliver Bandel wrote: > Explanation: Pattern matches are like nested if's now in OCaml. The Pattern > that matches first in the code, will be executed!!! > This is NOT functional, this is imperative behaviour! No. If chains are perfectly functional .. in fact control transfer is little more than lazy evaluation. What you are *actually* complaining about is loss of transparency. When you write if A then .. else if B then .. the *actual* guard on the second case isn't B, but B and not A therefore the order of writing matters. So you cannot transparently reorder the branches. What you're *actually* asking for is probably a match construction that guarrantees the branches are mutually exclusive so that the order of writing is irrelevant. In particular, there is a related construction that executes *all* matching cases, and the mutually exclusive branches match is a special case of that which only takes one branch. In particular, a parallel match, which executes all the branches, possibly concurrently, would work well when the branches are exclusive.. (since no concurrency is required .. :) In fact, Ocaml 'match' syntax is chosen to do 20 quite distinct operations with one syntax: i.e. it is just a convenience. The compiler tries to unravel it to produce better code -- but the programmer does not actually know how well it will perform without heavy analysis. More discrete constructions would give the programmer much more idea of the actual semantics and implementation, BUT it would then be much harder -- less transparent -- to modify the code. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net