Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: "\"Márk S. Zoltán\"" <zoltan.s.mark@dravanet.hu>
To: caml-list@yquem.inria.fr
Subject: Parameter evaluation order
Date: Sat, 20 Aug 2005 00:21:55 +0200	[thread overview]
Message-ID: <43065B83.6050503@dravanet.hu> (raw)

I was recently thinking about parameter evaluation order and how come it 
is unspecified in OCaml. Maybe this was already discussed here, but I do 
not recall it and cannot find it, either. Do not get me wrong, I do not 
have an unsurmontable problem with unspecified parameter evaluation 
ordering, and in a world full of languages with similar disclaimers I 
could not even have a problem. Also, side effects in parameters is just 
ugly. So the current shape of the language is fine with me.

But I do think that currying + strictness + side-effects => 
left-to-right evaluation order.  That is because a multi-parameter 
function application should be functionally equivalent to a closure 
taking the first (== leftmost) parameter and returning a closure which 
takes the second parameter etc. while parameters should be evaluated 
before passing, as per strictness. 

Consider the following code:

==== ordertest.ml =====
let f a b c d = ()

let () =
  let ff1 = f (print_string "1") in
  let ff2 = ff1 (print_string "2") in
  let ff3 = ff2 (print_string "3") in
  ff3 (print_string "4");
  print_newline ()

let () =
  let f2 = f (print_string "1") (print_string "2")
  in f2 (print_string "3") (print_string "4") ;
  print_newline ()

let () =
  f
    (print_string "1")
    (print_string "2")
    (print_string "3")
    (print_string "4");
  print_newline ()
==============

The three let ()'s should be functionally equivalent, and yet they are not:

---------------------
$ ocaml ordertest.ml
1234
2143
4321
---------------------

ocamlopt creates a different outcome, but that is well known: the last 
line reads 1234.

Of course, if this kind of logic was applied, labels and FFI's would be 
difficult to handle. Probably even enrichment of the type system with 
'has side effect' and forbidding the use of expressions with such types 
in parameters would be simpler than that, not that I advocate either 
solution. I do not say we should have left-to-right evaluation order, 
only that it would be more logical.  Am I wrong?

    M-







             reply	other threads:[~2005-08-19 22:22 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-19 22:21 "Márk S. Zoltán" [this message]
2005-08-20  9:12 ` [Caml-list] " Alain Frisch
2005-08-26 17:53   ` "Márk S. Zoltán"
2005-08-22 16:50 ` Damien Doligez
2005-08-23  7:12   ` skaller
2005-08-23 11:29     ` Damien Doligez
2005-08-23 13:34       ` Igor Pechtchanski
2005-08-23 19:52         ` Damien Doligez
2005-08-24  1:24   ` Hao-yang Wang
2005-08-24 11:33     ` [Caml-list] " Damien Doligez
2005-08-24 14:39       ` Christophe Raffalli
2005-08-24 15:47         ` Berkeley DB Joel Reymont
2005-08-24 16:08         ` [Caml-list] Re: Parameter evaluation order brogoff
2005-08-24 20:05           ` Christophe Raffalli
2005-08-24 20:25             ` brogoff
2005-08-24 20:53               ` Jon Harrop
     [not found]               ` <430CE193.9000805@univ-savoie.fr>
2005-08-26  9:53                 ` Christophe Raffalli
2005-08-26 10:10                   ` Jon Harrop
2005-08-26 12:09                     ` Christophe Raffalli
2005-08-26 12:26                       ` Diego Olivier Fernandez Pons
2005-08-26 16:48                         ` Christophe Raffalli
2005-08-27 15:33                           ` Christophe TROESTLER
2005-08-26 12:36                       ` Ville-Pertti Keinonen
2005-08-26 14:17                         ` Fernando Alegre
2005-08-26 17:00                         ` Christophe Raffalli
2005-08-26 22:58                       ` skaller

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=43065B83.6050503@dravanet.hu \
    --to=zoltan.s.mark@dravanet.hu \
    --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