match_co: needs more cases
I made some strictifying changes and started getting this msg from ghc:
match_co: needs more cases
vector-0.10.0.1:Data.Vector.Generic.Mutable.MVector{tc r46}
(Sym (vector-0.10.0.1:Data.Vector.TFCo:R:MutableVector{tc r45}))
main:Util.TimeVectorStorable.Sample{tc r4e} y{tv a4lK} [tv]
It's not just TimeVectorStorable.Sample (which is indeed stored in
Data.Vectors), we also have some mysterious compiler-generated
symbols:
match_co: needs more cases
vector-0.10.0.1:Data.Vector.Generic.Mutable.MVector{tc rQA}
(Sym (vector-0.10.0.1:Data.Vector.TFCo:R:MutableVector{tc rQz}))
a{tv a6IH} [tv]
I assume this is harmless, but I didn't see any other references to
this error on the web or on the ghc trac so maybe it's new?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: A language extension for dealing with Prelude.foldr vs Foldable.foldr and similar dilemmas
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
Re: A language extension for dealing with Prelude.foldr vs Foldable.foldr and similar dilemmas
I agree that it would be unfortunate to complicate the Prelude definitions of foldr and such by generalizing to type classes like Foldable. This proposal seems attractive to me as a way to reconcile abstraction when it's needed, and simplicity for beginners. However, it does seem like a common pattern might be to want to re-export a more generic symbol alongside a rewrite rule that substitutes a more efficient implementation for a specific type. Consider Text, ByteString, and Vector, for example. Is that doable with rewrite rules and this proposal? I'd also point out that the first of the two (-XMoreSpecificExports) would be convenient even without the other. Many people already routinely list type signatures in comments after each symbol of the export list. This would just allow the compiler to check and enforce the contracts that people are already documenting in comments. Adding optional type checking where people are already writing type signatures anyway seems like an obvious win. 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
Re: A language extension for dealing with Prelude.foldr vs Foldable.foldr and similar dilemmas
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
Re: A language extension for dealing with Prelude.foldr vs Foldable.foldr and similar dilemmas
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
