Re: FYI: removing `fibon`

[Michal Terepeta]

Ok, thanks Gracjan!

Ben, could I ask you to pull from:
https://github.com/michalt/nofib/tree/fibon
(https://github.com/michalt/nofib.git branch `fibon`)
Or if you prefer Phab, let me know if there's some magic incantation
to make it work with this patch (`arc` currently crashes for me)

Thanks,
Michal

On Tue, Mar 14, 2017 at 9:32 PM Gracjan Polak 
wrote:

> I'm not working on it and do not plan to start again.
>
> Looks like fibon never worked and wasn't used for anything, so it should
> be removed. Still it would make sense to replace this code with something
> used as part of normal nofib test cases.
>
> 2017-03-14 19:59 GMT+01:00 Michal Terepeta :
>
> Hi all,
>
> I wanted to remove `fibon` (from `nofib`) - it's broken, abandoned
> upstream (no commits in 5 years) and I'm not aware of anyone using it
> or working on it. At this point I don't think it makes sense to try to
> revive it - I'd prefer putting the time/effort into getting a few new
> benchmarks.
>
> There were already discussions about removing it in
> https://ghc.haskell.org/trac/ghc/ticket/11501
>
> If someone is actually working on getting it to work again, please
> shout!
>
> Thanks,
> Michal
>
> PS. I've tried uploading the patch to Phab, but I think it's just too
> large (arc is crashing). So I've uploaded it to github:
> https://github.com/michalt/nofib/tree/fibon
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: DeriveFoldable treatment of tuples is surprising

[Ryan Yates]

Thanks for the clarification!

Ryan

On Wed, Mar 22, 2017 at 9:47 AM, Ryan Scott  wrote:

> I believe what Sven was saying is not that the Foldable instance for
> tuples are given "special treatment" (which is arguably an orthogonal
> discussion), but rather that -XDeriveFoldable special-cases tuples, which
> is certainly true.
>
> As Edward noted, there is one possible justification for this behavior
> w.r.t. things like newtype V3 a = V3 (a, a, a) deriving Foldable. But to be
> honest, I find this justification tenuous at best, given the confusion it
> causes when explaining how DeriveFunctor/DeriveFoldable/DeriveTraversable
> work to newcomers. Removing this special case would not only be simple, but
> it would also lead to a more consistent story overall.
>
> I would be curious to know how much code in the wild is actually taking
> advantage of a trick like newtype V3 a = V3 (a, a, a) deriving Foldable. If
> the breakage isn't terrible, then I propose we just rip off this wart.
>
> (This is basically a rehash of the thoughts I left at
> https://ghc.haskell.org/trac/ghc/ticket/13465#comment:3)
>
> Ryan S.
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: DeriveFoldable treatment of tuples is surprising

[Ryan Scott]

I believe what Sven was saying is not that the Foldable instance for tuples
are given "special treatment" (which is arguably an orthogonal discussion),
but rather that -XDeriveFoldable special-cases tuples, which is certainly
true.

As Edward noted, there is one possible justification for this behavior
w.r.t. things like newtype V3 a = V3 (a, a, a) deriving Foldable. But to be
honest, I find this justification tenuous at best, given the confusion it
causes when explaining how DeriveFunctor/DeriveFoldable/DeriveTraversable
work to newcomers. Removing this special case would not only be simple, but
it would also lead to a more consistent story overall.

I would be curious to know how much code in the wild is actually taking
advantage of a trick like newtype V3 a = V3 (a, a, a) deriving Foldable. If
the breakage isn't terrible, then I propose we just rip off this wart.

(This is basically a rehash of the thoughts I left at
https://ghc.haskell.org/trac/ghc/ticket/13465#comment:3)

Ryan S.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: DeriveFoldable treatment of tuples is surprising

[Ryan Yates]

On Wed, Mar 22, 2017 at 4:12 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).
>

I'm not sure what you mean by "pairs are given a special treatment".
Tuples are given the only possible treatment:

data (,) a b = (a,b)

The b is the only place to fold over with a Foldable or change with a
Functor instance.  When things are monomorphic there are more options and
that leads to the least surprising, fold over all the options for:

data Pair a = Pair a a

or

data X a = X (a,a)

The (a,a) here is most certainly not the same thing as (a,b).  There is
something that is a bit surprising to me in that DerivingFoldable will not
a user declared data type for pair with two arguments:

> data Pair a = Pair a a deriving (Functor, Foldable, Show)
> data X a = X (Pair a) deriving (Functor, Foldable, Show)
> length (X (Pair 1 2))
2
> data Tup a b  = Tup a b deriving (Functor, Foldable, Show)
> data Y a = Y (Tup a a) deriving (Functor, Show)

:10:34: error:
• Can't make a derived instance of ‘Functor Y’:
Constructor ‘Y’ must use the type variable only as the last
argument of a data type
• In the data declaration for ‘Y’
> data Y a = Y (Tup a a) deriving (Foldable, Show)

:11:34: error:
• Can't make a derived instance of ‘Foldable Y’:
Constructor ‘Y’ must use the type variable only as the last
argument of a data type
• In the data declaration for ‘Y’
> data Y a = Y (Tup a a) deriving (Foldable, Show)

But it is happy to do just that with (a,a).


Ryan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: SPECIALISE INLINE pragma

[Matthew Pickering]

Thanks Simon.

I made a page for it here - https://wiki.haskell.org/Inlining_and_Specialisation

Matt

On Wed, Mar 22, 2017 at 10:50 AM, Simon Peyton Jones
 wrote:
> |  On the same topic, I also wrote a blog post simply explaining the
> |  essential things to know about the inliner and specialiser as I don't
> |  think they are generally appreciated. Comments welcome!
> |
> |  http://mpickering.github.io/posts/2017-03-20-inlining-and-
> |  specialisation.html
>
> Fantastic work Matthew.
>
> Might you put in the "Collaborative documentation" section of the Haskell 
> wiki?  https://wiki.haskell.org/GHC
>
> That way others could help edit/maintain/extend it.  I have quite a few 
> suggestions, but most are easier just to execute than to send you suggested 
> deltas.
>
>
> |  The user guide says that "you can make GHC diverge by using SPECIALISE
> |  INLINE on an ordinarily-recursive function."
>
> Suppose you have
>
> f x = ...(f [x])...
>
> Now I think SPECIALISE INLINE might go on for ever, making more and more 
> specialised copies.  At least I think that's it.  Making a concrete example 
> and putting that in the manual would be great.
>
> Simon
>
> |  -Original Message-
> |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
> |  Matthew Pickering
> |  Sent: 20 March 2017 15:52
> |  To: GHC developers 
> |  Subject: SPECIALISE INLINE pragma
> |
> |  The user guide says that "you can make GHC diverge by using SPECIALISE
> |  INLINE on an ordinarily-recursive function."
> |
> |  Does anyone know the ticket or technique which causes this to happen?
> |
> |  https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgo
> |  w_exts.html#specialize-inline
> |
> |
> |
> |  Matt
> |  ___
> |  ghc-devs mailing list
> |  ghc-devs@haskell.org
> |  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: SPECIALISE INLINE pragma

[Simon Peyton Jones via ghc-devs]

|  I didn't know the bit about INLINE being ignored on a loop-breaker
|  with no warning and no way of changing the loop-breaker.

GHC tries hard NOT to choose an INLINE function as a loop breaker.  But if you 
write

f x = if ... then 0 else (f x')
{-# INLINE f #-}

then the only possible loop breaker is 'f', so GHC has to choose it. 

What else would you suggest?  What puzzling behaviour do you have in mind?

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|  Mikolaj Konarski
|  Sent: 20 March 2017 23:41
|  To: Matthew Pickering 
|  Cc: GHC developers 
|  Subject: Re: SPECIALISE INLINE pragma
|  
|  > On the same topic, I also wrote a blog post simply explaining the
|  > essential things to know about the inliner and specialiser as I
|  don't
|  > think they are generally appreciated. Comments welcome!
|  >
|  > http://mpickering.github.io/posts/2017-03-20-inlining-and-
|  specialisati
|  > on.html
|  
|  LGTM. I'd propose to link to this from GHC manual.
|  
|  I didn't know the bit about INLINE being ignored on a loop-breaker
|  with no warning and no way of changing the loop-breaker. That probably
|  explains puzzling and counter-intuitive results of some alternative
|  layouts of INLINEs in the computation-intensive parts of my code, at
|  least since the time I provide unfoldings for all functions and so
|  discounts don't help GHC in picking the intended loop-breaker.
|  And I don't think this ignoring of the programmer's intent wrt INLINE
|  is documented in the usual places.
|  ___
|  ghc-devs mailing list
|  ghc-devs@haskell.org
|  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: SPECIALISE INLINE pragma

[Simon Peyton Jones via ghc-devs]

|  On the same topic, I also wrote a blog post simply explaining the
|  essential things to know about the inliner and specialiser as I don't
|  think they are generally appreciated. Comments welcome!
|  
|  http://mpickering.github.io/posts/2017-03-20-inlining-and-
|  specialisation.html

Fantastic work Matthew.

Might you put in the "Collaborative documentation" section of the Haskell wiki? 
 https://wiki.haskell.org/GHC

That way others could help edit/maintain/extend it.  I have quite a few 
suggestions, but most are easier just to execute than to send you suggested 
deltas.


|  The user guide says that "you can make GHC diverge by using SPECIALISE
|  INLINE on an ordinarily-recursive function."

Suppose you have

f x = ...(f [x])...

Now I think SPECIALISE INLINE might go on for ever, making more and more 
specialised copies.  At least I think that's it.  Making a concrete example and 
putting that in the manual would be great.

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|  Matthew Pickering
|  Sent: 20 March 2017 15:52
|  To: GHC developers 
|  Subject: SPECIALISE INLINE pragma
|  
|  The user guide says that "you can make GHC diverge by using SPECIALISE
|  INLINE on an ordinarily-recursive function."
|  
|  Does anyone know the ticket or technique which causes this to happen?
|  
|  https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgo
|  w_exts.html#specialize-inline
|  
|  
|  
|  Matt
|  ___
|  ghc-devs mailing list
|  ghc-devs@haskell.org
|  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs