Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: "David McClain" <dmcclain@azstarnet.com>
To: <caml-list@inria.fr>
Subject: Re: Undefined evaluation order
Date: Tue, 10 Oct 2000 12:23:11 -0700	[thread overview]
Message-ID: <001801c032ef$88ed4ec0$210148bf@dylan> (raw)

I second this opinion overall... I cut my teeth with respect to this when
writing C back about 20 years ago. Each individual statement in a program
carries with it the (implicit) assumption of simultaneous evaluation, unless
care is taken to indicate otherwise (e.g., Lisp (LET ...) vs (LET* ...) ).
Hence depending on a particular order of evaluation is seemingly dangerous,
not to mention confusing when switching between many different languages as
I must do... (Lately, with a mix of OCaml, SmallTalk, Dylan, and Lisp I have
even been getting confused about operator precedence!).

I think it is probably wrong for too many assumptions to be made in the
design and use of a language. Lisp is stellar in this regard, simply because
only one assumption is made - first operand is a function all the rest are
args. When one must switch between languages, it is horribly confusing to
have to get back into the mindset of the crowd that fancies their particular
language as the one and only...

Just my 2c...

- DM

-----Original Message-----
From: Thorsten Ohl <ohl@hep.tu-darmstadt.de>
To: caml-list@inria.fr <caml-list@inria.fr>
Date: Tuesday, October 10, 2000 10:08 AM
Subject: Re: Undefined evaluation order


>Brian Rogoff <bpr@best.com> writes:
>
>> For OCaml it appears that the perspective adopted is that the
>> programmer must make the temporal dependencies explicit. [...] it is
>> mentioned that this usually leads to clearer programs.  I'm sure the
>> bytecode compiler argument is valid, but not the code clarity one
>
>Maybe I have ben brainwashed by too much Fortran, but depending on
>side effects in the evaluation of function arguments that change the
>result according to the evaluation order is not good style, IMHO.
>Explicit `let' bindings are clear and improve the likelihood that the
>author will still be able to understand his/her code a few year later
>significantly.
>
>I agree that leaving this important chunk of the semantics unspecified
>is not nice, but closing the door on parallelism forever would be much
>worse, IMHO.
>
>(Only half-joking) There should be an option in the compiler
>randomizing evaluation order for debugging ...
>--
>Thorsten Ohl, Physics Department, TU Darmstadt -- ohl@hep.tu-darmstadt.de
>http://heplix.ikp.physik.tu-darmstadt.de/~ohl/ [<=== PGP public key here]
>



             reply	other threads:[~2000-10-10 19:25 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-10-10 19:23 David McClain [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-10-20 14:59 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-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
2000-10-16 16:29           ` Christophe Raffalli
2000-10-17  9:19             ` Ralf Treinen
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='001801c032ef$88ed4ec0$210148bf@dylan' \
    --to=dmcclain@azstarnet.com \
    --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