| Is the problem that Hugs gives runST a type rather than treating it as a
| language construct?
No, because
(a) Hugs 1.4 *doesn't* give runST a type ... it treats it as a language
construct.
(b) If anything, using language constructs is more troublesome. And it
is obviously less attractive to build in special language
constructs when you have the ability to build things up yourself
from existing language mechanisms.
I don't think my previous message was properly understood, so let me say
things a different way.
In previous releases of Hugs, including the original August 1996
release of Hugs 1.3, and the January 1998 release of Hugs 1.4,
runST was implemented as a special language construct, with its
own typing rules. Without an official semantics in the presence
of class constraints, one can argue that the treatment of runST
in those systems was a reasonable interpretation. It was not,
however, the most liberal interpretation. This was identified in
a posting to hugs-users by Yoshihiko Ichikawa on Thu, 29 Aug 1996.
I posted a very simple modification to Hugs 1.3 on Sun, 01 Sep 1996
that allowed Hugs to use the more liberal interpretation. But, of
course, runST was still implemented as a special language construct.
I don't know why this change was not incorporated in later versions
of Hugs; it may have been overlooked, or it may have been found to
interact badly with other parts of the system later on.
Starting with Hugs 1.3c, runST is no longer implemented as a built
in language construct, but is instead defined as a function with
type runST :: (forall s. ST s a) -> a. (The implementation of this
function is, however, still provided by a primitive, although that
could perhaps be avoided now too.) With this type for runST, we
get the more liberal interpretation once again, in which
runST (return 5) :: Num a => a
Hugs 1.4 will soon have the same type checker, and hence will offer
the same treatment of runST, without requiring a special language
construct.
All the best,
Mark
