caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jon Harrop <jon@ffconsultancy.com>
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	[thread overview]
Message-ID: <200710200010.53630.jon@ffconsultancy.com> (raw)
In-Reply-To: <4234F84D-BEC4-4850-B051-D38E8EA38918@mpi-sws.mpg.de>

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


  parent reply	other threads:[~2007-10-19 23:19 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-18  9:52 Tom
2007-10-18 10:33 ` [Caml-list] " skaller
2007-10-18 11:01   ` Andreas Rossberg
2007-10-18 12:25 ` Jon Harrop
2007-10-18 12:40   ` Arnaud Spiwack
2007-10-18 13:17     ` Jon Harrop
2007-10-18 15:15       ` Till Varoquaux
2007-10-18 12:46   ` Jacques Garrigue
2007-10-18 13:57     ` Jon Harrop
2007-10-18 14:22       ` Brian Hurt
2007-10-18 14:52         ` Robert Fischer
2007-10-18 15:04           ` Eric Cooper
2007-10-18 17:18         ` Jon Harrop
2007-10-19  1:16           ` skaller
2007-10-19  5:09           ` Bárður Árantsson
2007-10-19  5:23             ` [Caml-list] " Erik de Castro Lopo
2007-10-19  5:46               ` Bárður Árantsson
2007-10-19 12:25               ` [Caml-list] " Christophe Raffalli
2007-10-19 12:47                 ` Luc Maranget
2007-10-20 14:26                   ` Christophe Raffalli
2007-10-19 14:48                 ` Robert Fischer
2007-10-19 21:43                   ` Andreas Rossberg
2007-10-19 21:51                     ` Robert Fischer
2007-10-20 13:10                       ` Andreas Rossberg
2007-10-19 23:10                     ` Jon Harrop [this message]
2007-10-20  1:13                       ` skaller
2007-10-20  6:36                         ` Tom
2007-10-21 11:17                           ` skaller
2007-10-19  8:55             ` Zheng Li
2007-10-19 22:27             ` [Caml-list] " Jon Harrop
2007-10-19 13:00           ` [Caml-list] " Brian Hurt
2007-10-19 13:49             ` Loup Vaillant
2007-10-19 14:41               ` Zheng Li
2007-10-19 23:09             ` [Caml-list] " Jon Harrop
2007-10-18 20:07   ` Tom
2007-10-19  0:59     ` skaller
2007-10-18 20:48 ` Lauri Alanko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200710200010.53630.jon@ffconsultancy.com \
    --to=jon@ffconsultancy.com \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).