...

2. I do not understand the order in which nhc-compiled code evaluates arithmetic expressions.

Haskell does not specify the order of evaluation in this case.

Hugs -> a a a a ghc -> a a a a hbc -> b b a a nhc98-> a a b b

I'm not even sure that ML specifies the order - since I believe SML/NJ would give you all "a"s and O'Caml all "b"s. Personally, I'm quite happy with the underspecification here, and in any case it is only likely to be encountered by people who like programming with exceptions.

Actually, I think this could be a minor headache for profiling resource usage accross Haskell implementations. Even without using explicit exceptions, you might get unexpected resource exhaustion exceptions (even within a single compiler, just by switching default types?). The mini-example I gave came from a long chain of experiments that started out with an application of foldl. As a simple example, try using nhc's version of the Hood browser for something like import Observe main = printO $ observe "foldl" foldl (+) 0 [1..4::Int] and compare the proceedings with the screenshots and text in Andy Gill's Haskell2000 paper for the same example. I first looked at nhc's prelude definition of foldl, then came upon the idea of using error to get an instant report on the order, and looked at a simple addition, in case nhc might do its evaluation from right to left (of course, it doesn't, at least not for the default type of Integers..). I briefly played with the idea that nhc might use commutativity, based on types, but that didn't make sense, either, and it took quite a while before I suspected that the order might depend on types, *without* any deeper reasons behind the choice.

...

Is this effect intensional?

No. It just happened that way, in nhc98 at least.

Btw, Standard ML has to specify the precise order of evaluation for everything (including records and declarations..), because of its use of side-effects. OCaml isn't SML (by design;-). I think Lisp specifies an order for parameter evaluation, Scheme explicitly specifies it as arbitrary. For all its shortcomings, I was surprised to find that Java has quite a bit of a specification (hard to read, but at least it has such a thing). It's just Haskell that is left behind (isn't it hilarious that the report talks about potential loss of sharing in two places without ever explaining how such sharing could come about in the first place? we just tend to assume so many things, but whenever I search for them in the Haskell report, they aren't there..). Regards, Claus