A possible bug in Hugs, first seen in the September version, but persistent
through to the just-released (November) version. "Possible" because it's
not clear that a non-terminating error message is forbidden by the
Haskell specification, although I'm guessing that it's not the behavior
intended by the implementors.
This bug was discovered by my student, Nick Eby, during work on an early
assignment in my FP class at Willamette University. In defining a slight
variant of zip called "twist", he gave the following clause (without yet
seeing the need for the others to complete the definition):
twist (x:xs) (y:ys) = (x,y) : twist ys xs
(The "twisting" aspect seems unimportant, i.e., the same problems arise
if one makes a similarly partial definition of zip.)
When this (incompletely-defined) function is applied to some short sample
lists expressed with the ellipsis notation, an error message is generated
(which is of course desirable), but the message generation itself seems
to loop:
-----------
Main> twist [1..3] [1..3]
[(1,1),(2,2),(3,3)
Program error: {twist [] (takeWhile (flip (Ord_default_compare (Make.Ord instEq_
v30 primCmpInteger (Ord_default_compare (Make.Ord instEq_v30 primCmpInteger (Ord
_default_compare (Make.Ord instEq_v30 primCmpInteger (Ord_default_compare (Make.
Ord instEq_v30 primCmpInteger (Ord_default_compare (Make.Ord instEq_v30 primCmpI
nteger (Ord_default_compare (Make.Ord instEq_v30 primCmpInteger (Ord_default_com
pare (Make.Ord instEq_v30 primCmpInteger (Ord_default_compare (Make.Ord instEq_v
30 primCmpInteger (Ord_default_compare (Make.Ord instEq_v30 primCmpInteger (Ord_
default_compare (Make.Ord instEq_v30 primCmpInteger (Ord_default_compare (Make.O
rd instEq_v30 primCmpInteger (Ord_default_compare (Make.Ord instEq_v30 primCmpIn
teger (Ord_default_compare (Make.Ord instEq_v30 primCmpInteger (Ord_default_comp
are (Make.Ord instEq_v30 primCmpInteger (Ord_default_compare (Make.Ord instEq_v3
0 primCmpInteger (Ord_default_compare (Make.Ord instEq_v30 primCmpInteger (Ord_d
efault_compare (Make.Ord instEq_v30 primCmpInteger (Ord_default_compare (Make.Or
d instEq_v30 primCmpInteger (Ord_default_compare (Make.Ord instEq_v30 primCmpInt
eger (Ord_default_compare (Make.Ord instEq_v30 primCmpInteger (Ord_default_compa
re (Make.Ord instEq_v30 primCmpInteger (Ord_default_compare (Make.Ord instEq_v30
----------
(and so on.)
The same call generates a nicely-terminating error message if we don't use the
ellipsis construction:
Main> twist [1,2,3] [1,2,3]
[(1,1),(2,2),(3,3)
Program error: {twist [] []}
More specifically, the non-terminating behavior seems tied to the use of the
ellipsis in the first argument.
I hope this information is helpful. I'd be curious to hear about how the
bug (assuming it's considered to be one) comes about (clearly takeWhile
and compare are involved, but I don't see where the looping behavior
comes in).
-- Fritz Ruehr
[EMAIL PROTECTED]
