Re: WARNING in hptSomeThingsBelowUs

[Ben Franksen]

I can provide a test case (the darcs darcs repo) where I have just seen
this for the second time.

Am 23.03.2017 um 00:43 schrieb Evan Laforge:
> I've been seeing this since 6.12.  I brought it up 7 (!) years ago,
> but unfortunately it doesn't look like I filed a bug as Simon
> requested.  I probably failed to reproduce easily, and then forgot.
> But it still definitely happens.
> 
> On Wed, Mar 22, 2017 at 3:59 PM, Ben Franksen  wrote:
>> This is what I get after removing a file from the working tree and also
>> from the cabal file for the project and then rebuild.
>>
>> WARNING in hptSomeThingsBelowUs
>>   missing module Darcs.Util.Environment
>>   Probable cause: out-of-date interface files
>>
>> I am using cabal new-build. Cabal folks tell me this is a ghc problem. I
>> am using ghc-7.10.3.


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: DeriveFoldable treatment of tuples is surprising

[Oliver Charles]

> there is a fair bit of user code for things like vector types that do
things like

newtype V3 a = V3 (a,a,a,a)
 ^ 1 2 3 4(!?)

Oh boy, I sure hope not ;)

On Wed, Mar 22, 2017 at 8:14 AM Sven Panne  wrote:

> 2017-03-21 22:29 GMT+01:00 Edward Kmett :
>
> [... In general I think the current behavior is the least surprising as it
> "walks all the a's it can" and is the only definition compatible with
> further extension with Traversable. [...]
>
>
> OTOH, the current behavior contradicts my intuition that wrapping a type
> into data/newtype plus using the deriving machinery is basically a no-op
> (modulo bottoms etc.). When I e.g. wrap a type t, I would be very surprised
> if the Eq/Ord instances of the wrapped type would behave differently than
> the one on t. I know that this is very handwavy argument, but I think the
> current behavior is *very* surprising.
>
> Somehow the current behavior seems to be incompatible with the FTP, where
> pairs are given a special treatment (if that't the right/intuitive choice
> is a completely different topic, though).
>
> Given the fact that "deriving Foldable" is quite old and therefore hard to
> change, I would at least suggest a big, fat warning in the documentation,
> including various examples where intuition and implementation do not
> necessarily meet.
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: DeriveFoldable treatment of tuples is surprising

[Sven Panne]

2017-03-21 22:29 GMT+01:00 Edward Kmett :

> [... In general I think the current behavior is the least surprising as it
> "walks all the a's it can" and is the only definition compatible with
> further extension with Traversable. [...]
>

OTOH, the current behavior contradicts my intuition that wrapping a type
into data/newtype plus using the deriving machinery is basically a no-op
(modulo bottoms etc.). When I e.g. wrap a type t, I would be very surprised
if the Eq/Ord instances of the wrapped type would behave differently than
the one on t. I know that this is very handwavy argument, but I think the
current behavior is *very* surprising.

Somehow the current behavior seems to be incompatible with the FTP, where
pairs are given a special treatment (if that't the right/intuitive choice
is a completely different topic, though).

Given the fact that "deriving Foldable" is quite old and therefore hard to
change, I would at least suggest a big, fat warning in the documentation,
including various examples where intuition and implementation do not
necessarily meet.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users