[core libraries] Re: Tightening up on inferred type signatures

[Edward Kmett]

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 <ekmett at 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 <ganesh at earth.li>wrote:
>
>> On 23/04/2014 20:04, dm-list-haskell-libraries at scs.stanford.edu wrote:
>> > Edward Kmett <ekmett at 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140430/b5b40d16/attachment.html>