[nhc-bugs] cygwin, java and cygpath (and some arithmetic)

[C.Reinke]

> > 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