From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: thelema314@gmail.com
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Strange performances
Date: Sat, 19 Jan 2008 11:32:43 +0900 (JST) [thread overview]
Message-ID: <20080119.113243.267873825.garrigue@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <4790D9FC.5090108@gmail.com>
From: Edgar Friendly <thelema314@gmail.com>
> Jacques Garrigue wrote:
> >
> > This is why I sent an erratum. The cause for the segfault was not the
> > array access, but the stack overflow, which occured due to ocaml's
> > peculiar evaluation order.
>
> Is there any case where ocaml's "peculiar evaluation order" results in
> any benefit other than slightly simpler code at the compiler level? I
> understand that people shouldn't depend on evaluation order, but it
> seems that people fall into this trap often. And even extremely
> experienced camlers (if you permit this characterization of you) forget
> this behavior.
Actually, the bytecode optimization is related to the evaluation order
of functions, not data structures. So it would be perfectly possible
to create blocks from left to right, without losing this optimization.
I thought about it once, since most errors seem actually related with
data construction rather than function calls. Such an order would even
generate slightly more compact code for modules (which clearly have
to be evaluated from left to right.)
The downside of such an approach would be different evaluation orders
for data constructors and functions. There is no theoretical problem
in it, since they form different syntactic classes in ocaml, but
people may not be completely aware of that.
Another unrelated problem seldom noted is that for records, the
evaluation order is that of the record definition, not that used when
creating it. And the same thing is true for labelled functions.
So you cannot expect the evaluation order to be exactly the one
appearing in the code.
Cheers,
Jacques
next prev parent reply other threads:[~2008-01-19 2:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-18 1:32 Benjamin Canou
2008-01-18 2:15 ` [Caml-list] " Jacques Garrigue
2008-01-18 2:28 ` Jacques Garrigue
2008-01-18 7:39 ` Till Varoquaux
2008-01-18 9:12 ` Jacques Garrigue
2008-01-18 16:55 ` Benjamin Canou
2008-01-18 17:05 ` Olivier Andrieu
2008-01-18 17:11 ` Jon Harrop
2008-01-18 17:43 ` Jon Harrop
2008-01-18 19:53 ` Benjamin Canou
2008-01-18 16:55 ` Edgar Friendly
2008-01-18 17:52 ` Kuba Ober
2008-01-18 17:56 ` Jon Harrop
2008-01-19 2:32 ` Jacques Garrigue [this message]
2008-01-24 22:52 ` Christophe Raffalli
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=20080119.113243.267873825.garrigue@math.nagoya-u.ac.jp \
--to=garrigue@math.nagoya-u.ac.jp \
--cc=caml-list@yquem.inria.fr \
--cc=thelema314@gmail.com \
/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