Wrong order of evaluation in application of curried function

[nrnrnr]

Moscow ML seems to be applying functions the Caml way, rather than what is called for in the Definition of Standard ML. The manual says to report this deviation as a bug. For me, it's a show-stopping bug.

Example source code:

structure S = struct
  fun shout_then_apply f = (print "Shouting.\n"; f)
  fun id x = x
  val _ = shout_then_apply id (print "Evaluating second argument.\n")
end

The standard says that the first print should be called when shout_then_apply is applied to id, which is before the second print is evaluated. But that's not what mosml does:

For comparison, here's output from MLton:

nr@homedog ©152/g/textbook> mosmlc -toplevel -o a mosmlbug.sml
nr@homedog ©152/g/textbook> ./a
Evaluating second argument.
Shouting.
nr@homedog ©152/g/textbook> mlton -output b mosmlbug.sml
nr@homedog ©152/g/textbook> ./b
Shouting.
Evaluating second argument.
nr@homedog ©152/g/textbook> 

Standard ML of New Jersey also gets the evaluation order right.

For me, this is a show-stopping bug---is there any chance of getting it fixed?

[nrnrnr]

Followup: I found this workaround:

  val _ = let val g = shout_then_apply id in g end (print "Take two.\n")

which behaves in a way that is consistent with the standard. So the bug is no longer show-stopping; it's just a bug.

[sestoft]

On 26Jul17, 18:38, "Norman Ramsey" <[email protected]<mailto:[email protected]>> wrote: Followup: I found this workaround: val _ = let val g = shout_then_apply id in g end (print "Take two.\n") which behaves in a way that is consistent with the standard. So the bug is no longer show-stopping; it's just a bug. Indeed it's a deviation from the Standard, and the root cause of this is that mosml uses the Caml abstract machine which is most efficient when evaluating application from right to left (as you noted when raising the issue). So in fact the bug has been there since version 1.0. We (then Sergei Romanenko and I) could not find a robust solution that also had good performance (somewhat more of a concern on a 16 MHz 80386 than it is today). So we decided to leave it there, and hope that only few people would be sophisticated enough to exploit both side effects and higher-order functions in the same code. I'm pretty sure that Andreas Rossberg noted this too, but apart from that there is at most one or two others who have pointed this out in the past 23 years. Peter

[nrnrnr]

I'm sure it's rarely encountered, but in the next release of the manual you might want to point it out, rather than encourage people to report "any deviation" as a bug. And other people might like to know about the workaround...

(My real application is slightly sordid, which is to instrument the evaluation of a let expression without wrapping the expression in anything. I evaluate the function applyCheckingOverflow (fn x => x)\ expression, where

  fun applyCheckingOverflow f =
    if !recursionLimit <= 0 then
      raise RuntimeError "recursion too deep"
    else
      let val _ = recursionLimit := !recursionLimit - 1
      in  fn arg => f arg before (recursionLimit := !recursionLimit + 1)
      end

If the application happens to raise an exception, it is caught elsewhere, and the counter is reset.

P.S. @rossberg is pretty good company!

[sestoft]

On 27Jul17, 21:50, "Norman Ramsey" <[email protected]<mailto:[email protected]>> wrote: I'm sure it's rarely encountered, but in the next release of the manual you might want to point it out, rather than encourage people to report "any deviation" as a bug. And other people might like to know about the workaround... Indeed, it is stupid that we didn't include a section "Known deviations from Standard ML" or similar... Peter

[dcurrie]

This bug has been noted in mosml/doc/bugs as long as I can remember!

• e

[sestoft]

On 21Dec17, 4:36, "Doug Currie" <[email protected]<mailto:[email protected]>> wrote: This bug has been noted in mosml/doc/bugs as long as I can remember! · e Indeed -- and is unlikely to ever be fixed. Have a merry christmas, Peter