This is basically what you get by default already with the raw proposal we've been talking about -- the Preludes in the haskell98 and haskell2010 remain unmodified by this proposal and are available for teaching use.
Sent from my iPhone On May 27, 2013, at 8:53 PM, Andrew Farmer <afar...@ittc.ku.edu> wrote: > I generally agree with Iavor's points, but if this is such an issue, why not > make Prelude more general by default and have a special 'Prelude.Basic' with > the more specific type signatures for beginners? The general Prelude would be > implicitly imported as now, unless the module imported Prelude.Basic > unqualified. Then make Hackage warn/reject packages that use Prelude.Basic. > > Tutorials/Books would have to tell readers to add a magic "import > Prelude.Basic" at the beginning of their source files, but tutorials for > other languages do this (public static void main(..)?) to relatively little > complaint. > > Sorry, I'm sure this has been proposed before... but the proposed extension > seems complicated to avoid some qualified imports/hidings. If we really want > people to use Foldable's foldr by default, then make it the default and let > beginners add a magic line once per file to get simpler types. > > Andrew > > > On Mon, May 27, 2013 at 5:07 PM, Daniel Gorín <dgo...@dc.uba.ar> wrote: >> Hi Iavor, >> >> On May 27, 2013, at 6:18 PM, Iavor Diatchki wrote: >> >> > Hello, >> > >> > >> > On Fri, May 24, 2013 at 12:42 AM, Daniel Gorín <dgo...@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 :) >> >> I understand your concern, but I don't quite see how a library could abuse >> this feature. I mean, a library could export the same symbol with different >> specialized types in various modules, but you, the user of the library, will >> see them as different symbols with conflicting name, just like now you see >> symbols Prelude.foldr and Data.Foldable.foldr exported by base... unless, of >> course, you specifically activate the extension (the one called >> MoreSpecificImports in my first mail). That is, it would be an opt-in >> feature. >> >> > 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? >> >> Do you have a particular example in mind? The more general version of every >> symbol can be used wherever the more specialized one fits, and in the >> (seemingly rare?) case where the extra polymorphism may harm you and that >> adding a type annotation is not convenient enough, you could just hide the >> import of more the general version. Do you anticipate this to be a common >> scenario? >> >> > 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 >> >> But this doesn't scale that well, IMO. In real code even restricted to the >> the base package the hiding clauses can get quite long and qualifying basic >> polymorphic functions starts to feel like polymorphism done wrong. >> >> This can very well be just a matter of taste, but apparently so many people >> have strong feelings about this issue that it is seriously being proposed to >> move Foldable and Traversable to the Prelude, removing all the monomorphic >> counterparts (that is, make Prelude export the unspecialized versions). >> While this would be certainly convenient for me, I think it would be an >> unfortunate move: removing concrete (monomorphic) functions in favor of >> abstract versions will make a language that is already hard to learn, even >> harder (but there was a long enough thread in the libraries mailing list >> about this already!). In any case this proposal is an attempt to resolve >> this tension without "penalizing" any of the sides. >> >> Thanks, >> Daniel >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
