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
next prev 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).