Re: [GHC] #9741: Interpreter stack checks are not quite right

[Simon Marlow]

On 06/11/2014 09:56, Simon Peyton Jones wrote:

|   Oh, and the reason you have the debug RTS in your compiler is because
|  `-ticky` implies `-debug

Interesting.  I didn't know that.  Is that a good idea? Wouldn't it be better 
to make them independent?


See #3439, as you'll note it was your idea too :)

The alternative is worse: if they were separate, then we have to 
multiply the number of variants of the RTS we currently have by two 
(non-ticky and ticky).  We currently build 6-8 versions of the RTS 
depending on whether you have profiling on, and if ticky were a separate 
option it would double that number.  You could choose not to build some 
of the combinations, but then you might be surprised when -ticky doesn't 
work with some other option.


The other part of the rationale is that if you're using -ticky then 
you're already taking a performance hit from the counters, so adding 
more overhead, in the form of the extra checks that -debug does, doesn't 
hurt.


Cheers,
Simon



Simon

|  -Original Message-
|  From: ghc-tickets [mailto:ghc-tickets-boun...@haskell.org] On Behalf
|  Of GHC
|  Sent: 06 November 2014 08:37
|  Cc: ghc-tick...@haskell.org
|  Subject: Re: [GHC] #9741: Interpreter stack checks are not quite right
|
|  #9741: Interpreter stack checks are not quite right
|  -+
|  --
|  -+---
|Reporter:  simonpj |Owner:  simonmar
|Type:  bug |   Status:  closed
|Priority:  highest |Milestone:  7.10.1
|   Component:  Compiler|  Version:  7.8.3
|  Resolution:  fixed   | Keywords:
|Operating System:  | Architecture:
|  Unknown/Multiple
|Unknown/Multiple   |   Difficulty:  Unknown
| Type of failure:  |   Blocked By:
|None/Unknown   |  Related Tickets:
|   Test Case:  |
|Blocking:  |
|  Differential Revisions:  |
|  -+
|  --
|  -+---
|
|  Comment (by simonmar):
|
|   Oh, and the reason you have the debug RTS in your compiler is because
|  `-ticky` implies `-debug`.  Incidentally this is probably slowing down
|  your builds quite a lot, so you might want to turn it off.
|
|  --
|  Ticket URL: 
|  GHC 
|  The Glasgow Haskell Compiler
|  ___
|  ghc-tickets mailing list
|  ghc-tick...@haskell.org
|  http://www.haskell.org/mailman/listinfo/ghc-tickets
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [GHC] #9781: Make list monad operations fuse

[Kim-Ee Yeoh]

>From the patch fragment at

https://phabricator.haskell.org/D455?id=1311#inline-3123

What's the justification for expanding out the definition of mapM from
"sequence . map f" into do-notation and duplicated code?

Observe how mapM now duplicates code from sequence.

The absence of benchmarks is bad enough. What's worse is that the given
excuse boils down to "Pity the poor compiler! Let's take over its work
instead. Like, just in case, you know."

This optimization work needs to take place at a higher level, with deep
understanding of existing compiler transformations. Otherwise, it's all a
code-muddying crapshoot in the dark.

-- Kim-Ee

On Tue, Nov 11, 2014 at 2:22 PM, GHC  wrote:

> #9781: Make list monad operations fuse
> -+-
>   Reporter:  dfeuer  |Owner:  dfeuer
>   Type:  task|   Status:  patch
>   Priority:  normal  |Milestone:  7.10.1
>  Component:  Core|  Version:  7.9
>   Libraries  | Keywords:
> Resolution:  | Architecture:  Unknown/Multiple
>   Operating System:  |   Difficulty:  Unknown
>   Unknown/Multiple   |   Blocked By:
>Type of failure:  Runtime |  Related Tickets:
>   performance bug|
>  Test Case:  |
>   Blocking:  |
> Differential Revisions:  Phab:D455   |
> -+-
>
> Comment (by Herbert Valerio Riedel ):
>
>  In [changeset:"4923cea56345060faaf77e4c475eac6aa3c77506/ghc"]:
>  {{{
>  #!CommitTicketReference repository="ghc"
>  revision="4923cea56345060faaf77e4c475eac6aa3c77506"
>  Define list monad operations using comprehensions
>
>  Define list monad operations using list comprehensions. Code using monad
>  operations with lists did not fuse fully. Writing list code with `do`
>  notation or `(>>=)` and `(>>)` operations could allocate more than
>  equivalent code using list comprehensions.
>
>  Define `mapM` directly, instead of using `sequence` and `map`. This
>  leads to substantially less allocation in `cryptarithm2`.
>
>  Addresses #9781
>
>  Reviewed By: ekmett, nomeata
>
>  Differential Revision: https://phabricator.haskell.org/D455
>  }}}
>
> --
> Ticket URL: 
> GHC 
> The Glasgow Haskell Compiler
> ___
> ghc-tickets mailing list
> ghc-tick...@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-tickets
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [GHC] #9781: Make list monad operations fuse

[David Feuer]

On Nov 11, 2014 3:56 AM, "Kim-Ee Yeoh"  wrote:
>
> From the patch fragment at
>
> https://phabricator.haskell.org/D455?id=1311#inline-3123
>
> What's the justification for expanding out the definition of mapM from
"sequence . map f" into do-notation and duplicated code?
>
> Observe how mapM now duplicates code from sequence.

One good option might be to redefine sequence in terms of mapM.

> The absence of benchmarks is bad enough. What's worse is that the given
excuse boils down to "Pity the poor compiler! Let's take over its work
instead. Like, just in case, you know."

The excuse is that it actually makes a big difference for nofib. Why? I
would have to guess it relates to what inlines when. The inliner is a
finicky beast. In response to your insults, I will say that although GHC
has beautiful ideas in it, a lot of the details of the optimization passes
and how they fit together *are* a bit of a crapshoot, chosen by benchmarks
rather than theory. Theory sometimes comes up behind and explains why the
benchmarks do what they do, but you can't expect every little change to be
backed up by some deep theoretical reason.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: [commit: ghc] master: Define list monad operations using comprehensions (4923cea)

[Simon Peyton Jones]

The "Note" doesn't mention one of the main points, which is (if I understand 
rightly) to improve fusion.

Would it be wotth making this point, and giving an example in the Note?

Simon

|  -Original Message-
|  From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf
|  Of g...@git.haskell.org
|  Sent: 11 November 2014 07:23
|  To: ghc-comm...@haskell.org
|  Subject: [commit: ghc] master: Define list monad operations using
|  comprehensions (4923cea)
|  
|  Repository : ssh://g...@git.haskell.org/ghc
|  
|  On branch  : master
|  Link   :
|  http://ghc.haskell.org/trac/ghc/changeset/4923cea56345060faaf77e4c475e
|  ac6aa3c77506/ghc
|  
|  >---
|  
|  commit 4923cea56345060faaf77e4c475eac6aa3c77506
|  Author: David Feuer 
|  Date:   Tue Nov 11 07:59:34 2014 +0100
|  
|  Define list monad operations using comprehensions
|  
|  Define list monad operations using list comprehensions. Code using
|  monad
|  operations with lists did not fuse fully. Writing list code with
|  `do`
|  notation or `(>>=)` and `(>>)` operations could allocate more than
|  equivalent code using list comprehensions.
|  
|  Define `mapM` directly, instead of using `sequence` and `map`.
|  This
|  leads to substantially less allocation in `cryptarithm2`.
|  
|  Addresses #9781
|  
|  Reviewed By: ekmett, nomeata
|  
|  Differential Revision: https://phabricator.haskell.org/D455
|  
|  
|  >---
|  
|  4923cea56345060faaf77e4c475eac6aa3c77506
|   libraries/base/GHC/Base.hs | 51
|  +++---
|   1 file changed, 44 insertions(+), 7 deletions(-)
|  
|  diff --git a/libraries/base/GHC/Base.hs b/libraries/base/GHC/Base.hs
|  index 501a6d5..0d20e34 100644
|  --- a/libraries/base/GHC/Base.hs
|  +++ b/libraries/base/GHC/Base.hs
|  @@ -225,8 +225,32 @@ class Monoid a where
|   mconcat = foldr mappend mempty
|  
|   instance Monoid [a] where
|  +{-# INLINE mempty #-}
|   mempty  = []
|  +{-# INLINE mappend #-}
|   mappend = (++)
|  +{-# INLINE mconcat #-}
|  +mconcat xss = [x | xs <- xss, x <- xs]
|  +-- See Note: [List comprehensions and inlining]
|  +
|  +{-
|  +Note: [List comprehensions and inlining]
|  +
|  +The list monad operations are traditionally described in terms of
|  concatMap:
|  +
|  +xs >>= f = concatMap f xs
|  +
|  +Similarly, mconcat for lists is just concat. Here in Base, however,
|  we
|  +don't have concatMap, and we'll refrain from adding it here so it
|  won't
|  +have to be hidden in imports. Instead, we use GHC's list
|  comprehension
|  +desugaring mechanism to define mconcat and the Applicative and Monad
|  instances for lists.
|  +We mark them INLINE because the inliner is not generally too keen to
|  +inline build forms such as the ones these desugar to without our
|  +insistence.  Defining these using list comprehensions instead of
|  foldr
|  +has an additional potential benefit, as described in
|  +compiler/deSugar/DsListComp.lhs: if optimizations needed to make
|  +foldr/build forms efficient are turned off, we'll get reasonably
|  efficient translations anyway.
|  +-}
|  
|   instance Monoid b => Monoid (a -> b) where
|   mempty _ = mempty
|  @@ -501,7 +525,9 @@ sequence ms = foldr k (return []) ms
|   -- | @'mapM' f@ is equivalent to @'sequence' . 'map' f@.
|   mapM :: Monad m => (a -> m b) -> [a] -> m [b]  {-# INLINE mapM #-}
|  -mapM f as   =  sequence (map f as)
|  +mapM f as = foldr k (return []) as
|  +where
|  +  k a r = do { x <- f a; xs <- r; return (x:xs) }
|  
|   -- | Promote a function to a monad.
|   liftM   :: (Monad m) => (a1 -> r) -> m a1 -> m r
|  @@ -667,16 +693,27 @@ instance MonadPlus Maybe
|   -- The list type
|  
|   instance Functor [] where
|  +{-# INLINE fmap #-}
|   fmap = map
|  
|  +-- See Note: [List comprehensions and inlining]
|   instance Applicative [] where
|  -pure = return
|  -(<*>) = ap
|  -
|  -instance  Monad []  where
|  -m >>= k = foldr ((++) . k) [] m
|  -m >> k  = foldr ((++) . (\ _ -> k)) [] m
|  +{-# INLINE pure #-}
|  +pure x= [x]
|  +{-# INLINE (<*>) #-}
|  +fs <*> xs = [f x | f <- fs, x <- xs]
|  +{-# INLINE (*>) #-}
|  +xs *> ys  = [y | _ <- xs, y <- ys]
|  +
|  +-- See Note: [List comprehensions and inlining] instance Monad []
|  +where
|  +{-# INLINE (>>=) #-}
|  +xs >>= f = [y | x <- xs, y <- f x]
|  +{-# INLINE (>>) #-}
|  +(>>) = (*>)
|  +{-# INLINE return #-}
|   return x= [x]
|  +{-# INLINE fail #-}
|   fail _  = []
|  
|   instance Alternative [] where
|  
|  ___
|  ghc-commits mailing list
|  ghc-comm...@haskell.org
|  http:

RE: [GHC] #9781: Make list monad operations fuse

[Simon Peyton Jones]

The inliner is a finicky beast. In response to your insults, I will say that 
although GHC has beautiful ideas in it, a lot of the details of the 
optimization passes and how they fit together *are* a bit of a crapshoot, 
chosen by benchmarks rather than theory.

It’s true that, particularly for fusion, inlining can make a huge difference.  
And GHC really does need help… it’s extremely hard for it to make the “right” 
choice all the time.

I strongly agree with Kim-Ee that we should play the game of “optimise by 
randomly mutating the program and pick the version that (today) happens to run 
faster”.  But I don’t think David is doing that.   There is, at least a Note: 
[List comprehensions and inlining].

What we should do is to

· understand which the crucial inlining decisions are, and why

· express that understanding in a Note, so that subsequent people 
looking at the code also understand

· remove any un-necessary code cruft, which sometimes accumulates 
during a period of experimentation, leaving the minimum necessary to achieve 
the effect

I’m not quite certain that all these steps have been done here, and they can be 
tiresome to do.  But worth it!

Simon

From: Libraries [mailto:libraries-boun...@haskell.org] On Behalf Of David Feuer
Sent: 11 November 2014 09:12
To: Kim-Ee Yeoh
Cc: Haskell Libraries; ghc-devs
Subject: Re: [GHC] #9781: Make list monad operations fuse


On Nov 11, 2014 3:56 AM, "Kim-Ee Yeoh" mailto:k...@atamo.com>> 
wrote:
>
> From the patch fragment at
>
> https://phabricator.haskell.org/D455?id=1311#inline-3123
>
> What's the justification for expanding out the definition of mapM from 
> "sequence . map f" into do-notation and duplicated code?
>
> Observe how mapM now duplicates code from sequence.

One good option might be to redefine sequence in terms of mapM.

> The absence of benchmarks is bad enough. What's worse is that the given 
> excuse boils down to "Pity the poor compiler! Let's take over its work 
> instead. Like, just in case, you know."

The excuse is that it actually makes a big difference for nofib. Why? I would 
have to guess it relates to what inlines when. The inliner is a finicky beast. 
In response to your insults, I will say that although GHC has beautiful ideas 
in it, a lot of the details of the optimization passes and how they fit 
together *are* a bit of a crapshoot, chosen by benchmarks rather than theory. 
Theory sometimes comes up behind and explains why the benchmarks do what they 
do, but you can't expect every little change to be backed up by some deep 
theoretical reason.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Typechecker plugins: request for review and another workflow question

[Adam Gundry]

I've just pushed wip/tc-plugins-amg, in which I remove the hs-boot file
and unify the core2core and typechecker plugins under a single -fplugin
flag. This did involve making a separate module for plugins, which I
think is probably a good thing.

I looked at using a hook instead, with a plugin to modify hooks, but I'm
not sure exactly where such a plugin should be invoked. Ideally we want
the typechecker modifications to work on a per-module basis, but most of
the hooks seem to have a wider scope than that.

Adam


On 11/11/14 03:08, Eric Seidel wrote:
> 
>> On Nov 10, 2014, at 07:58, Austin Seipp  wrote:
>>
>> Hi Iavor;
>>
>> I took a very, very cursory glance. Naturally I am not a typechecker
>> guru, but I did look over the mechanical changes/extensions to thread
>> things around. Two things popped out to me:
>>
>> - 1) Ugh, a new .hs-boot file. I assume this wasn't added without
>> good reason, but ideally we would be eliminating them quicker than we
>> add them. :) I want to take a closer look at this; perhaps we can
>> refactor something for you to remove the need for this.
>>
>> - 2) I am kind of not a fan of having separate 'plugins for
>> core2core' and 'plugins for typechecking' flags, AKA -ftc-plugin and
>> -fplugin. Ideally I would think all plugins could be uniformly
>> specified by simply saying '-fplugin'. This mostly avoids the need for
>> duplication and a naming convention/slew of flags for each case (which
>> we have to catalog and document). There may be an easy way to make
>> this the case; I haven't looked closely yet (it has been some time
>> since I starred at the plugin code, even though Max wrote it and I
>> helped get it merged!)
> 
> I looked into this again a bit today and recall now why we made a separate
> Plugin type and flag; adding the TcPlugin to the existing Plugin type defined
> in CoreMonad creates a circular dependency between CoreMonad and TcRnTypes.
> 
> We could (and perhaps should) move all of the plugin types into a separate
> module, but that would require pulling other types (e.g. CoreToDo) out of
> CoreMonad to break the circularity.



-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: let/app invariant violated by code generated with mkCoreApp

[Simon Peyton Jones]

Oh bother, that is _so_ tiresome. The desugarer establishes the let/app 
invariant, so we get

I# x_help

but if x_help has a compulsory unfolding to (x void), returning an Int#, that 
violates the let/app invariant.  Sigh.  This is a ridiculous amount of work for 
a tiny corner (pattern synonyms for unboxed constants).

Harump.  Let's see.  We are talking only of things like this

pattern P = 4#

correct?  Perhaps it may be simpler to make the psWrapper in PatSyn be
psWrapper :: Either Id Literal
and treat such patterns specially from the moment we first see them?  That 
would eliminate all this void stuff entirely.

Pursuing the current line, though, I suppose that the desugarer could inline 
compulsory unfoldings during desugaring itself.  In this line, add a case for 
when var has a compulsory unfolding.

dsExpr (HsVar var)= return (varToCoreExpr var)   -- See Note 
[Desugaring vars]

That would, I suppose, be the quickest pathc.

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Dr.
|  ERDI Gergo
|  Sent: 08 November 2014 14:03
|  To: GHC Devs
|  Subject: let/app invariant violated by code generated with mkCoreApp
|  
|  Hi,
|  
|  I'm trying to attach (f Void#) as a compulsory unfolding to an Id.
|  Here's what I tried originally:
|  
|   let unfolding = mkCoreApp (Var worker_id) (Var voidPrimId)
|   wrapper_id' = setIdUnfolding wrapper_id $
|  mkCompulsoryUnfolding unfolding
|  
|  However, when I try to use wrapper_id' in the desugarer, the Core
|  linter looks at me strange. This is the original Core:
|  
|  f :: Int
|  [LclIdX, Str=DmdType]
|  f = break<1>() GHC.Types.I# Main.$WPAT
|  
|  and this is the error message ($WPAT is the wrapper_id', PAT is the
|  worker_id in this example)
|  
|  : Warning:
|   In the expression: I# (PAT void#)
|   This argument does not satisfy the let/app invariant: PAT void#
|  
|  Now, I thought I'd make sure mkCoreApp generated correct Core by
|  writing it out by hand:
|  
|   let unfolding = Case (Var voidPrimId) voidArgId pat_ty
|  [(DEFAULT,[],App (Var worker_id) (Var voidArgId))]
|  
|  however, bizarrely, this *still* results in *the same* error message,
|  as if something was transforming it back to a straight App.
|  
|  Anyone have any hints what I'm doing wrong here?
|  
|  Bye,
|   Gergo
|  
|  --
|  
| .--= ULLA! =-.
|  \ http://gergo.erdi.hu   \
|   `---= ge...@erdi.hu =---'
|  You are in a twisty maze of little install diskettes.
|  ___
|  ghc-devs mailing list
|  ghc-devs@haskell.org
|  http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Concrete syntax for pattern synonym type signatures

[Richard Eisenberg]

Let me restate the proposals more concretely. Correct me if I'm wrong!

Suppose we have the following declarations:

   data T a b where
 MkT :: (Eq a, Ord b, Show c) => a -> (b, b) -> c -> T a b

   pattern P x y = MkT 5 (y, True) x

What is the type of P?

Simon's proposal:

> pattern P :: (Eq a, Ord Bool, Show c) => (Num a) => c -> Bool -> T a Bool

Or, more generally:

> pattern  ::  =>  =>  args> -> 


My proposal:

> pattern P :: (Num a) => (Eq a, Ord Bool, Show c) => c -> Bool -> T a Bool

Or, more generally:

> pattern  ::  =>  =>  args> -> 

The only difference is the order of required vs. provided constraints.


My previous comment about bizarre scoping is that the universal variables -- 
which (in my opinion) go with the required constraints -- scope over both sets 
of constraints. The existential variables go with the provided constraints and 
scope over only the provided constraints. So, Simon's ordering means that the 
scope of the second (lexically) listed constraints have a *smaller* scope than 
the first listed constraints. With my ordering, the size of the scope increases 
as you read to the right, as it normally does.

On Nov 10, 2014, at 4:07 PM, Simon Peyton Jones  wrote:

> | Whatever syntax we choose, I would highly recommend putting in a helpful
> | link to more information in error messages.
> 
> In principle I like this very much, but I have always stumbled on 
> - writing links that will remain stable for ever (and are hence 
> release-specific)
> - keeping them up to date when the version changes
> - making them easy to test e.g. in my build tree
> 
> Separate question really, but would need some systematic attention to make it 
> work properly in general.

Is there a way of pulling the version from DynFlags? If so, it would be easy to 
include the version number in an SDoc. Then, we could make the link go to the 
user manual. It would be easy to write a function `userManualLink :: String -> 
SDoc` that takes the last bit of the link and produces a link to the manual for 
the version at hand. (It wouldn't work for non-released versions, but I'm OK 
with that.) 

Richard

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Concrete syntax for pattern synonym type signatures

[Edward Kmett]

Lamely, I can't seem to reconstruct the problem.

GHC seems to be more careful about gathering the constraints up into a
tuple even when I give an explicit type signature involving nested contexts
nowadays.

-Edward

On Mon, Nov 10, 2014 at 4:07 PM, Simon Peyton Jones 
wrote:

>   Note though, it doesn't mean the same thing to say (Foo a, Bar a b) =>
> ... as it does to say
>
> Foo a => Bar a b => ...
>
> The latter can use Foo a when working on Bar a b, but not Bar a b to
> discharge Foo a, which makes a difference when you have functional
> dependencies.
>
>
>
> I disagree.  Can you offer a concrete example, and show that one
> typechecks when the other does not?
>
>
>
> Simon
>
>
>
> *From:* Edward Kmett [mailto:ekm...@gmail.com]
> *Sent:* 10 November 2014 15:46
> *To:* Richard Eisenberg
> *Cc:* Simon Peyton Jones; GHC Devs
> *Subject:* Re: Concrete syntax for pattern synonym type signatures
>
>
>
> Note though, it doesn't mean the same thing to say (Foo a, Bar a b) => ...
> as it does to say
>
>
>
> Foo a => Bar a b => ...
>
>
>
> The latter can use Foo a when working on Bar a b, but not Bar a b to
> discharge Foo a, which makes a difference when you have functional
> dependencies.
>
>
>
> So in some sense the 'pattern requires/supplies' split is just that.
>
>
>
>
>
>
>
> That said, Richard's other option
>
>
>
> pattern Foo a => P :: Bar a => a
>
>
>
> has the benefit that it looks a bit like the old datatype contexts (but
> here applied to the constructor/pattern).
>
>
>
> If we expect the left hand side or the right hand side to be most often
> trivial then that may be worth considering.
>
>
>
> You'd occasionally have things like
>
>
>
> pattern (Num a, Eq a) => Foo :: a
>
>
>
> for
>
>
>
> pattern Foo = 8
>
>
>
> but most of the time they'd wind up just looking like a GADT constructor.
>
>
>
> -Edward
>
>
>
> On Sun, Nov 9, 2014 at 10:02 PM, Richard Eisenberg 
> wrote:
>
>
> On Nov 9, 2014, at 2:11 PM, Simon Peyton Jones 
> wrote:
> >
> > * One other possibility would be two => thus
> >   pattern P :: (Eq b) => (Num a, Eq a) => ...blha...
> >
>
> I should note that I can say this in 7.8.3:
>
> foo :: Show a => Eq a => a -> String
> foo x = show x ++ show (x == x)
>
> Note that I've separated the two constraints with a =>, not a comma. This
> syntax does what you might expect. (I actually believe that this is an
> improvement over the conventional syntax, but that's a story for another
> day.) For better or worse, this trick does not work for GADT constructors
> (which is a weird incongruence with function type signatures), so adding
> the extra arrow does not really steal syntax from GADT pattern synonyms.
>
> Richard
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: [GHC] #9781: Make list monad operations fuse

[David Feuer]

On Nov 11, 2014 6:04 AM, "Simon Peyton Jones"  wrote:
> It’s true that, particularly for fusion, inlining can make a huge
difference.  And GHC really does need help… it’s extremely hard for it to
make the “right” choice all the time.

The inliner does indeed do amazing things, and list fusion does indeed do
lovely things for user code. It's just not the most *reliable* optimization
in the compiler. I don't think there's anything wrong with admitting that
and trying to avoid relying on it too heavily in *library* code. Kim-Ee was
right that expanding out mapM by hand bloated the source. I've since
defined `sequence=mapM id` to resolve that problem, and doing so does not
hurt the benchmarks—it relies only on inlining id (which is quite reliable)
and beta-reducing (which is also quite reliable).

> I strongly agree with Kim-Ee that we should play the game of “optimise by
randomly mutating the program and pick the version that (today) happens to
run faster”.  But I don’t think David is doing that.   There is, at least a
Note: [List comprehensions and inlining].

I've been trying to leave a trail of comments and notes as I go. I may need
to go further.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: Concrete syntax for pattern synonym type signatures

[Simon Peyton Jones]

|  My proposal:
|  
|  > pattern P :: (Num a) => (Eq a, Ord Bool, Show c) => c -> Bool -> T a
|  > Bool
|  
|  My previous comment about bizarre scoping is that the universal
|  variables -- which (in my opinion) go with the required constraints --
|  scope over both sets of constraints. The existential variables go with
|  the provided constraints and scope over only the provided constraints.
|  So, Simon's ordering means that the scope of the second (lexically)
|  listed constraints have a *smaller* scope than the first listed
|  constraints. With my ordering, the size of the scope increases as you
|  read to the right, as it normally does.

I _think_ you mean that you _could_ write P's type like this:

|  > pattern P :: forall a. (Num a) => 
  forall c. (Eq a, Ord Bool, Show c) => 
  c -> Bool -> T a

I'm not sure we really would give it that nested structure, but it would be 
reasonable to do so.

Richard's point is that the match-required constraints can *only* mention the 
universally quantified type variables.

So yes, I think Richard is probably right.  

Incidentally ote that 
pattern P x = (3,x)
would have type
pattern P :: Num a => () => b -> (a,b)

But since the "match-provided but no match-required" case must look simple, the 
"match-required but no match-provided" case is bound to look odd.

OK, Gergo, I think you are good to go now.

Simon

|  On Nov 10, 2014, at 4:07 PM, Simon Peyton Jones
|   wrote:
|  
|  > | Whatever syntax we choose, I would highly recommend putting in a
|  > | helpful link to more information in error messages.
|  >
|  > In principle I like this very much, but I have always stumbled on
|  > - writing links that will remain stable for ever (and are hence
|  > release-specific)
|  > - keeping them up to date when the version changes
|  > - making them easy to test e.g. in my build tree
|  >
|  > Separate question really, but would need some systematic attention
|  to make it work properly in general.
|  
|  Is there a way of pulling the version from DynFlags? If so, it would
|  be easy to include the version number in an SDoc. Then, we could make
|  the link go to the user manual. It would be easy to write a function
|  `userManualLink :: String -> SDoc` that takes the last bit of the link
|  and produces a link to the manual for the version at hand. (It
|  wouldn't work for non-released versions, but I'm OK with that.)
|  
|  Richard

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Typechecker plugins: request for review and another workflow question

[Eric Seidel]

> On Nov 11, 2014, at 04:19, Adam Gundry  wrote:
> 
> I've just pushed wip/tc-plugins-amg, in which I remove the hs-boot file
> and unify the core2core and typechecker plugins under a single -fplugin
> flag. This did involve making a separate module for plugins, which I
> think is probably a good thing.

Thanks! I just checked out your branch, but had to add `Plugins` to the
list of exposed modules in ghc.cabal in order to actually use a plugin
though. Otherwise I get a horrible

  Symbol not found: _ghc_Plugins_Plugin_con_info

error from the linker when I try to compile a module with -fplugin=MyPlugin.

> I looked at using a hook instead, with a plugin to modify hooks, but I'm
> not sure exactly where such a plugin should be invoked. Ideally we want
> the typechecker modifications to work on a per-module basis, but most of
> the hooks seem to have a wider scope than that.

Well, I think we want the option to decide between per-module and global
invocation of plugins, e.g. if I pass -fplugin on the command-line then
I would expect ghc to use the plugin for *any* module it ends up compiling.

The list of plugins to enable is in the DynFlags, which suggests to me that
GHC must compile each module with a specific set of DynFlags, based on the
LANGUAGE and OPTIONS_GHC pragmas. The Hooks are also in the DynFlags, so
perhaps all we need to do is make -fplugin add a Hook, and let GHC's
existing machinery take care of the rest?

Eric
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Typechecker plugins: request for review and another workflow question

[Iavor Diatchki]

Hi,

thanks Adam!   I merged your changes into `wip/tc-plugin` and updated the
type-nats plugin to work with the new plugin interface.

-Iavor
PS: It looks like `Plugins` was already in ghc.cabal.in and things worked
form me.  Maybe the problem was a stale ghc.cabal?





On Tue, Nov 11, 2014 at 9:49 AM, Eric Seidel  wrote:

>
> > On Nov 11, 2014, at 04:19, Adam Gundry  wrote:
> >
> > I've just pushed wip/tc-plugins-amg, in which I remove the hs-boot file
> > and unify the core2core and typechecker plugins under a single -fplugin
> > flag. This did involve making a separate module for plugins, which I
> > think is probably a good thing.
>
> Thanks! I just checked out your branch, but had to add `Plugins` to the
> list of exposed modules in ghc.cabal in order to actually use a plugin
> though. Otherwise I get a horrible
>
>   Symbol not found: _ghc_Plugins_Plugin_con_info
>
> error from the linker when I try to compile a module with
> -fplugin=MyPlugin.
>
> > I looked at using a hook instead, with a plugin to modify hooks, but I'm
> > not sure exactly where such a plugin should be invoked. Ideally we want
> > the typechecker modifications to work on a per-module basis, but most of
> > the hooks seem to have a wider scope than that.
>
> Well, I think we want the option to decide between per-module and global
> invocation of plugins, e.g. if I pass -fplugin on the command-line then
> I would expect ghc to use the plugin for *any* module it ends up compiling.
>
> The list of plugins to enable is in the DynFlags, which suggests to me that
> GHC must compile each module with a specific set of DynFlags, based on the
> LANGUAGE and OPTIONS_GHC pragmas. The Hooks are also in the DynFlags, so
> perhaps all we need to do is make -fplugin add a Hook, and let GHC's
> existing machinery take care of the rest?
>
> Eric
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Control.Exception.assert vs HsVersions.h's ASSERT?

[RodLogic]

Having spent a bit of time staring at GHC's sources, I noticed that there
are around 140 modules using a set of C macros for assertions, namely:

ASSERT
> ASSERT2
> MASSERT
> MASSERT2
> ASSERTM
> ASSERTM2


However, I see that Control.Exception already provides a first class
Haskell assertion function:

assert :: Bool -> a -> a


that is turned off automatically when optimizations are turned on, and
provides an error containing the filename and line number, which was why I
thought the above macros existed and were still in use.

My question is: is there any reason to keep using these macros instead of
*assert*?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: [GHC] #9781: Make list monad operations fuse

[David Feuer]

Note also that there are fairly clear reasons that fusion is flakier than
many other optimizations. In particular, it requires the compiler to do
things that seem *weird*, and that in most other cases are just *bad
ideas*. At least, it requires:

1. Inlining things that look large and/or expensive. This is done in the
hope that they will fuse with other things, producing a whole that is
smaller and cheaper than the sum of its parts. It is done with the
knowledge that these things will (in most cases) be written back to smaller
cheaper forms if they don't fuse. That is, *our* knowledge of that—the
compiler has absolutely no way to know what shenanigans we're up to.

2. Refraining from floating things that look like they should be floated.
GHC likes to pull constants and such out because doing so improves sharing
and also improves other analyses. But if it pulls our producer away from
our consumer, they will not fuse. I think Simon's simplifier changes a few
months ago helped with this issue, but I don't know that it is (or can ever
be) resolved completely.
On Nov 11, 2014 11:54 AM, "David Feuer"  wrote:

>
> On Nov 11, 2014 6:04 AM, "Simon Peyton Jones" 
> wrote:
> > It’s true that, particularly for fusion, inlining can make a huge
> difference.  And GHC really does need help… it’s extremely hard for it to
> make the “right” choice all the time.
>
> The inliner does indeed do amazing things, and list fusion does indeed do
> lovely things for user code. It's just not the most *reliable* optimization
> in the compiler. I don't think there's anything wrong with admitting that
> and trying to avoid relying on it too heavily in *library* code. Kim-Ee was
> right that expanding out mapM by hand bloated the source. I've since
> defined `sequence=mapM id` to resolve that problem, and doing so does not
> hurt the benchmarks—it relies only on inlining id (which is quite reliable)
> and beta-reducing (which is also quite reliable).
>
> > I strongly agree with Kim-Ee that we should play the game of “optimise
> by randomly mutating the program and pick the version that (today) happens
> to run faster”.  But I don’t think David is doing that.   There is, at
> least a Note: [List comprehensions and inlining].
>
> I've been trying to leave a trail of comments and notes as I go. I may
> need to go further.
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: let/app invariant violated by code generated with mkCoreApp

[Dr . ÉRDI Gergő]

Yep, that seems to work. I'll add a note explaining why we need unfoldings
here.
On Nov 11, 2014 10:14 PM, "Simon Peyton Jones" 
wrote:

> Oh bother, that is _so_ tiresome. The desugarer establishes the let/app
> invariant, so we get
>
> I# x_help
>
> but if x_help has a compulsory unfolding to (x void), returning an Int#,
> that violates the let/app invariant.  Sigh.  This is a ridiculous amount of
> work for a tiny corner (pattern synonyms for unboxed constants).
>
> Harump.  Let's see.  We are talking only of things like this
>
> pattern P = 4#
>
> correct?  Perhaps it may be simpler to make the psWrapper in PatSyn be
> psWrapper :: Either Id Literal
> and treat such patterns specially from the moment we first see them?  That
> would eliminate all this void stuff entirely.
>
> Pursuing the current line, though, I suppose that the desugarer could
> inline compulsory unfoldings during desugaring itself.  In this line, add a
> case for when var has a compulsory unfolding.
>
> dsExpr (HsVar var)= return (varToCoreExpr var)   -- See Note
> [Desugaring vars]
>
> That would, I suppose, be the quickest pathc.
>
> Simon
>
> |  -Original Message-
> |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Dr.
> |  ERDI Gergo
> |  Sent: 08 November 2014 14:03
> |  To: GHC Devs
> |  Subject: let/app invariant violated by code generated with mkCoreApp
> |
> |  Hi,
> |
> |  I'm trying to attach (f Void#) as a compulsory unfolding to an Id.
> |  Here's what I tried originally:
> |
> |   let unfolding = mkCoreApp (Var worker_id) (Var voidPrimId)
> |   wrapper_id' = setIdUnfolding wrapper_id $
> |  mkCompulsoryUnfolding unfolding
> |
> |  However, when I try to use wrapper_id' in the desugarer, the Core
> |  linter looks at me strange. This is the original Core:
> |
> |  f :: Int
> |  [LclIdX, Str=DmdType]
> |  f = break<1>() GHC.Types.I# Main.$WPAT
> |
> |  and this is the error message ($WPAT is the wrapper_id', PAT is the
> |  worker_id in this example)
> |
> |  : Warning:
> |   In the expression: I# (PAT void#)
> |   This argument does not satisfy the let/app invariant: PAT void#
> |
> |  Now, I thought I'd make sure mkCoreApp generated correct Core by
> |  writing it out by hand:
> |
> |   let unfolding = Case (Var voidPrimId) voidArgId pat_ty
> |  [(DEFAULT,[],App (Var worker_id) (Var voidArgId))]
> |
> |  however, bizarrely, this *still* results in *the same* error message,
> |  as if something was transforming it back to a straight App.
> |
> |  Anyone have any hints what I'm doing wrong here?
> |
> |  Bye,
> |   Gergo
> |
> |  --
> |
> | .--= ULLA! =-.
> |  \ http://gergo.erdi.hu   \
> |   `---= ge...@erdi.hu =---'
> |  You are in a twisty maze of little install diskettes.
> |  ___
> |  ghc-devs mailing list
> |  ghc-devs@haskell.org
> |  http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs