Polymorphism in the Prelude

Daniel Gorín dgorin at dc.uba.ar
Tue Jun 24 19:08:12 UTC 2014

On Tue, Jun 24, 2014 at 3:42 AM, Mateusz Kowalczyk <fuuzetsu at fuuzetsu.co.uk> wrote:
> Do you have anything specific in mind here? At first I was just going to
> dismiss this as wishful thinking but perhaps we could actually do
> something about this.
> Maybe we could provide ‘alternative’ signatures which would make types
> more specific with some (which? all of known ones?) instances.

One thing that might help is to list the specific type of methods below instance declarations, in a collapsible view to avoid cluttering. An example rendering (in "expanded view")  would be:

> [-] instance Functor ((->) r) where
>      fmap :: (a -> b) -> (r -> a) -> (r -> b) 

Non-methods, could be handled with documentation pragmas, so the library maintainer could pick which functions to document with specialized types. One could, for example, define Data.Either as:

> module Data.Either (  … ,  (+++) )
> where
> import Control.Arrow ( (+++) ) 
>> {#- SPECIALIZE DOC (+++) :: (a -> a') -> (b -> b') -> Either a b -> Either a’ b’ #-}
which would be rendered by haddock as, say:

> (+++) :: (a -> a’) -> (b -> b’) -> Either a b -> Either a’ b’
>   Specialized signature of [Control.Arrow.(+++)]

with a suitable link. I’d prefer the module system being able to export more specific instances of functions, but this could be a decent compromise.

On 24 Jun 2014, at 18:20, Bryan O'Sullivan <bos at serpentine.com> wrote:
> You can already see how that works out with Scala documentation, which is an incomprehensible mess.

I’m not familiar with Scala documentation, do you think something like this would get messy?

More information about the Libraries mailing list