From: Brian Rogoff <bpr@best.com>
To: Christophe Raffalli <Christophe.Raffalli@univ-savoie.fr>
Cc: caml-list@inria.fr
Subject: Re: Undefined evaluation order
Date: Mon, 16 Oct 2000 08:48:06 -0700 (PDT) [thread overview]
Message-ID: <Pine.BSF.4.21.0010160832560.25294-100000@shell5.ba.best.com> (raw)
In-Reply-To: <39EABE87.53274BB6@univ-savoie.fr>
On Mon, 16 Oct 2000, Christophe Raffalli wrote:
> It seems to me that a program making use of evaluation order in function
> or constructor application is wrong !
Why? It seems right to me, when you're reading in a file of records or
building an AST from a file, or whatever, to depend on the evaluation
order when building the data structure. I didn't get surprised, because I
know OCaml is right-to-left, but I still find all of that let binding code
redundant, especially when the records get long. There is nothing "wrong"
about it that I can see, except that some people don't like it in concept.
Interestingly, some people really did like it in concept and some of them
were teachers who've witnessed beginners stumble over this very issue.
> It seems easy to me to add some marking in the type system to detect
> expression with side effects ...
I thought about this too. Something like Clean's uniqueness types? Maybe
in OCaml 4 :)
> then one could have a warning (or even
> an error :-) when some code depends on evaluation order and then, in
> this case only, force left to right evaluation order.
What does this mean? That you would have the programmer manually insert
lets to force the order, or that the compiler does so automatically?
> I am sure I would find some bugs in my programs with such a warning :-)
I think the random evaluation order that someone proposed as a test/debugging
tool might be easier than a modification of the type system.
-- Brian
next prev parent reply other threads:[~2000-10-16 17:47 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-10-11 12:22 Greg Morrisett
2000-10-11 20:35 ` Pierre Weis
2000-10-13 7:05 ` Judicael Courant
2000-10-13 14:21 ` Markus Mottl
2000-10-16 8:38 ` Christophe Raffalli
2000-10-16 15:48 ` Brian Rogoff [this message]
2000-10-16 16:29 ` Christophe Raffalli
2000-10-17 9:19 ` Ralf Treinen
2000-10-12 8:35 ` Undefined evaluation order: define it for constructors ? Jacques Garrigue
2000-10-12 13:26 ` Hugo Herbelin
-- strict thread matches above, loose matches on Subject: below --
2000-10-20 14:59 Undefined evaluation order Gerard Huet
2000-10-14 1:42 David McClain
2000-10-13 13:56 Dave Berry
2000-10-12 17:06 David McClain
2000-10-12 11:32 Greg Morrisett
2000-10-12 9:53 Dave Berry
2000-10-10 19:23 David McClain
2000-10-10 18:55 John R Harrison
2000-10-10 12:46 Greg Morrisett
2000-10-05 18:14 Brian Rogoff
2000-10-06 2:02 ` Ken Wakita
2000-10-06 11:18 ` Pierpaolo BERNARDI
2000-10-07 6:46 ` Ken Wakita
2000-10-08 15:43 ` David Mentré
2000-10-08 22:47 ` Brian Rogoff
2000-10-10 12:47 ` Thorsten Ohl
2000-10-10 20:52 ` Brian Rogoff
2000-10-10 19:26 ` Stefan Monnier
2000-10-09 12:45 ` Xavier Leroy
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=Pine.BSF.4.21.0010160832560.25294-100000@shell5.ba.best.com \
--to=bpr@best.com \
--cc=Christophe.Raffalli@univ-savoie.fr \
--cc=caml-list@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