[bitc-dev] Extent of type class instances (MPJ look)

[David Hopwood]

Mark P. Jones wrote:
> [...] Are you perhaps thinking
> of a system that would allow something like the following pair of modules?
> 
>    module N where
>      class C a where c :: a -> a
> 
>      twice  :: C a => a -> a
>      twice x = c (c x)
> 
>      twiceFalse = twice False
> 
>    module M where
>      import N
> 
>      instance C Bool where c = not
> 
>      main = print twiceFalse
> 
> Note here that the definition of twiceFalse in module N seems to require
> an instance of C for Bool, but there is no such instance in N.
> 
> Technically, it is still possible to type check the code in N; the principal
> type of twiceFalse is: C Bool => Bool -> Bool.
> 
> A Haskell compiler, however, would reject the definition of N.  I believe
> this choice was made as a pragmatic compromise between the desire to be as
> flexible as possible and the desire to allow early detection of errors.
> In other words, the designers thought that code like this was most likely
> to be a programmer error (forgetting to define or import an instance of C
> for Bool in N).  While it would be possible to assign the C Bool => ...
> type to twiceFalse, that could prevent the (presumed) error from being
> detected until the top of the call graph (intermediate points on the call
> graph would also inherit the extra C Bool constraint).

On the general point of more flexible language semantics producing less
understandable errors:

If a program fails to compile in the full language, perhaps it could be
compiled again as if it were written in a more restricted language (which
will also fail, but possibly for a different reason). Then, the errors from
the second compilation can be presented as additional warnings.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>