Re: [core libraries] Re: Tightening up on inferred type signatures
On 23/04/2014 20:04, dm-list-haskell-librar...@scs.stanford.edu wrote: Edward Kmett ekm...@gmail.com writes: You can wind up in perfectly legitimate situations where the name for the type you are working with isn't in scope, but where you can write a combinator that would infer to have that type. I'd hate to lose that. It is admittedly of marginal utility at first glance, but there are some tricks that actually need it, and it can also arise if a type synonym expands to a type that isn't exported or brought into scope, so trying to push this line of reasoning too far I is possibly not too productive. Good point. In particular, it's not weird at all want to export type synonyms on their own, particularly where ghost type parameters are used to select between only a few cases. Consider something like this (inspired by postgresql-orm): Is there an abstraction being protected by only exporting the type synonym in cases like this? Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [core libraries] Re: Tightening up on inferred type signatures
Not sure. An even simpler case is something like exporting a Traversal but not exporting Data.Traversable, which appears in the expansion, etc. These sorts of things happen in code using lens. Older versions of lens didn't export all of the types needed to write out the type signature long hand without extra imports, just to avoid cluttering the namespace. -Edward On Wed, Apr 30, 2014 at 2:10 AM, Ganesh Sittampalam gan...@earth.li wrote: On 23/04/2014 20:04, dm-list-haskell-librar...@scs.stanford.edu wrote: Edward Kmett ekm...@gmail.com writes: You can wind up in perfectly legitimate situations where the name for the type you are working with isn't in scope, but where you can write a combinator that would infer to have that type. I'd hate to lose that. It is admittedly of marginal utility at first glance, but there are some tricks that actually need it, and it can also arise if a type synonym expands to a type that isn't exported or brought into scope, so trying to push this line of reasoning too far I is possibly not too productive. Good point. In particular, it's not weird at all want to export type synonyms on their own, particularly where ghost type parameters are used to select between only a few cases. Consider something like this (inspired by postgresql-orm): Is there an abstraction being protected by only exporting the type synonym in cases like this? Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [core libraries] Re: Tightening up on inferred type signatures
Er.. my mistake. Control.Applicative. That is what it is we don't re-export that is used in Traversal. =) On Wed, Apr 30, 2014 at 2:47 AM, Edward Kmett ekm...@gmail.com wrote: Not sure. An even simpler case is something like exporting a Traversal but not exporting Data.Traversable, which appears in the expansion, etc. These sorts of things happen in code using lens. Older versions of lens didn't export all of the types needed to write out the type signature long hand without extra imports, just to avoid cluttering the namespace. -Edward On Wed, Apr 30, 2014 at 2:10 AM, Ganesh Sittampalam gan...@earth.liwrote: On 23/04/2014 20:04, dm-list-haskell-librar...@scs.stanford.edu wrote: Edward Kmett ekm...@gmail.com writes: You can wind up in perfectly legitimate situations where the name for the type you are working with isn't in scope, but where you can write a combinator that would infer to have that type. I'd hate to lose that. It is admittedly of marginal utility at first glance, but there are some tricks that actually need it, and it can also arise if a type synonym expands to a type that isn't exported or brought into scope, so trying to push this line of reasoning too far I is possibly not too productive. Good point. In particular, it's not weird at all want to export type synonyms on their own, particularly where ghost type parameters are used to select between only a few cases. Consider something like this (inspired by postgresql-orm): Is there an abstraction being protected by only exporting the type synonym in cases like this? Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [core libraries] Re: Tightening up on inferred type signatures
You can wind up in perfectly legitimate situations where the name for the type you are working with isn't in scope, but where you can write a combinator that would infer to have that type. I'd hate to lose that. It is admittedly of marginal utility at first glance, but there are some tricks that actually need it, and it can also arise if a type synonym expands to a type that isn't exported or brought into scope, so trying to push this line of reasoning too far I is possibly not too productive. Parts of lens, constraints and probably a few other packages I maintain would break as hard data points. -Edward On Tue, Apr 22, 2014 at 2:44 AM, Simon Peyton Jones simo...@microsoft.comwrote: | Independent of language extensions, what about types and classes whose | names are not in scope. Is there an implicit ... if you import all | the relevant symbols and the end of the rule? Good point. I'm honestly unsure how far to push this one! (It'd be relatively easy to check whether they were in scope and complain if not, but ...) Simon | -Original Message- | From: haskell-core-librar...@googlegroups.com [mailto:haskell-core- | librar...@googlegroups.com] On Behalf Of David Mazieres | Sent: 22 April 2014 00:41 | To: Simon Peyton Jones; Haskell Libraries (librar...@haskell.org); | core-libraries-commit...@haskell.org; GHC users | Subject: [core libraries] Re: Tightening up on inferred type signatures | | Simon Peyton Jones simo...@microsoft.com writes: | | GHC generally obeys this rule | | * If GHC infers a type f::type, then it's OK for you to add a type | signature saying exactly that. | | Independent of language extensions, what about types and classes whose | names are not in scope. Is there an implicit ... if you import all | the relevant symbols and the end of the rule? | | David | | -- | You received this message because you are subscribed to the Google | Groups haskell-core-libraries group. | To unsubscribe from this group and stop receiving emails from it, send | an email to haskell-core-libraries+unsubscr...@googlegroups.com. | For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups haskell-core-libraries group. To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [core libraries] Re: Tightening up on inferred type signatures
| Independent of language extensions, what about types and classes whose | names are not in scope. Is there an implicit ... if you import all | the relevant symbols and the end of the rule? Good point. I'm honestly unsure how far to push this one! (It'd be relatively easy to check whether they were in scope and complain if not, but ...) Simon | -Original Message- | From: haskell-core-librar...@googlegroups.com [mailto:haskell-core- | librar...@googlegroups.com] On Behalf Of David Mazieres | Sent: 22 April 2014 00:41 | To: Simon Peyton Jones; Haskell Libraries (librar...@haskell.org); | core-libraries-commit...@haskell.org; GHC users | Subject: [core libraries] Re: Tightening up on inferred type signatures | | Simon Peyton Jones simo...@microsoft.com writes: | | GHC generally obeys this rule | | * If GHC infers a type f::type, then it's OK for you to add a type | signature saying exactly that. | | Independent of language extensions, what about types and classes whose | names are not in scope. Is there an implicit ... if you import all | the relevant symbols and the end of the rule? | | David | | -- | You received this message because you are subscribed to the Google | Groups haskell-core-libraries group. | To unsubscribe from this group and stop receiving emails from it, send | an email to haskell-core-libraries+unsubscr...@googlegroups.com. | For more options, visit https://groups.google.com/d/optout. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
