I would say that the 'bug' is that Data.Array.ST does not export ST.
GHC's policy is to report error messages in the same vocabulary as the user would use. Even though you have imported Control.Monad.ST.Lazy and Data.Array.ST, you can still say "ST" unambiguously, because Control.Monad.ST.Lazy exports ST, but Data.Array.ST does not -- so there's only one ST in scope.
If you imported only Data.Array.ST you wouldn't be able to mention "ST" at all.
If Data.Array.ST exported ST, the error message would give a qualified name for the ST constructor -- qualified by one of its import modules, that is.
I'll ask Simon M if we should export a bit more from Data.Array.ST, but actually I think the compiler is behaving right. It'd be pain if every error message used fully-qualified names!
Exporting ST from Data.Array.ST looks like the wrong fix to me. It's fixing a tools problem by changing the library interface - we'd have to do it each time this issue came up. Perhaps the real source of the problem is that the lazy ST monad is called ST? Ok, so that's just blaming the library again, but the fact that two different types have the same name is bound to lead to confusion. Cheers, Simon
On Friday 09 May 2003 10:23 am, Simon Marlow wrote:
Perhaps the real source of the problem is that the lazy ST monad is called ST? Ok, so that's just blaming the library again, but the fact that two different types have the same name is bound to lead to confusion.
I think we gave them the same name so that it would be easy to switch back and forth between the lazy and strict monads. Almost the same effect can be achieved using type synonyms though it's not clear that being able to switch back and forth is as useful as we originally thought it would be. The other factor here is that when the library was designed, qualified names were a new feature and, based on experience from other languages, we thought that one of two things would happen: 1) Qualified names would be used routinely rather than being reluctantly used only to resolve ambiguity. I guess we ignored the premium that Haskell programmers place on concision. 2) Haskell programmers happily accept that an expression like "1+2" can't be understood without knowing additional contextual information (i.e., the type the expression is used at). It seemed plausible that they'd use unqualified names in the same spirit. I think this didn't happen because the 'ambiguity' intrioduced by type classes brings you additional flexibility but Haskell's module system doesn't add much extra flexibility (because we have nothing corresponding to ML-style functors). Which is a long way of saying that, in the absence of a more flexible module system, renaming the lazy st monad seems sensible. -- Alastair Reid
participants (2)
-
Alastair Reid -
Simon Marlow