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.0 required=5.0 tests=AWL 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 3CB71BC69 for ; Sat, 20 Oct 2007 01:19:22 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAM/XGEfUnw7Wnmdsb2JhbACCOIwcAQEBAQcEBik X-IronPort-AV: E=Sophos;i="4.21,302,1188770400"; d="scan'208";a="3370982" Received: from ptb-relay03.plus.net ([212.159.14.214]) by mail1-smtp-roc.national.inria.fr with ESMTP; 20 Oct 2007 01:19:21 +0200 Received: from [80.229.56.224] (helo=beast.local) by ptb-relay03.plus.net with esmtp (Exim) id 1Ij17h-0004tk-7n for caml-list@yquem.inria.fr; Sat, 20 Oct 2007 00:19:21 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: Help me find this pdf Date: Sat, 20 Oct 2007 00:10:53 +0100 User-Agent: KMail/1.9.7 References: <4718C3AA.9050503@fischerventure.com> <4234F84D-BEC4-4850-B051-D38E8EA38918@mpi-sws.mpg.de> In-Reply-To: <4234F84D-BEC4-4850-B051-D38E8EA38918@mpi-sws.mpg.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710200010.53630.jon@ffconsultancy.com> X-Spam: no; 0.00; rossberg:01 iirc:01 semantics:01 deallocated:01 semantics:01 ocaml:01 haskell:01 semantically:01 haskell:01 unspecified:01 semantically:01 iirc:01 ocamlc:01 ocamlopt:01 compiler:01 On Friday 19 October 2007 22:43:42 Andreas Rossberg wrote: > Wow, that made my FUD sensors go wild. This whole thread made my FUD sensors go wild. :-) > 1. Purity and evaluation regime are separate issues. You can very > well have a pure language that is eager. IIRC, you then need the option of laziness to be able to implement all programs with the same asymptotic complexity as impure/eager or pure/lazy. > 2. However, in a pure language the details of evaluation order are > largely immaterial to its semantics, which obviously is an advantage. I'm not sure that unknown evaluation order is an "obvious" advantage in general. For example, when evaluating "f && g" where f is O(1) and g is O(n!) you might want to know that "f" gets evaluated first. > 3. Lazy evaluation by itself is as precise an evaluation scheme as > eager evaluation. There is no inherent vagueness. Does a thunk preventing a large data structure from being deallocated count as "inherent vagueness"? > 4. In fact, the semantics of OCaml arguably is more vague than that > of Haskell, because evaluation order is underspecified (and can vary > between compilers) even where it matters semantically. Haskell only > leaves it unspecified where it is not semantically observable. IIRC, ocamlc and ocamlopt really do evaluate in different orders sometimes. > 5. The problem with Haskell and laziness on the other hand is not > semantic bugs, but the fact that it can make space complexity hard to > predict sometimes. And time performance hard or impossible to achieve. > 6. Nevertheless, evaluation is fully deterministic, thus it certainly > cannot cause Heisenbugs, neither semantically nor performance-wise. Perhaps I've missed something but surely evaluation order can alter asymptotic complexity? If so, moving from one compiler to another can change the asymptotic complexity of your program? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e