A language extension for dealing with Prelude.foldr vs Foldable.foldr and similar dilemmas

[Iavor Diatchki]

Hello,


On Fri, May 24, 2013 at 12:42 AM, Daniel Gorín <dgorin at dc.uba.ar> wrote:

> On May 24, 2013, at 9:28 AM, Simon Peyton-Jones wrote:
>
> > How about (in Haskell98)
> >
> >       module Data.List ( foldr, ...)
> >       import qualified Data.Foldable
> >       foldr :: (a -> b -> b) -> b -> [a] -> b
> >       foldr = Data.Foldable.foldr
>
> It would not be the same! Using your example one will get that the
> following fails to compile:
>
> > import Data.List
> > import Data.Foldable
> > f = foldr
>
> The problem is that Data.List.foldr and Data.Foldable.foldr are here
> different symbols with the same name.
> This is precisely why Foldable, Traversable, Category, etc are awkward to
> use. The proposal is to make Data.List reexport Data.Foldable.foldr (with a
> more specialized type) so that the module above can be accepted.
>
>
I think that it is perfectly reasonable for this to fail to compile---to
me, this sort of implicit shadowing based on what extensions are turned on
would be very confusing.  It may seem obvious with a well-known example,
such as `foldr`, but I can easily imagine getting a headache trying to
figure out a new library that makes uses the proposed feature in anger :)

Also, using module-level language extensions does not seem like the right
tool for this task: what if I wanted to use the most general version of one
symbol, but the most specific version of another?  One needs a more fine
grained tool, and I think that current module system already provides
enough features to do so (e.g., explicit export lists, `hiding` clauses`,
and qualified imports).  For example, it really does not seem that
inconvenient (and, in fact, I find it helpful!) to write the following:

    import Data.List hiding (foldr)
    import Data.Foldable

Last, but not least, in my experience being explicit about the dependencies
of a module (i.e., using implicit import lists and qualified imports) tends
to lead to (i) more robust code because it reduces accidental breakage due
to new versions of libraries, and (ii) more readable code, because it makes
it easier to follow the code dependencies, which is especially important
when studying a new large code base.

-Iavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20130527/4d300576/attachment.htm>