RE: Pattern synonym constraints :: Ord a => () => ...

[Simon Peyton Jones via Glasgow-haskell-users]

 must be the union of the constraints required to match the pattern, 
_plus_ required to build with the pattern -- if it is bidirectional.
I think that is confusing too!  How about this:

  *   ⟨CReq⟩ are the constraints required to match the pattern, in a pattern 
match.
  *   ⟨CProv⟩ are the constraints made available (provided) by a successful 
pattern match.
  *and  are both required when P is used as a constructor in 
an expression.
That makes the constructor form explicit.
The only mechanism for getting the constraints needed for building is by 
polluting the constraints needed for matching.
Yes I agree that’s bad. It is acknowledge as such in the paper, and is the 
subject of accepted proposal #42.

Simon

PS: I am leaving Microsoft at the end of November 2021, at which point 
simo...@microsoft.com<mailto:simo...@microsoft.com> will cease to work.  Use 
simon.peytonjo...@gmail.com<mailto:simon.peytonjo...@gmail.com> instead.  (For 
now, it just forwards to simo...@microsoft.com.)

From: Anthony Clayden 
Sent: 06 October 2021 11:42
To: Simon Peyton Jones 
Cc: Gergő Érdi ; GHC users 
Subject: Re: Pattern synonym constraints :: Ord a => () => ...



On Wed, 6 Oct 2021 at 21:24, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:

I suggest the User Guide needs an example where a constraint needed for 
matching (presumably via a View pattern) is not amongst the constraints carried 
inside the data constructor, nor amongst those needed for building. Then the 
limitations in the current design would be more apparent for users.

The user 
manual<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.gitlab.haskell.org%2Fghc%2Fdoc%2Fusers_guide%2Fexts%2Fpattern_synonyms.html%3Fhighlight%3Dpattern%2520syn%23typing-of-pattern-synonyms&data=04%7C01%7Csimonpj%40microsoft.com%7C941ec01fb46743eefb4d08d988b5e64a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637691137569565464%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=B7ZHX1fB5hRZkVuvId1OhnC6j5oYoqeSaD2hByBAPRM%3D&reserved=0>
 does already speak about the type of a builder, here:

...
   How could we make that clearer?

This point in that section of the Guide is wrong/misleading:


· ⟨CReq⟩ are the constraints required to match the pattern.
 must be the union of the constraints required to match the pattern, 
_plus_ required to build with the pattern -- if it is bidirectional.


Then thank you Simon, but it's the type of the _matcher_ that's problematic. 
The only mechanism for getting the constraints needed for building is by 
polluting the constraints needed for matching. Here's a (crude, daft) example, 
using guards to 'raise' a required-for-failing-to-build that isn't 
required-for-successful-building nor for-matching

>pattern TwoNode :: (Show a, Ord a) => () => a -> a -> Tree a 
> -- GHC insists on both constraints as Req'd
>
>pattern TwoNode x y  <- Node Empty x (Leaf y)   where
>  TwoNode x y | x > y = Node Empty x (Leaf y)
>  | otherwise = error (show x ++ " not greater " ++ show y)
To quote you from May 1999


>But when you take a constructor *apart*, the invariant must hold

>by construction: you couldn't have built the thing you are taking

>apart unless invariant held.  So enforcing the invariant again is

>redundant; and in addition it pollutes the type of selectors.


`Show a` must have "held by construction" of the `Node`. But the PatSyn's 
constraints are requiring more than that was true in some distant line of code: 
 it wants evidence  in the form of a dictionary at the point of deconstructing; 
since the build was successful, I ipso facto don't want to `show` anything in 
consuming it. An `instance Foldable Tree` has no mechanism to pass in any such 
dictionaries (which'll anyway be redundant, as you say).


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

RE: Pattern synonym constraints :: Ord a => () => ...

[Simon Peyton Jones via Glasgow-haskell-users]

Perhaps I'm just stupid, and should be disqualified from using such features.
Only as a result of this thread (not from the User Guide nor from the paper) do 
I discover "use" means match-on.

You are not stupid.  And since you misunderstood despite effort, the 
presentation is - by definition - not as good as it should be.

The paper focuses pretty much entirely on matching, and takes building for 
granted.  But I can now see that it is not explicit on this point, and that 
leaves it open to misinterpretation.   I think the paper is reasonably careful 
to say "match on" rather than "use", but I wouldn't bet on it.

I suggest the User Guide needs an example where a constraint needed for 
matching (presumably via a View pattern) is not amongst the constraints carried 
inside the data constructor, nor amongst those needed for building. Then the 
limitations in the current design would be more apparent for users.

The user 
manual
 does already speak about the type of a builder, here:

*  For a bidirectional pattern synonym, a use of the pattern synonym as an 
expression has the type

(CReq, CProv) => t1 -> t2 -> ... -> tN -> t

So in the previous example, when used in an expression, ExNumPat has type

ExNumPat :: (Num a, Eq a, Show b) => b -> T t

Notice that this is a tiny bit more restrictive than the expression MkT 42 x 
which would not require (Eq a).
That does seem to directly address the use of a pattern synonym in an 
expression, and means that both CReq and Cprov are required at use sites in 
expressions.   It even includes an example of the sort you wanted.   How could 
we make that clearer?

Thanks

Simon


PS: I am leaving Microsoft at the end of November 2021, at which point 
simo...@microsoft.com will cease to work.  Use 
simon.peytonjo...@gmail.com instead.  (For 
now, it just forwards to simo...@microsoft.com.)

From: Glasgow-haskell-users  On 
Behalf Of Anthony Clayden
Sent: 06 October 2021 06:25
To: Gergő Érdi 
Cc: GHC users 
Subject: Re: Pattern synonym constraints :: Ord a => () => ...


Thanks Gergö, I've read that paper many times (and the User Guide). Nowhere 
does it make the distinction between required-for-building vs 
required-for-matching. And since most of the syntax for PatSyns (the `where` 
equations) is taken up with building, I'd taken it that "required" means 
required-for-building.

There is one paragraph towards the end of section 6 that kinda hints at the 
issue here. It's so cryptic it's no help. "An alternative would be to carry two 
types for each pattern synonym: ...". But already PatSyns carry two sets of 
_constraints_. The matrix type after the constraints is determined by the 
mapping to/from the data constructor. Why would there be two of those? What 
this paragraph might mean (?) is 'carry three sets of constraints', but put one 
set in a completely different signature. As per the proposal.

>  they [Required constraints] are "required" to be able to use the pattern 
> synonym.

Is highly misleading. Only as a result of this thread (not from the User Guide 
nor from the paper) do I discover "use" means match-on. The paper really does 
not address typing for "use" for building. I agree with SPJ's comment (quoted 
in the proposal) "This turns out to be wrong in both directions."

I suggest the User Guide needs an example where a constraint needed for 
matching (presumably via a View pattern) is not amongst the constraints carried 
inside the data constructor, nor amongst those needed for building. Then the 
limitations in the current design would be more apparent for users.

Perhaps I'm just stupid, and should be disqualified from using such features. 
(I keep away from GADTs for those reasons.) So I'm not going to volunteer to 
revise the User Guide further.


On Wed, 6 Oct 2021 at 15:26, Gergő Érdi mailto:ge...@erdi.hu>> 
wrote:
If you haven't yet, it is probably a good idea to read section 6 of
https://gergo.erdi.hu/papers/patsyns/2016-hs-patsyns-ext.pdf

On Wed, Oct 6, 2021 at 10:23 AM Gergő Érdi 
mailto:ge...@erdi.hu>> wrote:
>
> > I'm afraid none of this is apparent from the User Guide -- and I even 
> > contributed some material to the Guide, without ever understanding that. 
> > Before this thread, I took it that 'Required' means for building -- as in 
> > for smart constructors.
>
> No, that's not what the required/provided distinction means at

RE: -dinline-check for symbolic names?

[Simon Peyton Jones via Glasgow-haskell-users]

|  First, reading the ghc source code suggests I can only have one -ddinline-
|  check. Correct?

Yes. The last one wins.  This should be in the user manual.  Would anyone like 
to offer a PR?

|  Also, I'm guessing that the inlining I didn't see reported by -dinline-check
|  happened inside the simplifier pass inserted by the ConCat plugin.  (And
|  hence INLINE [0] moved it out of that pass.)  Is it possible that the flag
|  isn't getting propagated there?

I don't see how that could happen, but I only have a vague idea of what is 
going on.

Simon

|  -Original Message-
|  From: Michael Sperber 
|  Sent: 18 August 2021 14:14
|  To: Simon Peyton Jones 
|  Cc: glasgow-haskell-users@haskell.org
|  Subject: Re: -dinline-check for symbolic names?
|  
|  
|  On Tue, Aug 10 2021, Simon Peyton Jones  wrote:
|  
|  > It's hard to tell what is happening without a repro case. Can you share
|  one?
|  
|  Haven't been able to do that with <10MB of output, I'm afraid ...
|  
|  > You suggested that it might have something to do with using an
|  > operator.  Does the same thing happen if you replace the operator with
|  > an alpha-numeric name?
|  
|  I've now concluded several things are coming together.  As things started
|  working with INLINE [0] instead of INLINE, it's not the symbolic name.
|  
|  First, reading the ghc source code suggests I can only have one -ddinline-
|  check. Correct?
|  
|  Also, I'm guessing that the inlining I didn't see reported by -dinline-check
|  happened inside the simplifier pass inserted by the ConCat plugin.  (And
|  hence INLINE [0] moved it out of that pass.)  Is it possible that the flag
|  isn't getting propagated there?
|  
|  (Sorry for being vague - if you don't know offhand, it's not worth digging
|  without more info from me.)
|  
|  --
|  Regards,
|  Mike
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: Avoiding construction of dead dictionaries

[Simon Peyton Jones via Glasgow-haskell-users]

Hi Mike

Repro case is something like
* Here is a source or files
* Compile like this
* Look at the generated Core...observe silly thing happening

Evidence of importance could be as simple as "in my application I'm seeing a 
lot of these redundant dictionaries being built for no reason".  Or, stronger 
"this is slowing my application down by 5%".  TL;DR: is this just a curiosity 
that you noticed, or is it something that matters to you, and if so why?

|  Is there any way to see how far evaluates the dictionary construction to be
|  able to match on that unboxed tuple?

Not sure what you mean here, but once we have a repro case we can discuss.

Worth opening a ticket too -- email is easily lost.

Thanks

Simon

|  -Original Message-
|  From: Michael Sperber 
|  Sent: 12 August 2021 10:15
|  To: Simon Peyton Jones 
|  Cc: Sebastian Graf ; glasgow-haskell-users@haskell.org
|  Subject: Re: Avoiding construction of dead dictionaries
|  
|  
|  On Mon, Aug 09 2021, Simon Peyton Jones  wrote:
|  
|  > Could you offer a small repro case, with a pointer to evidence that it
|  matters in practice, and open a ticket?
|  
|  I'll try my best, but I'm unsure how I would generate evidence.  Could you
|  give me a hint?
|  
|  Is there any way to see how far evaluates the dictionary construction to be
|  able to match on that unboxed tuple?
|  
|  --
|  Regards,
|  Mike
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: InstanceSigs -- rationale for the "must be more polymorphic than"

[Simon Peyton Jones via Glasgow-haskell-users]

Do you have a concrete example?

I think that the recursive calls will all go via the original class method with 
its original type - we can't know that it's calling *this* instance till much 
later.   So I still don't get it.  An example would clear it up.

Simon

From: David Feuer 
Sent: 10 August 2021 12:01
To: Simon Peyton Jones 
Cc: Anthony Clayden ; GHC users 

Subject: Re: InstanceSigs -- rationale for the "must be more polymorphic than"

Simon, there are times when a function has to be generalized to be made 
polymorphic recursive. Perhaps the method takes an argument of type x (not a 
class parameter), but to call itself, it needs to be able to take types x, T x, 
T (T x), etc. That additional polymorphism can be introduced in the instance 
signature. The alternative is to introduce a helper function with extra 
polymorphism.

On Tue, Aug 10, 2021, 5:15 AM Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
AntC,

I think you see why the instance sig must be at least as polymorphic than the 
instantiated signature from the class - because that's what the client is going 
to expect.  We are building a record of functions, and they must conform to the 
class signature.

I agree with David's (1) and (2) reasons, but not with (3) or (4), neither of 
which I quite understand.

There is no compelling reason to make the instance signature more polymorphic - 
that is, doing so does not increase expressiveness.  But it might make a 
briefer, more comprehensible type for the reader.  The only alternative would 
be to insist that the two types are the same, a completely redundant test, but 
one you might conceivably want on stylistic grounds.

All in all, no big deal.  Instance signature are a convenience, never a 
necessity.

If you would like to offer a patch for the user manual to explain this better, 
that would be great.

Simon

From: Glasgow-haskell-users 
mailto:glasgow-haskell-users-boun...@haskell.org>>
 On Behalf Of David Feuer
Sent: 08 August 2021 09:37
To: Anthony Clayden 
mailto:anthony.d.clay...@gmail.com>>
Cc: GHC users 
mailto:glasgow-haskell-users@haskell.org>>
Subject: Re: InstanceSigs -- rationale for the "must be more polymorphic than"

To the best of my knowledge, `InstanceSigs` are never strictly necessary. They 
can, however, be useful for at least four purposes:

1. To provide a compiler-checked reminder of the type.
2. To bind type variables with `ScopedTypeVariables`.
3. To generalize the type so you can use polymorphic recursion.
4. To enhance parametricitry/polymorphism for internal documentation purposes.

The third reason is probably the main technical one to allow a more general 
signature, but the fourth is likely helpful too.

On Sun, Aug 8, 2021, 3:04 AM Anthony Clayden 
mailto:anthony.d.clay...@gmail.com>> wrote:
I can't help but feel InstanceSigs are either superfluous or upside-down. It's 
this bit in the User Guide:

> The type signature in the instance declaration must be
> more polymorphic than (or the same as) the one in the class declaration,
> instantiated with the instance type.

Usually if you give a signature, it must be _less_ polymorphic (or the same as) 
the type inferred from the term:

>lessPolyPlus :: Integral a => a -> a -> a
>lessPolyPlus x y = x + y

Or

>lessPolyPlus (x :: a) y = x + y :: Integral a => a

The examples in the User Guide aren't helping: you could just drop the 
InstanceSigs, and all is well-typed. (Even the example alleging to use 
-XScopedTypeVariables in a where sub-decl: you could just put random `xs :: 
[b]` without scoping `b`.)

Dropping the Sigs altogether works because the type from the class decl, 
suitably instantiated, is less polymorphic than inferred from the term. IOW the 
suitably instantiated type restricts what would otherwise be inferred. 
Situation normal.

I suppose it might be helpful to give an explicit InstanceSig as 'belt and 
braces' for the instantiated -- possibly because the instantiation is hard to 
figure out; possibly because you want to use -XScopedTypeVariables within a 
where-bound sub-decl, as an extra piece of string.

I can see you mustn't make the InstanceSig _less_ polymorphic than the suitably 
instantiated.

But the docos don't give any example where it's essential to provide an 
InstanceSig _and_  make it strictly more polymorphic. Here all the sigs and 
annotations are just superfluous:

>maxPolyPlus :: Num a => a -> a -> a
>maxPolyPlus = (+)
>
>class C a  where foo :: a -> T a
>instance Integral a => C a  where
>  foo :: Num a => a -> T a
>  foo (x :: a) = MkT (maxPolyPlus x x :: Num a => a)

Is there a persuasive example (to put in the User Guide)?

AntC

___
Glasgow-haskell-users mailing list
Glasgow-haskell-use

RE: -dinline-check for symbolic names?

[Simon Peyton Jones via Glasgow-haskell-users]

It's hard to tell what is happening without a repro case. Can you share one?

You suggested that it might have something to do with using an operator.   Does 
the same thing happen if you replace the operator with an alpha-numeric name?

Simon

| -Original Message-
| From: Glasgow-haskell-users 
| On Behalf Of Michael Sperber
| Sent: 06 August 2021 13:44
| To: glasgow-haskell-users@haskell.org
| Subject: Re: -dinline-check for symbolic names?
| 
| [You don't often get email from sper...@deinprogramm.de. Learn why this
| is important at http://aka.ms/LearnAboutSenderIdentification.]
| 
| On Fri, Aug 06 2021, Michael Sperber  wrote:
| 
| > On Wed, Aug 04 2021, Carter Schonwald 
| wrote:
| >
| >> I'm not sure about the pragma debugging, but are you using it in
| >> point free style? Cause I'm that case it may not be inclined because
| >> it's not being fully applied on the left hand side?
| >
| > Good point, but I checked, and it's fully applied. :-(
| 
| Another note: Once I change the INLINE to INLINE [0], everything works:
| (&&&) gets inlined, and -dinline-check works.  Explanation welcome ...
| 
| --
| Regards,
| Mike
| 
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.has
| kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-
| users&data=04%7C01%7Csimonpj%40microsoft.com%7C7b8c76634e3c4ce86a7008
| d958d801ac%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63763850704993823
| 2%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
| haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DZHraN9nVbZMWxmekmYP2sAqRBh1qNbVWUlo
| JQdKnkc%3D&reserved=0
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: InstanceSigs -- rationale for the "must be more polymorphic than"

[Simon Peyton Jones via Glasgow-haskell-users]

AntC,

I think you see why the instance sig must be at least as polymorphic than the 
instantiated signature from the class - because that's what the client is going 
to expect.  We are building a record of functions, and they must conform to the 
class signature.

I agree with David's (1) and (2) reasons, but not with (3) or (4), neither of 
which I quite understand.

There is no compelling reason to make the instance signature more polymorphic - 
that is, doing so does not increase expressiveness.  But it might make a 
briefer, more comprehensible type for the reader.  The only alternative would 
be to insist that the two types are the same, a completely redundant test, but 
one you might conceivably want on stylistic grounds.

All in all, no big deal.  Instance signature are a convenience, never a 
necessity.

If you would like to offer a patch for the user manual to explain this better, 
that would be great.

Simon

From: Glasgow-haskell-users  On 
Behalf Of David Feuer
Sent: 08 August 2021 09:37
To: Anthony Clayden 
Cc: GHC users 
Subject: Re: InstanceSigs -- rationale for the "must be more polymorphic than"

To the best of my knowledge, `InstanceSigs` are never strictly necessary. They 
can, however, be useful for at least four purposes:

1. To provide a compiler-checked reminder of the type.
2. To bind type variables with `ScopedTypeVariables`.
3. To generalize the type so you can use polymorphic recursion.
4. To enhance parametricitry/polymorphism for internal documentation purposes.

The third reason is probably the main technical one to allow a more general 
signature, but the fourth is likely helpful too.

On Sun, Aug 8, 2021, 3:04 AM Anthony Clayden 
mailto:anthony.d.clay...@gmail.com>> wrote:
I can't help but feel InstanceSigs are either superfluous or upside-down. It's 
this bit in the User Guide:

> The type signature in the instance declaration must be
> more polymorphic than (or the same as) the one in the class declaration,
> instantiated with the instance type.

Usually if you give a signature, it must be _less_ polymorphic (or the same as) 
the type inferred from the term:

>lessPolyPlus :: Integral a => a -> a -> a
>lessPolyPlus x y = x + y

Or

>lessPolyPlus (x :: a) y = x + y :: Integral a => a

The examples in the User Guide aren't helping: you could just drop the 
InstanceSigs, and all is well-typed. (Even the example alleging to use 
-XScopedTypeVariables in a where sub-decl: you could just put random `xs :: 
[b]` without scoping `b`.)

Dropping the Sigs altogether works because the type from the class decl, 
suitably instantiated, is less polymorphic than inferred from the term. IOW the 
suitably instantiated type restricts what would otherwise be inferred. 
Situation normal.

I suppose it might be helpful to give an explicit InstanceSig as 'belt and 
braces' for the instantiated -- possibly because the instantiation is hard to 
figure out; possibly because you want to use -XScopedTypeVariables within a 
where-bound sub-decl, as an extra piece of string.

I can see you mustn't make the InstanceSig _less_ polymorphic than the suitably 
instantiated.

But the docos don't give any example where it's essential to provide an 
InstanceSig _and_  make it strictly more polymorphic. Here all the sigs and 
annotations are just superfluous:

>maxPolyPlus :: Num a => a -> a -> a
>maxPolyPlus = (+)
>
>class C a  where foo :: a -> T a
>instance Integral a => C a  where
>  foo :: Num a => a -> T a
>  foo (x :: a) = MkT (maxPolyPlus x x :: Num a => a)

Is there a persuasive example (to put in the User Guide)?

AntC

___
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: Avoiding construction of dead dictionaries

[Simon Peyton Jones via Glasgow-haskell-users]

Hi Mike

|  The right-hand argument of <+ leads to a dictionary construction that is a
|  proof of a certain property, but the dictionary itself ends up being dead,
|  like so:
|  
|case $w$dOpCon_r2kGJ ...
|of
|{ (# ww1_s27L3 #) -> ... }
| ^
| never used

GHC needs to figure out that $w$dOpCon_r2kGJ always terminates, without 
throwing an exception etc.  That can't be too hard, and Sebastian Graf has 
thought about it quite a bit.

Could you offer a small repro case, with a pointer to evidence that it matters 
in practice, and open a ticket?

Thanks

Simon

|  -Original Message-
|  From: Glasgow-haskell-users  On
|  Behalf Of Michael Sperber
|  Sent: 06 August 2021 14:06
|  To: glasgow-haskell-users@haskell.org
|  Subject: Avoiding construction of dead dictionaries
|  
|  [You don't often get email from sper...@deinprogramm.de. Learn why this is
|  important at http://aka.ms/LearnAboutSenderIdentification.]
|  
|  I have another optimization problem.  ConCat includes this definition:
|  
|  (<+) :: Con a => (Con b => r) -> (a |- b) -> r r <+ Entail (Sub Dict) = r
|  
|  The right-hand argument of <+ leads to a dictionary construction that is a
|  proof of a certain property, but the dictionary itself ends up being dead,
|  like so:
|  
|case $w$dOpCon_r2kGJ ...
|of
|{ (# ww1_s27L3 #) -> ... }
| ^
| never used
|  
|  Yet, ghc (8.10.4) never elides this code.  (I'm naively assuming because of
|  the unboxed tuple, but actually have no clue.)
|  
|  Is there any chance of convincing ghc of erasing the dictionary
|  construction?
|  
|  Help would be much appreciated!
|  
|  --
|  Regards,
|  Mike
|  
|  ___
|  Glasgow-haskell-users mailing list
|  Glasgow-haskell-users@haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel
|  l.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-
|  users&data=04%7C01%7Csimonpj%40microsoft.com%7C301c6f15cc1142fc645908d95
|  8dc725a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637638526127543532%7CUn
|  known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
|  VCI6Mn0%3D%7C2000&sdata=fh2YiJ5NuDMPzpzzxsAL0MyceMFH0MuveNgvTo7ZNow%3D&a
|  mp;reserved=0
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: Avoiding construction of dead dictionaries

[Simon Peyton Jones via Glasgow-haskell-users]

> . So apparently it is possible for a dictionary to be bottom somehow.
That should not happen.

Except in the case of single-method dictionaries like
class C a where op ::  a -> a
In these cases the "dictionary" is represented by a newtype, like this
newtype C a = MkC (a->a)

Then you could say
instance C Int where
 op = bottom

and now a (C Int) dictionary is simply bottom.

It would be easy to change this decision, and use a data constructor even for 
single-method classes.  Some programs would become slightly less efficient, but 
things would be a bit more uniform.  If there was a real advantage to doing 
this, it'd definitely be worth measuring the perf cost (if any).

Simon

From: Glasgow-haskell-users  On 
Behalf Of Brandon Allbery
Sent: 09 August 2021 16:32
To: Tom Smeding 
Cc: GHC users ; sper...@deinprogramm.de
Subject: Re: Avoiding construction of dead dictionaries

We haven't figured out what they did, but the other day we had someone in 
#haskell with an infinite loop evaluating a dictionary. So apparently it is 
possible for a dictionary to be bottom somehow.

On Mon, Aug 9, 2021 at 11:27 AM Tom Smeding 
mailto:x...@tomsmeding.com>> wrote:
Hi Mike,


> But wouldn't that imply that ghc can build dictionary-construction code

> that evaluates to bottom? Can that happen?


I assume no, but here the dictionary is embedded as a field in the GADT, right? 
So if the data value is bottom, there is not even a dictionary to be found, let 
alone not-bottom.


This assumes that the Dict in `Entail (Sub Dict)` is a GADT like


Dict :: Con b => Dict something


where the Con dictionary is contained in the GADT. Remember that in Core, 
dictionaries are values, and there is no difference between => and ->.


- Tom



 Original Message 

On 9 Aug 2021, 15:24, Michael Sperber < 
sper...@deinprogramm.de> wrote:


Thanks for thinking about this one!

On Fri, Aug 06 2021, Tom Smeding 
mailto:x...@tomsmeding.com>> wrote:

> Would it not be unsound for ghc to elide dictionary construction here?

> After all, the right-hand side might actually be a bottom

> (e.g. undefined) at run-time, in which case the pattern match cannot

> succeed according to the semantics of Haskell.

But wouldn't that imply that ghc can build dictionary-construction code

that evaluates to bottom? Can that happen?

> I suspect that if you make the pattern match lazy (i.e. ~(Entail (Sub

> Dict))) or ignore the argument altogether (i.e. _), dictionary

> construction will be elided.

Thanks for the hint! ghc gives me this unfortunately, implying that it

agreed with your first comment:

src/ConCat/Category.hs:190:29: error:

* Could not deduce: Con b arising from a use of 'r'

from the context: Con a

bound by the type signature for:

(<+) :: forall a b r. Con a => (Con b => r) -> (a |- b) -> r

at src/ConCat/Category.hs:189:1-46

* In the expression: r

In an equation for '<+': r <+ ~(Entail (Sub Dict)) = r

* Relevant bindings include

r :: Con b => r (bound at src/ConCat/Category.hs:190:1)

(<+) :: (Con b => r) -> (a |- b) -> r

(bound at src/ConCat/Category.hs:190:3)

|

190 | r <+ ~(Entail (Sub Dict)) = r

| ^

Other ideas welcome!

--

Regards,

Mike

___

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


--
brandon s allbery kf8nh
allber...@gmail.com
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: exhausted simplifier ticks and hs-boot files

[Simon Peyton Jones via Glasgow-haskell-users]

Ganesh

It's an old bug that has somehow reappeared.
I opened https://gitlab.haskell.org/ghc/ghc/issues/17140

But it seems OK in HEAD, and hence probably in GHC 8.8.  Can you try?

Maybe put further comments on the issue tracker, rather than here.

thanks

Simon

| -Original Message-
| From: Glasgow-haskell-users  On
| Behalf Of Ganesh Sittampalam
| Sent: 05 August 2019 14:02
| To: glasgow-haskell-users@haskell.org
| Subject: exhausted simplifier ticks and hs-boot files
| 
| Hi,
| 
| The code below (also attached - unzip and run go.sh) triggers the GHC
| panic "Simplifier ticks exhausted", and I'm unsure whether I should view
| it as an instance of the known infelicity in the inliner
| (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html
| #bugs-ghc)
| 
| My code does have a recursive datatype, but the recursion isn't
| contravariant, which is the case described in "Secrets of the GHC inliner"
| (https://www.microsoft.com/en-us/research/wp-
| content/uploads/2002/07/inline.pdf,
| section 4).
| 
| It's cut down from some real code where I have a mutually recursive
| datatype that I want to define across two modules for code structuring
| reasons, meaning I need a .hs-boot file. I haven't been able to reproduce
| it without the .hs-boot file - if I put everything in one module it stops
| happening.
| 
| I've tried with a range of GHC versions from 8.2.x to an early version of
| 8.8. It happens with -O1 and not -O0, but I haven't managed to find a
| specific optimisation that triggers it.
| 
| Is this just an instance of the known problem in a different guise, or is
| it something different and worth a bug report?
| 
| Cheers,
| 
| Ganesh
| 
| T2.hs-boot
| ---
| module T2 where
| 
| data T2
| 
| mapP_T2 :: (Int -> Int) -> T2 -> T2
| 
| T1.hs
| -
| module T1 where
| 
| import {-# SOURCE #-} T2
| 
| data T1 = T1 T2
| 
| mapP_T1 :: (Int -> Int) -> T1 -> T1
| mapP_T1 _ (T1 xs) = T1 (mapP_T2 id xs)
| 
| T2.hs
| -
| 
| module T2 where
| 
| import T1
| 
| data T2 = T2 T1
| 
| mapP_T2 :: (Int -> Int) -> T2 -> T2
| mapP_T2 f (T2 t) = T2 (mapP_T1 f t)
| 
| go :: T1 -> T1
| go = mapP_T1 id
| 
| GHC output
| --
| $ ghc --make T2.hs -O1 -fsimpl-tick-factor=1000 -ddump-simpl-stats) [...]
| ghc.exe: panic! (the 'impossible' happened)
|   (GHC version 8.2.2 for x86_64-unknown-mingw32):
| Simplifier ticks exhausted
|   When trying UnfoldingDone mapP_T2
|   To increase the limit, use -fsimpl-tick-factor=N (default 100)
|   If you need to do this, let GHC HQ know, and what factor you needed
|   Total ticks: 61203
| 
|   24481 PreInlineUnconditionally
| 6121 ds_i17h
| 6120 f_a16p
| 6120 ds_d17d
| 6120 ds1_i17i
|   12241 UnfoldingDone
| 6121 mapP_T1
| 6120 mapP_T2
|   24481 BetaReduction
| 6121 ds_i17h
| 6120 f_a16p
| 6120 ds_d17d
| 6120 ds1_i17i
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: Equality constraints (~): type-theory behind them

[Simon Peyton Jones via Glasgow-haskell-users]

I'd far rather see GHC's implementation of FunDeps made more coherent (and 
learning from Hugs) than squeezing it into the straitjacket of System FC and 
thereby lose expressivity.

To call System FC a straitjacket is to suggest that there is a straightforward 
alternative that would serve the purpose better – let’s take off the 
straitjacket!  I’m all for that, but then we do need to describe what the new 
alternative is, at a comparable level of precision.

For better or worse, GHC uses FC as a statically-typed intermediate language.   
Vanishingly few compilers do this; almost all use an untyped intermediate 
language.  With an untyped IR, all you need do is typecheck the source program, 
and then you are done with typechecking --- provided that all the subsequent 
transformations and optimisations are sound.

But with a statically typed IR, we have to ensure that every transformation 
produces a program that is itself well-typed; and that in turn pretty much 
rules out complicated inference algorithms, because they are fragile to 
transformation.  Instead, GHC uses a complicated inference algorithm on the 
(implicitly typed) source program, but under the straitjacket restriction that 
the type inference algorithm must also translate the program into an 
explicitly-typed IR.

This is a choice that GHC makes.  It’s a choice that I love, and one that makes 
GHC distinctive.  But I accept that it comes with a cost.

There may be an IR based on fundeps, or CHRs or something, that has similar 
properties to FC.   It would be a great research goal to work on such a thing.

That said,  there may be aspects of GHC’s implementation fundeps that are 
unsatisfactory or argualbly just plain wrong, and which could be fixed and 
still translate into FC.   If anyone would like to work on that, I’d be happy 
to help explain how the current machinery works.

Simon

From: Glasgow-haskell-users  On 
Behalf Of Anthony Clayden
Sent: 25 March 2019 11:50
To: GHC Users List ; Tom Schrijvers 

Subject: Re: Equality constraints (~): type-theory behind them


> On Mon, Dec 10, 2018 at 8:36:42 AM Tom Schrijvers wrote:
> Maybe our Haskell'17 paper about Elaboration on Functional Dependencies sheds 
> some more light on your problem:

Thanks Tom, I've also been working through the 2011 expanded version of 'System 
F with Type Equality Coercions' that Adam suggested.

I'm finding your 2017 paper's proposals not up to the job, because it doesn't 
consider FunDeps for Overlapping Instances; and unnecessary because the 
examples it's addressing can be fixed purely using FunDeps, with their 
semantics per the 2006 'via CHRs' paper. The chief problems with using FunDeps 
in GHC code is GHC doesn't follow that semantics; neither does it follow any 
other well-principled/documented semantics.You can get it to accept a bunch of 
instances then find that taken together they're not consistent and confluent, 
in the sense of the 'via CHRs' paper.

Specifically, re the 2017's paper Challenge 1: Enforcing (essentially Trac 
#10675). That set of instances in the example is not valid by the 'via CHRs' 
rules, and should be rejected. Hugs indeed rejects that code. GHC accepts it 
and #10675 shows what sort of incoherence can result. I'm not seeing we need to 
translate to Type Families/System FC to explain it.

Re Challenge 2: Elaborating (which is Trac #9627 that gives the main example 
for the paper). We can fix that code with an extra `~` constraint:


class C a b | a -> b

instance C Int Bool



f :: (C Int b, b ~ Bool) => b -> Bool

f x  = x

(Or in Hugs with a `TypeCast` instead of the `~`.)



Is that extra constraint onerous? The signature already has `Bool` hard-coded 
as the return type, so I don't see it's any more onerous.

Or put that signature as

f :: (C Int b) => b -> b

Which also has the effect `b` must be `Bool`.



I'd far rather see GHC's implementation of FunDeps made more coherent (and 
learning from Hugs) than squeezing it into the straitjacket of System FC and 
thereby lose expressivity.



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

Guidelines for respectful communication

[Simon Peyton Jones via Glasgow-haskell-users]

Friends
As many of you will know, I have been concerned for several years about the 
standards of discourse in the Haskell community.  I think things have improved 
since the period that drove me to write my Respect 
email, 
but it's far from secure.
We discussed this at a meeting of the GHC Steering 
Committee at ICFP in September, 
and many of us have had related discussions since.  Arising out of that 
conversation, the GHC Steering Committee has decided to adopt these
  Guidelines for respectful 
communication

We are not trying to impose these guidelines on members of the Haskell 
community generally. Rather, we are adopting them for ourselves, as a signal 
that we seek high standards of discourse in the Haskell community, and are 
willing to publicly hold ourselves to that standard, in the hope that others 
may choose to follow suit.
We are calling them "guidelines for respectful communication" rather than a 
"code of conduct", because we want to encourage good communication, rather than 
focus on bad behaviour.  Richard Stallman's recent 
post about the new GNU Kind Communication 
Guidelines expresses the 
same idea.
Meanwhile, the Stack community is taking a similar 
approach.
Our guidelines are not set in stone; you can comment 
here.
   Perhaps they can evolve so that other Haskell committees (or even 
individuals) feel able to adopt them.
The Haskell community is such a rich collection of intelligent, passionate, and 
committed people. Thank you -- I love you all!
Simon



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

Summit on Advances in Programming Languages 2019

[Simon Peyton Jones via Glasgow-haskell-users]

Haskellers
The Summit oN Advances in Programming 
Languages (SNAPL) is a biennial venue for 
discussions about programming languages. SNAPL focuses on experience-based 
insight, innovation, and visionary ideas spanning from foundations to 
applications of programming languages. SNAPL welcome perspectives from both 
industry and academia.
Ras Bodik and Shriram Krishnamurthi are looking for community input in where 
and when to hold SNAPL 2019, and how long it should be.
Here is their survey.  Do consider 
making your views known to them.
Simon


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

RE: Natural number comparisons with evidence

[Simon Peyton Jones via Glasgow-haskell-users]

I see this in GHC.TypeNats

sameNat :: (KnownNat a, KnownNat b) =>

   Proxy a -> Proxy b -> Maybe (a :~: b)

sameNat x y

  | natVal x == natVal y = Just (unsafeCoerce Refl)

  | otherwise= Nothing

The unsafeCoerce says that sameNat is part of the trusted code base.  And 
indeed, it’s only because SNat is a private newtype (i.e its data constructor 
is private to GHC.TypeNats) that you can’t bogusly say(SNat 7 :: SNat 8)

You want exactly the same thing, but for a comparison oriented data CompareEv, 
rather than its equality counterpart :~:.   So the same approach seems 
legitimate.

I always want code with unsafeCoerce to be clear about (a) why it’s necessary 
and (b) why it’s sound.

Simon


From: Glasgow-haskell-users  On 
Behalf Of Conal Elliott
Sent: 24 May 2018 00:39
To: glasgow-haskell-users@haskell.org
Subject: Natural number comparisons with evidence

When programming with GHC's type-level natural numbers and `KnownNat` 
constraints, how can one construct *evidence* of the result of comparisons to 
be used in further computations? For instance, we might define a type for 
augmenting the results of `compare` with evidence:

> data CompareEv u v
>   = (u < v) => CompareLT
>   | (u ~ v) => CompareEQ
>   | (u > v) => CompareGT

Then I'd like to define a comparison operation (to be used with 
`AllowAmbiguousTypes` and `TypeApplications`, alternatively taking proxy 
arguments):

> compareEv :: (KnownNat m, KnownNat n) => CompareEv u v

With `compareEv`, we can bring evidence into scope in `case` expressions.

I don't know how to implement `compareEv`. The following attempt fails to 
type-check, since `compare` doesn't produce evidence (which is the motivation 
for `compareEv` over `compare`):

> compareEv = case natVal (Proxy @ u) `compare` natVal (Proxy @ v) of
>   LT -> CompareLT
>   EQ -> CompareEQ
>   GT -> CompareGT

Can `compareEv` be implemented in GHC Haskell? Is there already an 
implementation of something similar? Any other advice?

Thanks,  -- Conal

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

RE: Open up the issues tracker on ghc-proposals

[Simon Peyton Jones via Glasgow-haskell-users]

I can volunteer to at least scrape together all the objections to 
ScopedTypeVariables as currently. It's not yet a proposal, so not on github. 
Start a wiki page? A cafe thread? (It'll get lost.) A ghc-users thread? (It'll 
get ignored.)

That’s a fair question.  We have lots of forums, but your point is that certain 
sorts of discussions never get going with the right audience – you especially 
point to “confused beginners”.

I don’t know how to engage that audience effectively, and by definition I’m the 
wrong person even to have a well-informed view.   It’s quite a challenge 
because beginners tend not to be vocal, and yet they are a crucial set of 
Haskell users.  Every Haskell user started as a beginner.

The title of this thread, “Open up the issues tracker on ghc-proposals”, 
identifies a solution rather than a problem.  Perhaps a constructive place to 
start would be to articulate the challenge directly, in a new thread, and 
invite input from others about whether it’s a problem they encounter, and what 
possible solutions might be?

Thanks!

Simon

From: Glasgow-haskell-users  On 
Behalf Of Anthony Clayden
Sent: 03 May 2018 00:17
To: GHC users 
Cc: Joachim Breitner 
Subject: Re: Open up the issues tracker on ghc-proposals

On Th, 3 May 2018 at 13:53 UTC, Joachim Breitner wrote:
…

> hmm, some of that sounds like it would be better suited for haskell-cafe, 
> StackOverflow, ...

My point about "sometimes it's more of a niggle" was aimed at exactly your 
(Joachim's) series of proposals 'Resurrect Pattern Signatures'. The motivation 
is it helps "confused beginners". But those beginners won't be providing 
feedback on github. Instead you've got feedback from experienced users who've 
all said they see no point in the proposal. So the discussion has gone round 
and round and spun off other proposals. That whole series of discussions would 
be better happening somewhere else: where?

David's quite correct
>> Haskell-cafe might work, but it's a bit tricky to pull up all the language 
>> extension ideas discussed there.

My impression is not many people who could help refine a pre-proposal ever take 
part in the cafe.

Stackoverflow likewise. (I did raise a 'how do I do this?' type question there. 
It was David who responded, thank you. But I ended up answering it myself; and 
it turned out there was already a proposal on the slate.)

>> My limited experience with glasgow-haskell-users is that it's where threads 
>> go to die.

(I did try to continue one of David's threads there a few months ago.) But yes, 
my experience too. And that's sad because it's a wasted resource. I'm grateful 
to Simon for noticing this thread; but most topics I've raised on ghc-users 
have gone nowhere. So then I've tried pursuing them by poaching on Trac or 
github -- which is an abuse, I know.

> Most vague ideas get better when the proposer is nudged to sit down and write 
> it up properly! (And some get dropped in the process, which is also good :-)).

Yes exactly what I'm trying to get to happen. How/where?

Here's a specific example: there's talk of baking ScopedTypeVariables into the 
H2020 standard. There's also people unhappy with ScopedTypeVariables as 
currently (I'm one, but I don't know if my reservations are the same as 
others'). If we don't have an alternative proposal (and preferably an 
experimental extension) by 2020, the committee can only go with the as 
currently fait accompli or continue the H2010 status quo.

I can volunteer to at least scrape together all the objections to 
ScopedTypeVariables as currently. It's not yet a proposal, so not on github. 
Start a wiki page? A cafe thread? (It'll get lost.) A ghc-users thread? (It'll 
get ignored.)


AntC


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

RE: Open up the issues tracker on ghc-proposals

[Simon Peyton Jones via Glasgow-haskell-users]

|  > Sometimes, a language extension idea could benefit from
|  some community discussion before it's ready for a formal proposal.
|  
|  Can I point out it's not only ghc developers who make proposals. I'd
|  rather you post this idea more widely.

The Right Thing is surely for the main GHC proposals pave
https://github.com/ghc-proposals/ghc-proposals
to describe how you can up a "pre-proposal".  That is, document
the entire process in one, easy to find, place.

Mind you, I'm unclear about the distinction between a pre-proposal
and a proposal.  Both are drafts that invite community discussion,
prior to submitting to the committee for decision.

Simon

|  -Original Message-
|  From: Glasgow-haskell-users  On Behalf Of Anthony Clayden
|  Sent: 02 May 2018 02:34
|  To: glasgow-haskell-users@haskell.org; ghc-d...@haskell.org
|  Subject: Re: Open up the issues tracker on ghc-proposals
|  
|  > On May 1, 2018, at 2:24 PM, David Feuer  wrote:
|  >
|  > Sometimes, a language extension idea could benefit from
|  some community discussion before it's ready for a formal proposal.
|  
|  Can I point out it's not only ghc developers who make proposals. I'd
|  rather you post this idea more widely.
|  
|  As a datapoint, I found ghc-users and the café just fine for those
|  discussions.
|  Ghc-users seems to have very low traffic/is rather wasted currently.
|  And I believe a lot of people pre-discuss on reddit.
|  For ideas that have been on the back burner for a long time, there's
|  often wiki pages. (For example re Quantified
|  Constraints.)
|  
|  > I'd like to propose that we open up the GitHub issues
|  tracker for ghc-proposals to serve as a place to discuss pre-proposal
|  ideas. Once those discussions converge on one or a few specific plans,
|  someone can write a proper proposal.
|  
|  I'm not against that. There gets to be a lot of cruft on some
|  discussions about proposals, so I'd expect we could archive it all
|  once a proposal is more formalised.
|  
|  AntC
|  
|  ___
|  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: How to highlighting subexpressions in dumped core?

[Simon Peyton Jones via Glasgow-haskell-users]

I'm not keen on adding more Tick complexity -- it's a bit out of hand already, 
and all transformations must "do the right thing".

AnnExpr adds an annotation at every node.  You could, I guess use that to 
annotate -- but then you'd need a pretty printer for it so you'd end up with 
duplication.

Worth looking at #8809 and related tickets

S

| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Joachim Breitner
| Sent: 06 March 2018 15:27
| To: GHC users 
| Subject: How to highlighting subexpressions in dumped core?
| 
| Hi,
| 
| one of my plugins dumps core output to the user, and this core output
| contains “interesting subexpressions”. I would like to highlight them
| (for example, with `bold :: SDoc -> SDoc`).
| 
| As far as I can see, I have these options:
| 
|  * I copy all, or most of PprCore, and extend ppr_expr to look for the
|subexpressions that I care about.
| 
|Obviously not nice, because of a code copy.
| 
|  * I extend GHC to support that. One way would be to add a new
|constructor to `data Tickish id = … | Highlight` so that
|I can wrap the interesting subexpressions in
|`Tick Highlight e`.
| 
|That’s a bit better, and could even be useful in GHC (e.g. a linter
|error could highlight the lint error location), but it’d mean
|waiting for new compiler versions until I can make use of that,
|and it is still limited to subexpressions – highlighting a binder
|would require yet another support.
| 
|  * Could we extend SDoc with an operation
| 
|   highlightIn :: SDoc -> SDoc -> SDoc
| 
|or
| 
|   highlightIn :: Doc -> Doc -> Doc
| 
|where `highlightIn doc1 doc2` is like doc2, but any subdocument that
|is “ismorphic to doc1” (for whatever that means) gets highlighted?
| 
| 
| Are there other options that I might not see right now?
| 
| 
| 
| Cheers,
| Joachim
| 
| --
| Joachim Breitner
|   m...@joachim-breitner.de
| 
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach
| im-
| breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cd3680548aafa49c82
| 7e708d58376c5e7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636559468531
| 359492%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
| I6Ik1haWwifQ%3D%3D%7C-
| 2&sdata=VodWxNvTtF4Asflj%2FeC7%2FbQy0FExq2zq53hvtWoF98s%3D&reserved=0
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: Why is EvTerm limited?

[Simon Peyton Jones via Glasgow-haskell-users]

|  What would break if we had
|  
|   | EvExpr CoreExpr
|  
|  as an additional constructor there?

This has come up before.  I think that'd be a solid win. 

In fact, eliminate all the existing evidence constructors with "smart 
constructors" that produce an EvExpr.  That'd mean moving stuff from the 
desugarer into these smart constructors, but that's ok.

I /think/ I didn't do that initially only because there were very few forms and 
it mean that there was no CoreExpr stuff in the type checker. But as we add 
more forms that decision looks and less good.

You'd need to add zonkCoreExpr in place of zonkEvTerm.

evVarsOfTerm is called quite a bit; you might want to cache the result in the 
EvExpr constructor.

Make a ticket and execute?

Simon

|  -Original Message-
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  boun...@haskell.org] On Behalf Of Joachim Breitner
|  Sent: 19 January 2018 14:01
|  To: Glasgow-Haskell-Users users 
|  Subject: Why is EvTerm limited?
|  
|  Hi,
|  
|  I had some funky idea where a type checker plugin would have to
|  synthesize code for a custom-solved instances on the fly. But it seems
|  that does not work because EvTerm is less expressive than Core
|  (especially, no lambdas):
|  https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloa
|  ds.haskell.org%2F~ghc%2F8.2.2%2Fdocs%2Fhtml%2Flibraries%2Fghc-
|  8.2.2%2FTcEvidence.html%23t:EvTerm&data=02%7C01%7Csimonpj%40microsoft.
|  com%7C513ff7ae83914913225008d55f452dec%7C72f988bf86f141af91ab2d7cd011d
|  b47%7C1%7C0%7C636519673089385423&sdata=kFkUugVn02Nfu4QXJ6dkVwtx8KWFrTM
|  fWcVEiwf6KyI%3D&reserved=0
|  
|  What would break if we had
|  
|   | EvExpr CoreExpr
|  
|  as an additional constructor there?
|  
|  Cheers,
|  Joachim
|  
|  --
|  Joachim “nomeata” Breitner
|m...@joachim-breitner.de
|  
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C513ff7ae839149
|  13225008d55f452dec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636519
|  673089385423&sdata=Vh4BvbeEVUBIntKcf3XEseOzwUTx2RHPuANTY328dpM%3D&rese
|  rved=0
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: GHC rewrite rule type-checking failure

[Simon Peyton Jones via Glasgow-haskell-users]

*   Is it feasible for GHC to combine the constraints needed LHS and RHS to 
form an applicability condition?
I don’t think so.

Remember that a rewrite rule literally rewrites LHS to RHS.  It does not 
conjure up any new dictionaries out of thin air.  In your example, (D k b) is 
needed in the result of the rewrite.  Where can it come from?  Only from 
something matched on the left.

So GHC treats any dictionaries matched on the left as “givens” and tries to 
solve the ones matched on the left.  If it fails you get the sort of error you 
see.

One way to see this is to write out the rewrite rule you want, complete with 
all its dictionary arguments. Can you do that?

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Conal Elliott
Sent: 03 October 2017 01:03
To: Joachim Breitner 
Cc: glasgow-haskell-users@haskell.org
Subject: Re: GHC rewrite rule type-checking failure

Thanks very much for the reply, Joachim.

Oops! I flubbed the example. I really `morph` to distribute over an application 
of `comp`. New code below (and attached). You're right that I wouldn't want to 
restrict the type of `morph`, since each `morph` *rule* imposes its own 
restrictions.

My questions:

*   Is it feasible for GHC to combine the constraints needed LHS and RHS to 
form an applicability condition?
*   Is there any way I can make the needed constraints explicit in my rewrite 
rules?
*   Are there any other work-arounds that would enable writing such 
RHS-constrained rules?

Regards, -- Conal

``` haskell
{-# OPTIONS_GHC -Wall #-}
-- Demonstrate a type checking failure with rewrite rules

module RuleFail where

class C k where comp' :: k b c -> k a b -> k a c

instance C (->) where comp' = (.)

-- Late-inlining version to enable rewriting.
comp :: C k => k b c -> k a b -> k a c
comp = comp'
{-# INLINE [0] comp #-}

morph :: (a -> b) -> k a b
morph = error "morph: undefined"

{-# RULES "morph/(.)" forall f g. morph (g `comp` f) = morph g `comp` morph f 
#-}

-- • Could not deduce (C k) arising from a use of ‘comp’
--   from the context: C (->)
-- bound by the RULE "morph/(.)"
```


On Mon, Oct 2, 2017 at 3:52 PM, Joachim Breitner 
mailto:m...@joachim-breitner.de>> wrote:
Hi Conal,

The difference is that the LHS of the first rule is mentions the `C k`
constraint (probably unintentionally):

*RuleFail> :t morph comp
morph comp :: C k => k1 (k b c) (k a b -> k a c)

but the LHS of the second rule side does not:

*RuleFail> :t morph addC
morph addC :: Num b => k (b, b) b



A work-around is to add the constraint to `morph`:

morph :: D k b => (a -> b) -> k a b
morph = error "morph: undefined"

but I fear that this work-around is not acceptable to you.

Joachim

Am Montag, den 02.10.2017, 14:25 -0700 schrieb Conal Elliott:
> -- Demonstrate a type checking failure with rewrite rules
>
> module RuleFail where
>
> class C k where comp' :: k b c -> k a b -> k a c
>
> instance C (->) where comp' = (.)
>
> -- Late-inlining version to enable rewriting.
> comp :: C k => k b c -> k a b -> k a c
> comp = comp'
> {-# INLINE [0] comp #-}
>
> morph :: (a -> b) -> k a b
> morph = error "morph: undefined"
>
> {-# RULES "morph/(.)" morph comp = comp #-}  -- Fine



> class D k a where addC' :: k (a,a) a
>
> instance Num a => D (->) a where addC' = uncurry (+)
>
> -- Late-inlining version to enable rewriting.
> addC :: D k a => k (a,a) a
> addC = addC'
> {-# INLINE [0] addC #-}
>
> {-# RULES "morph/addC" morph addC = addC #-}  -- Fail
>
> -- • Could not deduce (D k b) arising from a use of ‘addC’
> --   from the context: D (->) b
>
> -- Why does GHC infer the (C k) constraint for the first rule but not (D k b)
> -- for the second rule?
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
--
Joachim Breitner
  m...@joachim-breitner.de
  
http://www.joachim-breitner.de/

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

RE: Inhibiting the specialiser?

[Simon Peyton Jones via Glasgow-haskell-users]

Did you try -fno-specialise?

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Conal Elliott
Sent: 15 September 2017 02:45
To: glasgow-haskell-users@haskell.org
Subject: Inhibiting the specialiser?

Is there a GHC flag for inhibiting the specializer (but not all optimizations)? 
I'm seeing huge output from the Specialise phase killed at 4GB and growing. The 
output starts as follows:

Result size of Specialise
  = {terms: 29,639, types: 10,921,552, coercions: 4,425,185}

Sounds like a lot to me. Is it?. I get this behavior with -O2 and with -O.

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

RE: Trouble with injective type families

[Simon Peyton Jones via Glasgow-haskell-users]

Functional dependencies and type-family dependencies only induce extra 
"improvement" constraints, not evidence.  For example

class C a b | a -> b where foo :: a -> b
instance C Bool Int where ...

f :: C Bool b => b -> Int
f x = x -- Rejected

Does the fundep on 'b' allow us to deduce (b ~ Int), GADT-like, in the body of 
'f', and hence accept the definition.  No, it does not.  Think of the 
translation into System F. We get

f = /\b \(d :: C Bool b). \(x::b).  x |> ???

What evidence can I used to cast 'x' by to get it from type 'b' to Int?

Rather, fundeps resolve ambiguity.  Consider

g x = foo True + x

The call to 'foo True' gives rise to a "wanted" constraint (C Bool beta), where 
beta is a fresh unification variable.  Then by the fundep we get an 
"improvement" constraint (also "wanted") (beta ~ Int). So we can infer g :: Int 
-> Int.


In your example we have

   x :: forall a b. (T Int ~ b) => a
   x = False

Think of the System F translation:

   x = /\a b. \(d :: T Int ~ b). False |> ??

Again, what evidence can we use to cast False to 'a'.


In short, fundeps and type family dependencies only add extra unification 
constraints, which may help to resolve ambiguous types.  They don’t provide 
evidence.  That's not to say that they couldn't.  But you'd need to extend 
System FC, GHC's core language, to do so.

Simon


| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Wolfgang Jeltsch
| Sent: 05 July 2017 01:21
| To: glasgow-haskell-users@haskell.org
| Subject: Trouble with injective type families
| 
| Hi!
| 
| Injective type families as supported by GHC 8.0.1 do not behave like I
| would expect them to behave from my intuitive understanding.
| 
| Let us consider the following example:
| 
| > {-# LANGUAGE RankNTypes, TypeFamilyDependencies #-}
| >
| > class C a where
| >
| > type T a = b | b -> a
| >
| > instance C Bool where
| >
| > type T Bool = Int
| >
| > type X b = forall a . T a ~ b => a
| >
| > x :: X Int
| > x = False
| 
| I would expect this code to be accepted. However, I get the following
| error message:
| 
| > A.hs:14:5: error:
| > • Could not deduce: a ~ Bool
| >   from the context: T a ~ Int
| > bound by the type signature for:
| >    x :: T a ~ Int => a
| > at A.hs:13:1-10
| >   ‘a’ is a rigid type variable bound by
| > the type signature for:
| >   x :: forall a. T a ~ Int => a
| > at A.hs:11:19
| > • In the expression: False
| >   In an equation for ‘x’: x = False
| > • Relevant bindings include x :: a (bound at A.hs:14:1)
| 
| This is strange, since injectivity should exactly make it possible to
| deduce a ~ Bool from T a ~ Int.
| 
| Another example is this:
| 
| > {-# LANGUAGE GADTs, TypeFamilyDependencies #-}
| >
| > class C a where
| >
| > type T a = b | b -> a
| >
| > instance C Bool where
| >
| > type T Bool = Int
| >
| > data G b where
| >
| > G :: Eq a => a -> G (T a)
| >
| > instance Eq (G b) where
| >
| > G a1 == G a2 = a1 == a2a
| 
| I would also expect this code to be accepted. However, I get the
| following error message:
| 
| > B.hs:17:26: error:
| > • Could not deduce: a1 ~ a
| >   from the context: (b ~ T a, Eq a)
| > bound by a pattern with constructor:
| >    G :: forall a. Eq a => a -> G (T a),
| >  in an equation for ‘==’
| > at B.hs:17:5-8
| >   or from: (b ~ T a1, Eq a1)
| > bound by a pattern with constructor:
| >    G :: forall a. Eq a => a -> G (T a),
| >  in an equation for ‘==’
| > at B.hs:17:13-16
| >   ‘a1’ is a rigid type variable bound by
| > a pattern with constructor: G :: forall a. Eq a => a -> G (T
| > a),
| > in an equation for ‘==’
| > at B.hs:17:13
| >   ‘a’ is a rigid type variable bound by
| > a pattern with constructor: G :: forall a. Eq a => a -> G (T
| > a),
| > in an equation for ‘==’
| > at B.hs:17:5
| > • In the second argument of ‘(==)’, namely ‘a2’
| >   In the expression: a1 == a2
| >   In an equation for ‘==’: (G a1) == (G a2) = a1 == a2
| > • Relevant bindings include
| > a2 :: a1 (bound at B.hs:17:15)
| > a1 :: a (bound at B.hs:17:7)
| 
| If b ~ T a and b ~ T a1, then T a ~ T a1 and subsequently a ~ a1, because
| of injectivity. Unfortunately, GHC does not join the two contexts (b ~ T
| a, Eq a) and (b ~ T a1, Eq a1).
| 
| Are these behaviors really intended, or are these bugs showing up?
| 
| All the best,
| Wolfgang
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-
| users&data=02%7C01%7Csimonpj%40microso

RE: 8.2.1-rc2 upgrade report

[Simon Peyton Jones via Glasgow-haskell-users]

Thanks for the report.

Going from 67G to 56G allocation is a very worthwhile improvement in runtime!  
Hurrah.

However, trebling compile time is very bad.  It is (I think) far from typical: 
generally 8.2 is faster at compiling than 8.0 so you must be hitting something 
weird.  Anything you can do to make a reproducible case would be helpful.  
-dshow-passes shows the size of each intermediate form, which at least 
sometimes shows where the big changes are.

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Alberto Valverde
Sent: 06 June 2017 12:39
To: GHC users 
Subject: 8.2.1-rc2 upgrade report

Hi,

I've finally managed to upgrade all the dependencies of the proprietary app I 
mentioned some days ago in this list and there are good and bad differences 
I've noticed between 8.0.2 that I'd like to share.

The bad
---

* An optimized cold build (-O2)  is about 3 times slower (~53s vs. ~2m55s) and 
consumes more memory (~2Gb vs. ~7Gb) at it's peak.

The good
-

* An un-optimized cold build (-O0) takes about the same time (~21s, phew! :) 
It's maybe even slightly faster with 8.2 (too few and badly taken measurements 
to really know, though)
* The optimized executable is slightly faster and allocates less memory. For 
this app it makes up for the performance regression of the optimized build 
(which is almost always done by CI), IMHO.

I did only a couple of runs and only wrote down [1] the last run results (which 
were similar to the previous results) so take these observations with a grain 
of salt (except maybe the optimized build slowdown, which doesn't have much 
margin for variance to be skewing the results). I also measured the peak memory 
usage by observing "top".

In case gives a clue: The app is a multi-threaded 2D spread simulator which 
deals with many mmapped Storable mutable vectors and has been pretty optimized 
for countless hours (I mean by this that it has (too) many INLINE pragmas. 
Mostly on polymorphic functions to aid in their specialization). I think some 
of this information can be deduced from the results I'm linking at the footer. 
I believe the INLINEs are playing a big part of the slowdown since the slowest 
modules to compile are the "Main" ones which put everything together, along 
with the typical lens-th-heavy "Types" ones.

I'd like to help by producing a reproducible and isolated benchmark or a better 
analysis or ... so someone more knowledgeable than me on GHC internals can 
someday hopefully attack the regression. Any pointers on what would help and 
where can I learn to do it?

Thanks!


[1] 
https://gist.github.com/albertov/46fbb13d940f67a569f9a25c1cb8154c
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: Unused import warning on re-export

[Simon Peyton Jones via Glasgow-haskell-users]

| Is there a reason GHC considers this case an unused import? It seems that
| the use of the import is explicitly stated right within the import
| itself. Should I submit a ticket for this?

Hmm.  I think you are saying that

  module A where
import B as A(f)
g = True

that is equivalent to
   module A( module A ) where ...

which exports all things "x" in scope as "A.x".  So it'll export both f and g.

But GHC will report f as unused, but not g. And that's inconsistent.  Fair 
point.  Yes, file a ticket.  Better still, offer a patch :-).

Simon

| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Yitzchak Gale
| Sent: 10 May 2017 13:56
| To: GHC users 
| Subject: Unused import warning on re-export
| 
| I have a module A with no export list, and a function f which from the
| API point of view should part of the export list of A. But f must be
| defined in module B, not module A, due an import cycle. I added this line
| in module A to re-export f from A:
| 
| import B as A (f)
| 
| This resulted in an unused import warning. That is a problem for us - we
| keep our large code base clean of warnings as a policy.
| 
| Is there a reason GHC considers this case an unused import? It seems that
| the use of the import is explicitly stated right within the import
| itself. Should I submit a ticket for this?
| 
| Thanks,
| Yitz
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-
| users&data=02%7C01%7Csimonpj%40microsoft.com%7C81b06c9737d540a597df08d497
| a413d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636300178355700119&sd
| ata=xHt1FXEF5r4WMaMF3FSW4jFBRlB4OK8DQdcNAxZ7HOc%3D&reserved=0
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: join points and stream fusion?

[Simon Peyton Jones via Glasgow-haskell-users]

Thank you!

|  -Original Message-
|  From: Christian Höner zu Siederdissen [mailto:choe...@bioinf.uni-
|  leipzig.de]
|  Sent: 28 April 2017 00:14
|  To: Simon Peyton Jones 
|  Cc: glasgow-haskell-users@haskell.org
|  Subject: Re: join points and stream fusion?
|  
|  Sorry,
|  
|  with the addendum, I have constructed a very small example:
|  https://ghc.haskell.org/trac/ghc/ticket/13623
|  
|  This is new with ghc 8.2-rc1 and does not show up earlier.
|  
|  Viele Gruesse,
|  Christian
|  
|  * Simon Peyton Jones  [28.04.2017 00:35]:
|  > I'm afraid I don't have enough context to understand this thread.
|  >
|  > Could you offer a concrete example (as small as possible), and
|  explain how to reproduce the problem you are seeing.  Don't forget to
|  give the compiler version you are using, and any libraries you depend
|  on (as few as poss).
|  >
|  > Is this a regression? I.e. did some earlier version of GHC do better
|  on the exact same code?
|  >
|  > Maybe open a Trac ticket.
|  >
|  > Thanks
|  >
|  > Simon
|  >
|  > | -Original Message-
|  > | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  > | boun...@haskell.org] On Behalf Of Christian Höner zu Siederdissen
|  > | Sent: 27 April 2017 23:10
|  > | To: glasgow-haskell-users@haskell.org
|  > | Subject: Re: join points and stream fusion?
|  > |
|  > | As an addendum,
|  > |
|  > | I think what causes this is the following. I have a function
|  > | (|||) xs ys = \lu ij -> xs lu ij Stream.++ ys lu ij xs and ys are
|  > | two stream-generating functions and (Stream.++) concatenates
|  > | streams. In the example I have four streams:
|  > | xs_1 ||| xs_2 ||| xs_3 ||| xs_4
|  > |
|  > | However, here I end up with a join point on (++). Further
|  evidenced
|  > | (?) by the curious occurance of s1uf4 ... (Left (Left (Left
|  ...))).
|  > | Additional calls then are (Left (Left (Right ))) and so on.
|  > |
|  > | It would be really good if (|||) is *not* turned into a join
|  point.
|  > |
|  > | Best,
|  > | Christian
|  > |
|  > | * Christian Höner zu Siederdissen 
|  > | [27.04.2017 23:30]:
|  > | > Dear all,
|  > | >
|  > | > have some of you experienced bad code generation in ghc-8.2-rc1
|  in
|  > | > combination with stream fusion from the vector package?
|  > | >
|  > | > Unfortunately, the problem occurs with ADPfusion code which
|  means
|  > | > no simple example, but I'm asking because of the following core
|  below.
|  > | >
|  > | > In ghc-8.0 I have nice core, here however constructor
|  > | > specialization has not happened, neither with the Left/Right nor
|  with the SPEC.
|  > | >
|  > | > The running time in ghc-8.0 is 2.6 seconds, in rc-1 10.9
|  seconds.
|  > | >
|  > | > Best,
|  > | > Christian
|  > | >
|  > | > joinrec {
|  > | >   $wfoldlM'_loop2_s1uf4
|  > | >   $wfoldlM'_loop2_s1uf4 w_s1ueX ww1_s1uf2 w1_s1ueZ
|  > | > = case w_s1ueX of { __DEFAULT ->
|  > | >   case w1_s1ueZ of {
|  > | > Left sa_au90 ->
|  > | >   case sa_au90 of {
|  > | > Left sa1_XuNq ->
|  > | >   case sa1_XuNq of {
|  > | > Left sa2_XuNe ->
|  > | >   case sa2_XuNe of {
|  > | > SL s2_alTo k_alTp ->
|  > | >   case k_alTp of {
|  > | > __DEFAULT ->
|  > | >   jump $wfoldlM'_loop2_s1uf4
|  > | > SPEC ww1_s1uf2 lvl211_s1IDG;
|  > | > 1# ->
|  > | >   jump $wfoldlM'_loop2_s1uf4
|  > | > SPEC ww1_s1uf2 (Left (Left (Left (SR
|  > | > s2_alTo
|  > | >
|  > | > ___
|  > | > Glasgow-haskell-users mailing list
|  > | > Glasgow-haskell-users@haskell.org
|  > | >
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fma
|  > | > il.h
|  > | > askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-
|  users&
|  > | > data
|  > | >
|  =02%7C01%7Csimonpj%40microsoft.com%7Cd36333a2218f4c513f5a08d48dba1
|  > | > 57d%
|  > | >
|  7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636289277756070800&sd
|  > | > ata=
|  > | > DGsBNjZPuDbpEONyJBOy7BDimCELGHNM1trxjCP5luk%3D&reserved=0
|  > | ___
|  > | Glasgow-haskell-users mailing list
|  > | Glasgow-haskell-users@haskell.org
|  > |
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail
|  > | .hask
|  > | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-
|  > |
|  users&data=02%7C01%7Csimonpj%40microsoft.com%7Cd36333a2218f4c513f5a0
|  > | 8d48d
|  > |
|  ba157d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362892777560708
|  > | 00&sd
|  > | ata=DGsBNjZPuDbpEONyJBOy7BDimCELGHNM1trxjCP5luk%3D&reserved=0
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: join points and stream fusion?

[Simon Peyton Jones via Glasgow-haskell-users]

I'm afraid I don't have enough context to understand this thread.

Could you offer a concrete example (as small as possible), and explain how to 
reproduce the problem you are seeing.  Don't forget to give the compiler 
version you are using, and any libraries you depend on (as few as poss).

Is this a regression? I.e. did some earlier version of GHC do better on the 
exact same code?

Maybe open a Trac ticket.

Thanks

Simon

| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Christian Höner zu Siederdissen
| Sent: 27 April 2017 23:10
| To: glasgow-haskell-users@haskell.org
| Subject: Re: join points and stream fusion?
| 
| As an addendum,
| 
| I think what causes this is the following. I have a function
| (|||) xs ys = \lu ij -> xs lu ij Stream.++ ys lu ij xs and ys are two
| stream-generating functions and (Stream.++) concatenates streams. In the
| example I have four streams:
| xs_1 ||| xs_2 ||| xs_3 ||| xs_4
| 
| However, here I end up with a join point on (++). Further evidenced (?)
| by the curious occurance of s1uf4 ... (Left (Left (Left ...))).
| Additional calls then are (Left (Left (Right ))) and so on.
| 
| It would be really good if (|||) is *not* turned into a join point.
| 
| Best,
| Christian
| 
| * Christian Höner zu Siederdissen 
| [27.04.2017 23:30]:
| > Dear all,
| >
| > have some of you experienced bad code generation in ghc-8.2-rc1 in
| > combination with stream fusion from the vector package?
| >
| > Unfortunately, the problem occurs with ADPfusion code which means no
| > simple example, but I'm asking because of the following core below.
| >
| > In ghc-8.0 I have nice core, here however constructor specialization
| > has not happened, neither with the Left/Right nor with the SPEC.
| >
| > The running time in ghc-8.0 is 2.6 seconds, in rc-1 10.9 seconds.
| >
| > Best,
| > Christian
| >
| > joinrec {
| >   $wfoldlM'_loop2_s1uf4
| >   $wfoldlM'_loop2_s1uf4 w_s1ueX ww1_s1uf2 w1_s1ueZ
| > = case w_s1ueX of { __DEFAULT ->
| >   case w1_s1ueZ of {
| > Left sa_au90 ->
| >   case sa_au90 of {
| > Left sa1_XuNq ->
| >   case sa1_XuNq of {
| > Left sa2_XuNe ->
| >   case sa2_XuNe of {
| > SL s2_alTo k_alTp ->
| >   case k_alTp of {
| > __DEFAULT ->
| >   jump $wfoldlM'_loop2_s1uf4
| > SPEC ww1_s1uf2 lvl211_s1IDG;
| > 1# ->
| >   jump $wfoldlM'_loop2_s1uf4
| > SPEC ww1_s1uf2 (Left (Left (Left (SR
| > s2_alTo
| >
| > ___
| > Glasgow-haskell-users mailing list
| > Glasgow-haskell-users@haskell.org
| > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
| > askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users&data
| > =02%7C01%7Csimonpj%40microsoft.com%7Cd36333a2218f4c513f5a08d48dba157d%
| > 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636289277756070800&sdata=
| > DGsBNjZPuDbpEONyJBOy7BDimCELGHNM1trxjCP5luk%3D&reserved=0
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-
| users&data=02%7C01%7Csimonpj%40microsoft.com%7Cd36333a2218f4c513f5a08d48d
| ba157d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636289277756070800&sd
| ata=DGsBNjZPuDbpEONyJBOy7BDimCELGHNM1trxjCP5luk%3D&reserved=0
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: Why isn't this Overlapping?

[Simon Peyton Jones via Glasgow-haskell-users]

Moreover, as discussed in the user manual 
section,
 GHC doesn’t complain about overlapping instances at the instance decl, but 
rather where the instances are used. That’s why there is no overlap complaint 
here

Simon


From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Iavor Diatchki
Sent: 18 April 2017 01:50
To: anthony_clay...@clear.net.nz
Cc: GHC Users Mailing List 
Subject: Re: Why isn't this Overlapping?

Hello,

these two instances really should be rejected as they violate the FD of the 
class: we can derive `TypeEq a a True` using the first instance and `TypeEq a a 
False` using the second one.  Unfortunately, the check that we are using to 
validate FDs when `UndecidableInstances` is on, is not quite correct (relevant 
tickets are #9210 and #10675 where there are similar examples).

-Iavor



On Sun, Apr 16, 2017 at 12:13 AM, Anthony Clayden 
mailto:anthony_clay...@clear.net.nz>> wrote:
--ghc 7.10 or 8.0.1

{-# LANGUAGE DataKinds, KindSignatures, GADTs,
  MultiParamTypeClasses,
FunctionalDependencies, FlexibleInstances,
  UndecidableInstances,
NoOverlappingInstances   #-}

class TypeEq a a' (b :: Bool) | a a' -> b

instance (b ~ True) => TypeEq a a b
instance (b ~ False) => TypeEq a a' b

Those two instance heads are nearly identical, surely they
overlap?
And for a type-level type equality test, they must be
unifiable.
But GHC doesn't complain.

If I take off the FunDep, then GHC complains.

AFAICT none of those extensions imply Overlaps,
but to be sure I've put NoOverlapping.


AntC
___
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: Accessing the "original" names via GHC API

[Simon Peyton Jones via Glasgow-haskell-users]

The TyCon has a Name (use tyConName to get it).
The Name has a Module and an OccName (use nameModule and nameOccName to get 
them)
The OccName has a string (occNameString)
The Module has a ModuleName and a Package.


All of these will give the “original-name” info, ignoring what’s in scope.

Does that help?

S

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Ranjit Jhala
Sent: 25 January 2017 00:09
To: glasgow-haskell-users@haskell.org
Subject: Accessing the "original" names via GHC API

Hi,

I'm quite vexed trying to do the following. Suppose I have a file:

```
module Foo

import qualified Data.Set as S

baz :: S.Set Int
baz = S.empty
```

My goal is to write a function

   tyconString :: TyCon -> String

(perhaps with extra parameters) such that given the
`TyCon` corresponding to `Set`, I get back the "original"
name `S.Set`, or even `Data.Set.Set`.

Everything I've tried, which is fiddling with different variants of `PprStyle`, 
end up giving me `Data.Set.Base.Set`

Does anyone have a suggestion for how to proceed?

Thanks!

- Ranjit.


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

RE: GHC rewrite rules for class operations & laws

[Simon Peyton Jones via Glasgow-haskell-users]

|  Indeed, we could eliminate several hundred lines of boilerplate in GHC if we
|  could lift this restriction.

Can you be more specific?  Which hundreds of lines?

Do add this info to the ticket when Gorge makes it.  Or just make one!

Simon

|  -Original Message-
|  From: Ben Gamari [mailto:b...@smart-cactus.org]
|  Sent: 29 December 2016 14:50
|  To: Conal Elliott ; George Colpitts
|  
|  Cc: glasgow-haskell-users@haskell.org; Simon Peyton Jones
|  
|  Subject: Re: GHC rewrite rules for class operations & laws
|  
|  On December 28, 2016 7:27:20 PM EST, Conal Elliott  wrote:
|  >Hi, George. Yes, please do add a task, hopefully to serve as a
|  >conversation anchor until the issues and path forward are clearer. From
|  >my perspective, class methods are among the most natural and useful
|  >candidates for rewrite rules, since they tend to have associated laws,
|  >many (but not all) of which are helpful in optimization. The
|  >alternative I know (and am using) is fairly inconvenient: replicating
|  >entire APIs just in order to delay inlining long enough to apply rules.
|  >
|  Indeed, we could eliminate several hundred lines of boilerplate in GHC if we
|  could lift this restriction.
|  
|  Cheers,
|  
|  - Ben
|  

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

RE: GHC rewrite rules for class operations & laws

[Simon Peyton Jones via Glasgow-haskell-users]

Conal

Is it possible to apply GHC rewrite rules to class methods?

Not currently.  See https://ghc.haskell.org/trac/ghc/ticket/11688, esp 
comment:7 which gives links to similar examples.  
https://ghc.haskell.org/trac/ghc/ticket/10528 comment:13  gives more background.

It’d be great if someone wanted to think through all this.

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Conal Elliott
Sent: 17 November 2016 16:40
To: glasgow-haskell-users@haskell.org
Subject: GHC rewrite rules for class operations & laws


Is it possible to apply GHC rewrite rules to class methods? From what I’ve read 
and seen, class methods get eliminated early by automatically-generated rules. 
Is there really no way to postpone such inlining until a later simplifier 
stage? The GHC Users Guide docs say 
no,
 and suggests instead giving a duplicate vocabulary with somewhat awkward names 
for class methods. I’ve not seen this practice in libraries. I gather that we 
cannot therefore use class laws as optimizations in the form of rewrite rules, 
which seems a terrible loss.

In Control.Category and Control.Arrow, I see rules for class laws but also 
header comments saying “The RULES for the methods of class Arrow may never fire 
e.g. compose/arr; see Trac #10528”.

I’d appreciate a reality check about my conclusions as well as any strategies 
for using class laws in optimization.

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

RE: Getting rid of -XImpredicativeTypes

[Simon Peyton Jones via Glasgow-haskell-users]

1) ImpredicativeTypes enables types like `Maybe (forall a. a)`. Do those just 
disappear, or are they also enabled anyway? (I would guess the former.)
Yes, they’d disappear.

2) There was a sketch drawn up around a year ago (I think) aiming to actually 
fix ImpredicativeTypes. I don't recall who was working on it, but I think when 
I mentioned it in the context of something else, you didn't seem to be aware of 
it. I guess it's safe to say that nothing ever came of it, at least inasmuch as 
no one ever showed you their proposal for a properly functioning 
ImpredicativeTypes?
It’s just a swamp.  I have tried multiple times to fix ImpredicativeTypes, and 
failed every time.  Which is not to say that someone shouldn’t try again, with 
new thinking.

Simon

From: Dan Doel [mailto:dan.d...@gmail.com]
Sent: 26 September 2016 00:54
To: Simon Peyton Jones 
Cc: ghc-us...@haskell.org; ghc-d...@haskell.org
Subject: Re: Getting rid of -XImpredicativeTypes

I don't use the extension, because it's more pleasant to use newtypes with 
polymorphic contents. But here are some questions:
1) ImpredicativeTypes enables types like `Maybe (forall a. a)`. Do those just 
disappear, or are they also enabled anyway? (I would guess the former.)
2) There was a sketch drawn up around a year ago (I think) aiming to actually 
fix ImpredicativeTypes. I don't recall who was working on it, but I think when 
I mentioned it in the context of something else, you didn't seem to be aware of 
it. I guess it's safe to say that nothing ever came of it, at least inasmuch as 
no one ever showed you their proposal for a properly functioning 
ImpredicativeTypes?
Anyhow, if it can't be fixed, I think not having the extension is superior to 
its current state. And really, I think even if fixing it were on the roadmap, 
it'd be better to get rid of it until it were actually fixed.
-- Dan

On Sun, Sep 25, 2016 at 2:05 PM, Simon Peyton Jones via ghc-devs 
mailto:ghc-d...@haskell.org>> wrote:
Friends

GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to 
support impredicative polymorphism.  But it is vestigial…. if it works, it’s 
really a fluke.  We don’t really have a systematic story here at all.

I propose, therefore, to remove it entirely.  That is, if you use 
-XImpredicativeTypes, you’ll get a warning that it does nothing (ie. complete 
no-op) and you should remove it.

Before I pull the trigger, does anyone think they are using it in a 
mission-critical way?

Now that we have Visible Type Application there is a workaround: if you want to 
call a polymorphic function at a polymorphic type, you can explicitly apply it 
to that type.  For example:


{-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-}

module Vta where

  f x = id @(forall a. a->a) id @Int x

You can also leave out the @Int part of course.

Currently we have to use -XImpredicativeTypes to allow the @(forall a. a->a).   
 Is that sensible?  Or should we allow it regardless?   I rather think the 
latter… if you have Visible Type Application (i.e. -XTypeApplications) then 
applying to a polytype is nothing special.   So I propose to lift that 
restriction.

I should go through the GHC Proposals Process for this, but I’m on a plane, so 
I’m going to at least start with an email.

Simon

___
ghc-devs mailing list
ghc-d...@haskell.org<mailto:ghc-d...@haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=01%7C01%7Csimonpj%40microsoft.com%7Cf4d41103efc4487796c708d3e59f3720%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=Ju37RVvZoNakCzz1dgTj%2F8mO9yz4ImbII14Hw%2FHWRpk%3D&reserved=0>

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

FW: Getting rid of -XImpredicativeTypes

[Simon Peyton Jones via Glasgow-haskell-users]

Friends

GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to 
support impredicative polymorphism.  But it is vestigial…. if it works, it’s 
really a fluke.  We don’t really have a systematic story here at all.

I propose, therefore, to remove it entirely.  That is, if you use 
-XImpredicativeTypes, you’ll get a warning that it does nothing (ie. complete 
no-op) and you should remove it.

Before I pull the trigger, does anyone think they are using it in a 
mission-critical way?

Now that we have Visible Type Application there is a workaround: if you want to 
call a polymorphic function at a polymorphic type, you can explicitly apply it 
to that type.  For example:


{-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-}

module Vta where

  f x = id @(forall a. a->a) id @Int x

You can also leave out the @Int part of course.

Currently we have to use -XImpredicativeTypes to allow the @(forall a. a->a).   
 Is that sensible?  Or should we allow it regardless?   I rather think the 
latter… if you have Visible Type Application (i.e. -XTypeApplications) then 
applying to a polytype is nothing special.   So I propose to lift that 
restriction.

I should go through the GHC Proposals Process for this, but I’m on a plane, so 
I’m going to at least start with an email.

Simon
___
ghc-devs mailing list
ghc-d...@haskell.org
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=01%7C01%7Csimonpj%40microsoft.com%7Cfed1bf51dcf744f68fcd08d3e56e903b%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=jwRX7Pxe62sp6xU2jmXyoAxHNzledV%2BPceCGW%2BxN%2FlQ%3D&reserved=0
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: Type families in kind signatures with TypeInType

[Simon Peyton Jones via Glasgow-haskell-users]

Interesting. Is this case also an example, or is it a non-feature?

class C t where
type K t :: Type
type T t :: K t -> Type

m :: t -> T t a


Ah, that’s quite different!  We should do strongly-connected-component analysis 
of the associated-type declarations within a single class declaration…. but we 
don’t currently do that.   No difficulty in principle, I think.

You could open a ticket.   (Do include a link to this email thread and to 
#12088)

Simon


From: d4ve.menen...@gmail.com [mailto:d4ve.menen...@gmail.com] On Behalf Of 
David Menendez
Sent: 23 September 2016 19:51
To: Simon Peyton Jones 
Cc: glasgow-haskell-users@haskell.org Mailing List 

Subject: Re: Type families in kind signatures with TypeInType

On Fri, Sep 23, 2016 at 3:19 AM, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
This is an example of https://ghc.haskell.org/trac/ghc/ticket/12088.

Interesting. Is this case also an example, or is it a non-feature?

class C t where
type K t :: Type
type T t :: K t -> Type

m :: t -> T t a

min.hs:21:17: error:
• Type constructor ‘K’ cannot be used here
(it is defined and used in the same recursive group)
• In the kind ‘K t -> Type’
Failed, modules loaded: none.

GHC accepts this if K t is moved outside of C.

The “type instance T List” declaration actually depends on the “type instance K 
List” declaration; the latter must be typechecked before the former.  But this 
dependency is absolutely unclear.  There’s a long discussion on the thread.  
Bottom line: we don’t know a solid automated way to spot this kind of problem, 
so  I think we are going to ask for programmer assistance.  In this case, we’d 
put a “separator” after the “type instance K List” decl, to explain that it 
must be done first:

type instance K List = Type
===
type instance T List = []

Currently you have to write $(return []) to get the separator, but I think 
we’ll add a special separator.

Yes, this works. Thanks.

It would be disappointing if this is the best we can do, but I guess other 
dependent languages don’t need to deal with open type families and everything 
being potentially mutually recursive.

--
Dave Menendez mailto:d...@zednenem.com>>
<http://www.eyrie.org/~zednenem/<https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.eyrie.org%2F~zednenem%2F&data=01%7C01%7Csimonpj%40microsoft.com%7C89f26f5e599e49b96e0c08d3e3e29e26%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=c8g6ahf%2F8lun%2BPBof97s03XbePVwT4Buh6ef2bDSjLg%3D&reserved=0>>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: Type families in kind signatures with TypeInType

[Simon Peyton Jones via Glasgow-haskell-users]

This is an example of https://ghc.haskell.org/trac/ghc/ticket/12088.

The “type instance T List” declaration actually depends on the “type instance K 
List” declaration; the latter must be typechecked before the former.  But this 
dependency is absolutely unclear.  There’s a long discussion on the thread.  
Bottom line: we don’t know a solid automated way to spot this kind of problem, 
so  I think we are going to ask for programmer assistance.  In this case, we’d 
put a “separator” after the “type instance K List” decl, to explain that it 
must be done first:

type instance K List = Type
===
type instance T List = []

Currently you have to write $(return []) to get the separator, but I think 
we’ll add a special separator.

Simon


From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of David Menendez
Sent: 23 September 2016 05:48
To: glasgow-haskell-users@haskell.org Mailing List 

Subject: Type families in kind signatures with TypeInType

Should the code below work in GHC 8.0.1?

{-# LANGUAGE TypeInType, TypeFamilies #-}

import Data.Kind (Type)

type family K t :: Type
type family T t :: K t -> Type

data List

type instance K List = Type
type instance T List = []


Right now, I get an error like this one:

min.hs:12:24: error:
• Expected kind ‘K List -> Type’, but ‘[]’ has kind ‘* -> *’
• In the type ‘[]’
  In the type instance declaration for ‘T’

which is puzzling, since K List -> Type and * -> * should be the same.

Obviously, TypeInType is experimental and incomplete. I’m just wondering if 
this sort of thing is expected to work, or if I’m doing something not yet 
supported or never to be supported

In particular, the kind signature for T is forall t -> K t -> Type, which looks 
like DependentHaskell.

--
Dave Menendez mailto:d...@zednenem.com>>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: GHC Performance / Replacement for R?

[Simon Peyton Jones via Glasgow-haskell-users]

Sounds bad.  But it'll need someone with bytestring expertise to debug.  Maybe 
there's a GHC problem underlying; or maybe it's shortcoming of bytestring.  

Simon

|  -Original Message-
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  boun...@haskell.org] On Behalf Of Dominic Steinitz
|  Sent: 25 August 2016 10:11
|  To: GHC users 
|  Subject: GHC Performance / Replacement for R?
|  
|  I am trying to use Haskell as a replacement for R but running into two
|  problems which I describe below. Are there any plans to address the
|  performance issues I have encountered?
|  
|   1. I seem to have to jump through a lot of hoops just to be able to
|  select the data I am interested in.
|  
|  {-# LANGUAGE ScopedTypeVariables #-}
|  
|  {-# OPTIONS_GHC -Wall #-}
|  
|  import Data.Csv hiding ( decodeByName )
|  import qualified Data.Vector as V
|  
|  import Data.ByteString ( ByteString )
|  import qualified Data.ByteString.Char8 as B
|  
|  import qualified Pipes.Prelude as P
|  import qualified Pipes.ByteString as Bytes import Pipes import
|  qualified Pipes.Csv as Csv import System.IO
|  
|  import qualified Control.Foldl as L
|  
|  main :: IO ()
|  main = withFile "examples/787338586_T_ONTIME.csv" ReadMode $ \h -> do
|let csvs :: Producer (V.Vector ByteString) IO ()
|csvs = Csv.decode HasHeader (Bytes.fromHandle h) >-> P.concat
|uvectors :: Producer (V.Vector ByteString) IO ()
|uvectors = csvs  >-> P.map (V.foldr V.cons V.empty)
|vec_vec <- L.impurely P.foldM  L.vector uvectors
|print $ (vec_vec :: V.Vector (V.Vector ByteString)) V.! 17
|print $ V.length vec_vec
|let rockspring = V.filter (\x -> x V.! 8 == B.pack "RKS") vec_vec
|print $ V.length rockspring
|  
|  Here's the equivalent R:
|  
|  df <- read.csv("787338586_T_ONTIME.csv")
|  rockspring <- df[df$ORIGIN == "RKS",]
|  
|   2. Now I think I could improve the above to make an environment that
|  is more similar to the one my colleagues are used to in R but more
|  problematical is the memory usage.
|  
|   * 112.5M file
|   * Just loading the source into ghci takes 142.7M
|   * > foo <- readFile "examples/787338586_T_ONTIME.csv" > length foo
| takes me up to 4.75G. But we probably don't want to do this!
|   * Let's try again.
|   * > :set -XScopedTypeVariables
|   * > h <- openFile "examples/787338586_T_ONTIME.csv" ReadMode
|   * > let csvs :: Producer (V.Vector ByteString) IO () = Csv.decode
|  HasHeader (Bytes.fromHandle h) >-> P.concat
|   * > let uvectors :: Producer (V.Vector ByteString) IO () = csvs  >->
|  P.map (V.map id) >-> P.map (V.foldr V.cons V.empty)
|   * > vec_vec :: V.Vector (V.Vector ByteString) <- L.impurely P.foldM
|  L.vector uvectors
|   * Now I am up at 3.17G. In R I am under 221.3M.
|   * > V.length rockspring takes a long time to return 155 and now I am
| at 3.5G!!! In R > rockspring <- df[df$ORIGIN == "RKS",] seems
| instantaneous and now uses only 379.5M.
|   * > length(rockspring) 37 > length(df$ORIGIN) 471949 i.e. there are
| 37 columns and 471,949 rows.
|  
|  Running this as an executable gives
|  
|  ~/Dropbox/Private/labels $ ./examples/BugReport +RTS -s ["2014-01-
|  01","EV","20366","N904EV","2512","10747","1074702","30747",
|   "BRO","Brownsville, TX","Texas","11298","1129803","30194",
|"DFW","Dallas/Fort Worth, TX","Texas","0720","0718",
|"-2.00","8.00","0726","0837","7.00","0855","0844","-11.00","0.00",
|"","0.00","482.00","","","","","",""]
|  471949
|  155
|14,179,764,240 bytes allocated in the heap
| 3,378,342,072 bytes copied during GC
|   786,333,512 bytes maximum residency (13 sample(s))
|36,933,976 bytes maximum slop
|  1434 MB total memory in use (0 MB lost due to
|  fragmentation)
|  
|   Tot time (elapsed)  Avg pause
|  Max pause
|Gen  0 26989 colls, 0 par1.423s   1.483s 0.0001s
|  0.0039s
|Gen  113 colls, 0 par1.005s   1.499s 0.1153s
|  0.6730s
|  
|INITtime0.000s  (  0.003s elapsed)
|MUT time3.195s  (  3.193s elapsed)
|GC  time2.428s  (  2.982s elapsed)
|EXITtime0.016s  (  0.138s elapsed)
|Total   time5.642s  (  6.315s elapsed)
|  
|%GC time  43.0%  (47.2% elapsed)
|  
|Alloc rate4,437,740,019 bytes per MUT second
|  
|Productivity  57.0% of total user, 50.9% of total elapsed
|  
|  ___
|  Glasgow-haskell-users mailing list
|  Glasgow-haskell-users@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
|  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-
|  users&data=01%7c01%7csimonpj%40microsoft.com%7c5017a5fe26cb4df9c41d08d
|  3ccc7b5bd%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2Ku1Fr5QttHRoj5
|  NSOJREZrt2Fsqhi63iJOpxmku68E%3d
___
Glasgow-haskell-users mailing list
Gl

RE: ArgumentDo proposal updated

[Simon Peyton Jones via Glasgow-haskell-users]

I've added record construction and update to the syntax, which makes it clearer 
how the other constructs are analogous to them.

Simon

|  -Original Message-
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  boun...@haskell.org] On Behalf Of Akio Takano
|  Sent: 11 July 2016 03:24
|  To: glasgow-haskell-users@haskell.org
|  Subject: ArgumentDo proposal updated
|  
|  Hi glasgow-haskell-users,
|  
|  Thank you for all the feedback to the ArgumentDo proposal. Following
|  the discussion, I made changes to the proposal and updated the wiki
|  page [0].
|  
|  Now the proposed grammar is greatly simplified: it doesn't add a new
|  non-terminal anymore, indeed it removes one instead. The proposed set
|  of accepted programs remains unchanged.
|  
|  I hope the this update addresses one major concern that was raised in
|  the previous discussion.
|  
|  Any feedback is appreciated.
|  
|  Regards,
|  Takano Akio
|  
|  [0]: https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo
|  ___
|  Glasgow-haskell-users mailing list
|  Glasgow-haskell-users@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
|  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-
|  users&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c4ef11cd0d5d041
|  3ac28108d3a9327fd1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=flpo46
|  T9CWuGH8ndJY3roC44iubY7U8xeYWkJ2J8Img%3d
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: Rethinking GHC's approach to managing proposals

[Simon Peyton Jones via Glasgow-haskell-users]

Just to be clear:

* We are actively seeking feedback about the proposal [4] below.
  It's not a fait-accompli.

* You can join the dialogue by (a) replying to this email,
  (b) via the "Conversations" tab of [4], namely
  https://github.com/ghc-proposals/ghc-proposals/pull/1
  Doubtless via reddit too!

  If you don't like something, the more specific and concrete you
  can be about a better alternative, the better.  E.g. Richard's
  comments on the "conversations" tab both ask questions and propose
  answers.  Bravo!

Simon

| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ben
| Gamari
| Sent: 09 July 2016 21:46
| To: GHC developers ; ghc-users 
| Subject: Rethinking GHC's approach to managing proposals
| 
| Hello everyone,
| 
| Recently there has been a fair bit of discussion[1,2] around the
| mechanisms by which proposed changes to GHC are evaluated. While we have
| something of a formal proposal protocol [3], it is not clearly
| documented, inconsistently applied, and may be failing to serve a
| significant fraction of GHC's potential contributor pool.
| 
| Over the last few weeks, I have been doing a fair amount of reading,
| thinking, and discussing to try to piece together a proposal scheme
| which better serves our community.
| 
| The resulting proposal [4] is strongly inspired by the RFC process in
| place in the Rust community [5], the leaders of which have thought quite
| hard about fostering community growth and participation. While no
| process is perfect, I feel like the Rust process is a good starting
| point for discussion, offering enough structure to guide new
| contributors through the process while requiring only a modest
| investment of developer time.
| 
| To get a sense for how well this will work in our community, I propose
| that we attempt to self-host the proposed process. To this end I have
| setup a ghc-proposals repository [6] and opened a pull request for
| discussion of the process proposal [4].
| 
| Let's see how this goes.
| 
| Cheers,
| 
| - Ben
| 
| 
| [1]
| https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.red
| dit.com%2fr%2fhaskell%2fcomments%2f4oyxo2%2fblog_contributing_to_ghc%2f&
| data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c99735311c5f64cac6a6608
| d3a83a032a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Hl6GqRWfu7IOQtpE
| jpfsNAkv3mmLgNKm2ciQDoMe6HA%3d
| [2]
| https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.red
| dit.com%2fr%2fhaskell%2fcomments%2f4isua9%2fghc_development_outsidein%2f
| &data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c99735311c5f64cac6a660
| 8d3a83a032a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bj2AQqQirX3X%2f
| 4%2fFr05eXFuD4yW0r9Nmrmdg7IGEF%2f8%3d
| [3]
| https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures
| [4] https://github.com/ghc-proposals/ghc-
| proposals/pull/1/files?short_path=14d66cd#diff-
| 14d66cda32248456a5f223b6333c6132
| [5] https://github.com/rust-lang/rfcs
| [6] https://github.com/ghc-proposals/ghc-proposals
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Simon's email classified as spam

[Simon Peyton Jones via Glasgow-haskell-users]

Dear GHC devs/users
This is another test to see if email from me, relayed via Haskell.org, ends up 
in your spam folder.  Gershom thinks he’s fixed it (below).  Can I trespass on 
your patience once more?
Just let me know if this email ends up in your inbox or spam.  Can you cc John 
and Gershom (but perhaps not everyone else)?  Thanks
Simon


| From: Gershom B [mailto:gersh...@gmail.com]

| Sent: 18 June 2016 18:53

| To: Simon Peyton Jones ; John Wiegley

| 

| Cc: Michael Burge 

| Subject: Re: FW: CMM-to-SAM: Register allocation weirdness

|

| Simon — I just found two possible sources of the problem (first: the top

| level config didn’t take hold due to other errors when updating — fixed that,

| and second, it might be possible the top level config isn’t retroactively

| applied to all lists — so i added the config to the relevant lists directly).

|

| I think if you try one more time it might work (fingers crossed).

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

RE: CMM-to-ASM: Register allocation wierdness

[Simon Peyton Jones]

Takenobu, and others
Thanks.  Several people have mentioned that email from me is ending up in spam.
It turns out to be a fault in the Haskell.org mailman setup, which was 
mis-forwarding my email.
Apparently it is fixed now.  If THIS message ends up in spam with a complaint 
like that below, could you let me know?
Thanks
Simon

From: Takenobu Tani [mailto:takenobu...@gmail.com]
Sent: 18 June 2016 08:18
To: Simon Peyton Jones 
Subject: Re: CMM-to-ASM: Register allocation wierdness

Hi Simon,

I report to you about your mails.

Maybe, your mails don't reach to Gmail users.
I don't know why, but your mails have been distributed to "Spam" folder in 
Gmail.

Gmail displays following message:
  "Why is this message in Spam? It has a from address in 
microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmicrosoft.com&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce84426f5278c40b4b5b608d39748a97d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=4HVBZ56xFvcR1o%2fFaQsm5pyEY7FtYbSsF8ZI9n%2bKGmc%3d>
 but has failed 
microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmicrosoft.com&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce84426f5278c40b4b5b608d39748a97d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=4HVBZ56xFvcR1o%2fFaQsm5pyEY7FtYbSsF8ZI9n%2bKGmc%3d>'s
 required tests for authentication."


For reference, I attach the screen of my Gmail of spam folder.
Recent your mails have been detected as spam.
Please check your mail settings.

Regards,
Takenobu

2016-06-16 21:10 GMT+09:00 Simon Peyton Jones 
mailto:simo...@microsoft.com>>:
| All-in-all, the graph coloring allocator is in great need of some love;
| Harendra, perhaps you'd like to have a try at dusting it off and perhaps
| look into why it regresses in compiler performance? It would be great if
| we could use it by default.

I second this.   Volunteers are sorely needed.

Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org<mailto:Glasgow-haskell-users@haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-users&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce84426f5278c40b4b5b608d39748a97d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ZA5HqnZKwW95MzgBfiSVPXmyVnWjKrYA8L1W5nzd%2f%2b8%3d>

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

RE: CMM-to-ASM: Register allocation wierdness

[Simon Peyton Jones]

| All-in-all, the graph coloring allocator is in great need of some love;
| Harendra, perhaps you'd like to have a try at dusting it off and perhaps
| look into why it regresses in compiler performance? It would be great if
| we could use it by default.

I second this.   Volunteers are sorely needed.

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

RE: Pattern synonyms and GADTs in GHC 8.0.1

[Simon Peyton Jones]

GHC 8.0 swaps the order of provided vs required contexts in a pattern synonym 
signature.  (7.10 was advertised as experimental).  Thus:

pattern AddP :: () => (Num a, Eq a) => Exp a -> Exp a -> Exp a


Then it's fine

Simon

|  -Original Message-
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  boun...@haskell.org] On Behalf Of Emil Axelsson
|  Sent: 26 May 2016 16:27
|  To: glasgow-haskell-users 
|  Subject: Pattern synonyms and GADTs in GHC 8.0.1
|  
|  I have a problem where a pattern synonym doesn't provide the expected
|  type refinement in GHC 8.0.1.
|  
|  > {-# LANGUAGE GADTs #-}
|  > {-# LANGUAGE PatternSynonyms #-}
|  >
|  > data Exp a
|  >   where
|  > Num :: (Eq a, Num a) => a -> Exp a
|  > Add :: (Eq a, Num a) => Exp a -> Exp a -> Exp a
|  >
|  > pattern NumP a = Num a
|  >
|  > pattern AddP :: (Num a, Eq a) => Exp a -> Exp a -> Exp a pattern
|  AddP
|  > a b = Add a b
|  >
|  > simplifyP :: Exp a -> Exp a
|  > simplifyP (AddP a (NumP 0)) = a
|  > simplifyP a = a
|  
|  This gives the error
|  
|   • No instance for (Eq a) arising from a pattern
| Possible fix:
|   add (Eq a) to the context of
| the type signature for:
|   simplifyP :: Exp a -> Exp a
|   • In the pattern: AddP a (NumP 0)
| In an equation for ‘simplifyP’: simplifyP (AddP a (NumP 0)) = a
|  
|  If I remove the type signature for `AddP`, the code goes through.
|  Unfortunately, in my real code I need the type signature in order to
|  resolve overloading.
|  
|  GHC 7.10 didn't have this problem.
|  
|  Is this a bug?
|  
|  / Emil
|  ___
|  Glasgow-haskell-users mailing list
|  Glasgow-haskell-users@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
|  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-
|  users&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ccb54f042472240
|  7ed99608d3857a317a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=xv8M7C
|  IC4zyT4Zgq3HnXiGzUA1Z0tltZpE%2fIYhYP8KQ%3d
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: suboptimal ghc code generation in IO vs equivalent pure code case

[Simon Peyton Jones]

As Harendra has found, the biggest difference is probably that the IO version 
is necessarily strict, constructing the entire list (via the stack) before it 
returns, whereas the pure one is lazy, constructing the list only on demand. So 
the memory footprint of the lazy one will be asymptotically smaller (constant 
instead of linear in the list size).

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Harendra Kumar
Sent: 14 May 2016 22:18
To: David Feuer 
Cc: GHC users 
Subject: Re: suboptimal ghc code generation in IO vs equivalent pure code case

I have stared at the cmm and assembly quite a bit. Indeed there is no trace of 
a token in cmm and assembly as expected. Here is what is happening.

In the IO case the entire original list is evaluated and unfolded on the stack 
first. During the recursion, the stack will have as many closure pointers as 
the size of the list, last element of the list being on top of the stack. When 
we finish recursing the original list, the stack unwinds and we start creating 
the closures for the new list in the reverse order. This is all pretty evident 
from the cmm dump output.

This process retains a lot of heap and stack memory (proportional to the size 
of the list) which will require the GC to do a lot of walking, fixing and 
copying. I guess that's where the additional cost is coming from. When the list 
size increases this cost increases nonlinearly. That explains why at lower list 
sizes the IO version performs not just equal to but a tad better than the pure 
version because if GC overhead is not considered this code is in fact more 
efficient.

-harendra

On 15 May 2016 at 01:56, David Feuer 
mailto:david.fe...@gmail.com>> wrote:

The state token is zero-width and should therefore be erased altogether in code 
generation.
On May 14, 2016 4:21 PM, "Tyson Whitehead" 
mailto:twhiteh...@gmail.com>> wrote:
On 14/05/16 02:31 PM, Harendra Kumar wrote:
The difference seems to be entirely due to memory pressure. At list size 1000 
both pure version and IO version perform equally. But as the size of the list 
increases the pure version scales linearly while the IO version degrades 
exponentially. Here are the execution times per list element in ns as the list 
size increases:

Size of list  Pure   IO
1000   8.7  8.3
1 8.7  18
10   8.8  63
100 9.3  786

This seems to be due to increased GC activity in the IO case. The GC stats for 
list size 1 million are:

IO case:   %GC time  66.1%  (61.1% elapsed)
Pure case:   %GC time   2.6%  (3.3% elapsed)

Not sure if there is a way to write this code in IO monad which can reduce this 
overhead.

Something to be aware of is that GHC currently can't pass multiple return 
values in registers (that may not be a 100% accurate statement, but a 
reasonable high level summary, see ticket for details)

https://ghc.haskell.org/trac/ghc/ticket/2289

This can bite you with with the IO monad as having to pass around the world 
state token turns single return values into multiple return values (i.e., the 
new state token plus the returned value).

I haven't actually dug into your code to see if this is part of the problem, 
but figured I would mention it.

Cheers!  -Tyson
___
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

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

RE: Looking for GHC compile-time performance tests

[Simon Peyton Jones]

Thanks.  A repeatable test case would be incredibly helpful here.

Simon

| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Edward Kmett
| Sent: 05 May 2016 21:50
| To: Erik de Castro Lopo 
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: Looking for GHC compile-time performance tests
| 
| vector-algorithms has gotten slower to both compile and for users rather
| consistently during each release throughout the 7.x lifecycle. That may serve
| as a good torture test as well.
| 
| > On May 6, 2016, at 6:22 AM, Erik de Castro Lopo 
| wrote:
| >
| > Ben Gamari wrote:
| >
| >> So, if you would like to see your program's compilation time improve
| >> in GHC 8.2, put some time into reducing it to something minimal, submit
| >> it to us via a Trac ticket, and let us know in this thread.
| >
| > The vector package is probably a good candidate. Compling vector slowed
| > down signicantly between 7.8 and 7.10, only to speed up again with 8.0.
| >
| > Erik
| > --
| > --
| > Erik de Castro Lopo
| > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.mega-
| nerd.com%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c502efb8a671d48e
| 03c2408d37526cd98%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=NO6ktHARs7KWr%
| 2fFR9DJB3rAum%2bLblzbVFc5AeBi8Smg%3d
| > ___
| > Glasgow-haskell-users mailing list
| > Glasgow-haskell-users@haskell.org
| >
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
| org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-
| users&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c502efb8a671d48e03c240
| 8d37526cd98%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=f%2bspd5cb57tq15z4vF
| TrUe2RPC2SXY6SAu9MPW8fYfw%3d
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
| org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-
| users&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c502efb8a671d48e03c240
| 8d37526cd98%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=f%2bspd5cb57tq15z4vF
| TrUe2RPC2SXY6SAu9MPW8fYfw%3d
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: Magic classes for Overloaded Record Fields, overlaps, FunDeps

[Simon Peyton Jones]

|  > I have been vacillating between type families and fundeps for the ORF
|  > classes. I hadn't fully appreciated this point about overlap, but I
|  > think it is a reason to prefer fundeps, which is the direction in
|  > which I'm leaning. I'd be grateful for feedback on this issue though!
...

|  The difficulty remains that as soon as you want overlaps in such a way
|  that takes you to FunDeps, it's very difficult to 'mix modes' with type
|  families.

Can one give a standalone explanation of the fundep/type-family/overlap issue 
here? Or is it explained on a wiki page?

Simon

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

RE: [Feedback requested]: -fhelpful-import-errors

[Simon Peyton Jones]

Best in the ticket https://ghc.haskell.org/trac/ghc/ticket/11418#comment:27, I 
transferred your comment there

S

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Sven Panne
Sent: 16 February 2016 18:03
To: glasgow-haskell-users@haskell.org
Subject: Re: [Feedback requested]: -fhelpful-import-errors

2016-02-16 18:12 GMT+01:00 Tom Sydney Kerckhove 
mailto:syd.kerckh...@gmail.com>>:
[...] As suggested by `thomie`, I created a design proposal at
https://ghc.haskell.org/trac/ghc/wiki/Proposal/HelpfulImportError
and am now looking for feedback.

[ Not sure if the feedback should be submitted here on in the corresponding 
ticket... ]

Just a few quick remarks:

   * Whatever you do, never walk the file system tree up or down in an 
uncontrolled way, this will kill basically all benefits and is a show-stopper. 
File systems like NFS, NTFS, stuff on USB sticks etc. are so *horribly* slow 
when used that way that the walks will probably dominate your compilation time. 
And even under Linux it's not uncommon to have a few dozen directory levels and 
hundreds of thousands of files below our cwd: Just check out a few 
repositories, have some leftovers from compilations, tons of documentations in 
small HTML files etc., and this sums up quickly. Git walks up the tree, but 
only looking for a specific directory and will e.g. not cross mount points 
under normal circumstances. This is probably the limit of what you can do.

   * Caching between runs will be tricky: How will you invalidate the cache? 
People can (and will :-) do all kinds of evil things between runs, so how can 
you (in-)validate the cache quicker than re-scanning the file system again?

   * As a general rule to keep in mind during the design: Successful compiler 
runs should not pay a price. It's OK if things are a little bit slower when an 
error occurs, but the main use case is successful compilation. This is a bit 
like exceptions in most programming language implementations: They are more or 
less for free when you don't use them (yes, they have a cost even then because 
they complicate/invalidate some compiler optimizations, but let's forget that 
for now), and are often costly when you actually raise them.

Just my 2c,
   S.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: Were usage types ever in GHC

[Simon Peyton Jones]

Keith Wansbrough did implement his thesis work in a fork of GHC.  But (a) it 
was jolly complicated and pervasive, and (b) the performance improvements were 
not great.  It didn't pay its way. So we dropped it.  See his thesis, available 
here http://research.microsoft.com/en-us/um/people/simonpj/papers/papers.html

What we HAVE done (and is in GHC) is cardinality analysis. See "Higher order 
cardinality analysis in theory and practice"
http://research.microsoft.com/en-us/um/people/simonpj/papers/usage-types/usage.htm

Enjoy!

Simon
| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Philip Dexter
| Sent: 21 January 2016 23:15
| To: GHC Users List 
| Subject: Were usage types ever in GHC
| 
| I've recently been digging around to see if there has ever been any
| attempt to perform any sort of data reuse optimization in functional
| languages.
| 
| Along with many other papers, I've come across `Once upon a type' as well
| as `Once upon a polymorphic type'. They both mention a desire to include a
| similar system in GHC.
| 
| Then in `Playing by the rules: rewriting as a practical optimization
| technique in GHC' I see usage types mentioned in section 5.3:
| 
| """
| To express this, GHC adds extra usage type arguments to map, both at its
| definition and at its call sites. Once this is done, a specialised version
| of map can be compiled for the case when the usage-type argument is
| “once”, and a rule generated to match such calls, in exactly the same way
| as for specialising overloading.
| """
| 
| I can't tell if this is simply a hypothetical optimization or if this
| really happened at one point in the history of GHC.
| 
| I was hoping somebody could shed some light on this topic
| 
| Was a usage type system or something similar (e.g. linear type system)
| ever present in GHC?
| 
| If it was then why was it taken out (unless I'm missing something, this
| optimization is not happening today)? I could guess at this and say that
| the gains weren't worth the overhead, but perhaps there's another reason.
| 
| If it was never present, why not? There was obviously at least some
| interest in this sort of optimization at some point in the Haskell
| community and I'd be curious as to why it was never tested in GHC.
| 
| Thanks!
| 
| Philip Dexter
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: suppress warning "Defined but not used: type variable ‘x’" in GHC-8.0

[Simon Peyton Jones]

I have created not one but three tickets arising from this thread:


· https://ghc.haskell.org/trac/ghc/ticket/11449

· https://ghc.haskell.org/trac/ghc/ticket/11450

· https://ghc.haskell.org/trac/ghc/ticket/11451

I’d love comments on them: which of the three matter most to you folk?  The 
first also involves a flag-naming question.

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Edward Kmett
Sent: 17 January 2016 14:44
To: Andrew Farmer 
Cc: Henning Thielemann ; 
glasgow-haskell-users@haskell.org
Subject: Re: suppress warning "Defined but not used: type variable ‘x’" in 
GHC-8.0

No, the type instance must match the class heading.

I can use

instance Foo [_a] where
  type Bar [_a] = Int
  whatever = ... where
bar :: _a -> Int
bar = ...

but that is a needlessly messy thing to request of every package everywhere.

The arguments being pattern matched in a class associated type aren't really 
just bindings, they reference the surrounding context and so shouldn't be 
treated the same as the basic type family case.

It isn't just the class associated type being mangled, it is every type 
variable that comes from the instance head in the entire body of every instance 
that happens to have a class associated type in it.

Note that in the example above I added another ScopedTypeVariables reference to 
the same parameter, but it _also_ must be mangled despite having absolutely 
nothing to do with the class associated type.

The existing convention has worked since 6.10 or so, when all of this stuff was 
invented in the first place, and the new state of affairs is clearly worse.

-Edward

On Sun, Jan 17, 2016 at 3:16 AM, Andrew Farmer 
mailto:xicheko...@gmail.com>> wrote:

Can't you just:

instance Foo [a] where
  type Bar [_a] = Int

(At least I think I did that somewhere...)
On Jan 16, 2016 9:24 PM, "Edward Kmett" 
mailto:ekm...@gmail.com>> wrote:
As a data point I now get thousands of occurrences of this warning across my 
packages.

It is quite annoying.

class Foo a where
  type Bar a

instance Foo [a] where
  type Bar [a] = Int

is enough to trigger it.

And you can't turn it off by using _ as

instance Foo [_] where
  type Bar [_] = Int

isn't legal.

I've been avoiding it for now by using

  if impl(ghc >= 8)

ghc-options: -fno-warn-unused-matches

but this is a pretty awful addition to this warning as it stands.
-Edward

On Mon, Jan 11, 2016 at 2:12 PM, Henning Thielemann 
mailto:lemm...@henning-thielemann.de>> wrote:

On Mon, 11 Jan 2016, Richard Eisenberg wrote:
On Jan 9, 2016, at 6:44 PM, Henning Thielemann 
mailto:lemm...@henning-thielemann.de>> wrote:

instance (Natural n) => Num.Integer (Un n) where
   type Repr (Un _n) = Unary


GHC-7.6.3 and GHC-7.4.2 complain:
   Type indexes must match class instance head
   Found `Un _n' but expected `Un n'
   In the type synonym instance declaration for `Num.Repr'
   In the instance declaration for `Num.Integer (Un n)'


GHC-7.8.4, GHC-7.10.3 and GHC-8.0 are happy with the difference.

I'm surprised this is accepted at all. Looks like hogwash to me. I think you 
should post a bug report.

Ok, but then GHC must not warn about the unused argument of Repr.

___
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

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

RE: Warnings, -Wall, and versioning policy

[Simon Peyton Jones]

OK.  When this thread comes to a conclusion, can someone write it down; update 
the 3-release policy; and say what changes you want in GHC?

Thanks

Simon

| -Original Message-
| From: Gershom B [mailto:gersh...@gmail.com]
| Sent: 13 January 2016 18:18
| To: Simon Peyton Jones 
| Cc: GHC users ; ghc-d...@haskell.org;
| Edward Kmett ; Herbert Valerio Riedel ; Simon
| Marlow 
| Subject: Re: Warnings, -Wall, and versioning policy
| 
| On Wed, Jan 13, 2016 at 7:43 AM, Simon Peyton Jones
|  wrote:
| 
| > An implication is that GHC is free to introduce new warnings X into -Wall.
| Indeed doing so would be good, because the warning X might later move into
| the default set.  Indeed for such warnings, adding a "PS: this warning will
| become the default in GHC 9.2" might be a useful way to signal the upcoming
| change.  Then you can use -Wall and look for any "PS" indicators.
| 
| Yep. In general I think we don't know how _much_ noise a warning will
| create until it makes it into the wild, so just as with other new
| features its good to give them a bit of a "dry run" before deciding
| that they come "by default."
| 
| > You don’t give a rationale for (2) but I think you intend that if someone
| wants to add -Wno-X when GHC introduces X in 9.0, you don't want GHC 8.6 to
| fall over.  Worth articulating the rationale.
| 
| Yes, that's exactly the rationale. It doesn't help us short term, but
| longer term it should let users fiddle with warning flags more freely.
| 
| I think the general issue with three releases is not whether or not
| GHC introduces warnings and at what pace, but that certain _types_ of
| warnings (in particular redundancies, be they constraints, imports,
| etc) will fire on entirely desirable code due to certain migration
| paths. Most of the tricks we developed for backwards-compatible
| migrations essentially depend on certain redundancies in code for a
| period. Those can't be removed without hurting backwards-compatibility
| of code, but their presence also induces warnings.
| 
| So as a whole "warning freeness" and "backwards compatible migrations"
| become increasingly at odds with one another.
| 
| A full refactor of our warning sets would probably help in this
| regard, so that the default advice could be "good code is -Wlint clean
| but not necessarily -Wpedantic clean". Or even "is clean under
| -Wpedantic -Wno-redundancies".
| 
| --Gershom
| 
| >
| > | -Original Message-
| > | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| > | boun...@haskell.org] On Behalf Of Gershom B
| > | Sent: 13 January 2016 02:20
| > | To: GHC users ; ghc-d...@haskell.org;
| > | Edward Kmett ; Herbert Valerio Riedel ;
| Simon
| > | Marlow 
| > | Subject: Re: Warnings, -Wall, and versioning policy
| > |
| > | Hi Simon. I think you raise important issues here, although I believe
| you’re
| > | mistaken in one regard. Hackage rejects -Werror but I don’t think it
| rejects
| > | -Wall.
| > |
| > |  What I’d suggest is perhaps the following.
| > |
| > | 1) The libraries committee put forward -Wall cleanliness as an
| _aspirational
| > | goal_ rather than a final product, noting that the actual cleanliness
| might
| > | be with regards to `-Wall -Wno-foo -Wno-bar``.
| > |
| > | 2) GHC _change its code_ so that `ghc -Wno-wat` yields a _warning_ rather
| > | than an _error_ on `-W` followed by an unrecognized string.
| > |
| > | 3) No warning flags be introduced into the _default_ set without at least
| a
| > | few releases in some other set such as `-Wall`.
| > |
| > | We may also want to try to maintain a “best practices” example cabal file
| > | that shows how one can build with additional warnings under a “dev” flag,
| and
| > | with fewer warnings otherwise — so that the noise inflicted on package
| devs
| > | under their builds doesn’t get inflicted on all end users, and even
| perhaps
| > | with different warning flags per ghc version flag.
| > |
| > | I think this will respect the concerns of people that like to use `-
| Wall`,
| > | want to have relatively warning clean code, and want to have some degree
| of
| > | backwards compatibility (which is not an unreasonable combination in my
| > | opinion).
| > |
| > | Some related
| > | discussion: https://ghc.haskell.org/trac/ghc/ticket/11370 and
| https://ghc.has
| > |
| https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fkell.org%2ft
| rac%2fghc%2fwiki%2fDesign%2fWarnings&data=01%7c01%7csimonpj%40064d.mgd.micros
| oft.com%7c9de7c65d89a84408f00808d31c45e258%7c72f988bf86f141af91ab2d7cd011db47
| %7c1&sdata=BE9pq5knT%2fWTxOfrtEYefqDC2qMEQP%2b9fbcgvs%2f2qr0%3d | Cheers,
| > | Gershom
| > |
| > |
| > | On January 12, 2016 at 11:18:57 AM, Simon Marlow (marlo...@gmail.com)
| w

RE: Warnings, -Wall, and versioning policy

[Simon Peyton Jones]

Thanks Gershom.  That all sounds fine to me.  

An implication is that GHC is free to introduce new warnings X into -Wall.   
Indeed doing so would be good, because the warning X might later move into the 
default set.  Indeed for such warnings, adding a "PS: this warning will become 
the default in GHC 9.2" might be a useful way to signal the upcoming change.  
Then you can use -Wall and look for any "PS" indicators.

You don’t give a rationale for (2) but I think you intend that if someone wants 
to add -Wno-X when GHC introduces X in 9.0, you don't want GHC 8.6 to fall 
over.  Worth articulating the rationale.

Simon

| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Gershom B
| Sent: 13 January 2016 02:20
| To: GHC users ; ghc-d...@haskell.org;
| Edward Kmett ; Herbert Valerio Riedel ; Simon
| Marlow 
| Subject: Re: Warnings, -Wall, and versioning policy
| 
| Hi Simon. I think you raise important issues here, although I believe you’re
| mistaken in one regard. Hackage rejects -Werror but I don’t think it rejects
| -Wall.
| 
|  What I’d suggest is perhaps the following.
| 
| 1) The libraries committee put forward -Wall cleanliness as an _aspirational
| goal_ rather than a final product, noting that the actual cleanliness might
| be with regards to `-Wall -Wno-foo -Wno-bar``.
| 
| 2) GHC _change its code_ so that `ghc -Wno-wat` yields a _warning_ rather
| than an _error_ on `-W` followed by an unrecognized string.
| 
| 3) No warning flags be introduced into the _default_ set without at least a
| few releases in some other set such as `-Wall`.
| 
| We may also want to try to maintain a “best practices” example cabal file
| that shows how one can build with additional warnings under a “dev” flag, and
| with fewer warnings otherwise — so that the noise inflicted on package devs
| under their builds doesn’t get inflicted on all end users, and even perhaps
| with different warning flags per ghc version flag.
| 
| I think this will respect the concerns of people that like to use `-Wall`,
| want to have relatively warning clean code, and want to have some degree of
| backwards compatibility (which is not an unreasonable combination in my
| opinion).
| 
| Some related
| discussion: https://ghc.haskell.org/trac/ghc/ticket/11370 and https://ghc.has
| kell.org/trac/ghc/wiki/Design/Warnings
| 
| Cheers,
| Gershom
| 
| 
| On January 12, 2016 at 11:18:57 AM, Simon Marlow (marlo...@gmail.com) wrote:
| > Hi folks,
| >
| > We haven't described what guarantees GHC provides with respect to -Wall
| > behaviour across versions, and as a result there are some differing
| > expectations around this. It came up in this weeks' GHC meeting, so we
| > thought it would be a good idea to state the policy explicitly. Here it is:
| >
| > We guarantee that code that compiles with no warnings with -Wall
| > ("Wall-clean") and a particular GHC version, on a particular
| > platform, will be Wall-clean with future minor releases of the same
| > major GHC version on the same platform.
| >
| > (we plan to put this text in the User's Guide for future releases)
| >
| > There are no other guarantees. In particular:
| > - In a new major release, GHC may introduce new warnings into -Wall,
| > and/or change the meaning of existing warnings such that they trigger
| > (or not) under different conditions.
| > - GHC may generate different warnings on different platforms. (examples
| > of this are -fwarn-overflowed-literals and
| > -fwarn-unsupported-calling-conventions)
| >
| > Some rationale:
| > - We consider any change to the language that GHC accepts to be a
| > potentially code-breaking change, and subject to careful scrutiny. To
| > extend this to warnings would be a *lot* of work, and would make it
| > really difficult to introduce new warnings and improve the existing ones.
| > - Warnings can be based on analyses that can change in accuracy over
| > time. The -fwarn-unused-imports warning has changed a lot in what it
| > rejects, for example.
| > - We often introduce new warnings that naturally belong in -Wall. If
| > -Wall was required to be a fixed point, we would have to start
| > introducing new flags, and versioning, etc. and even keep the old
| > implementation of warnings when they change. It would get really messy.
| >
| > There are some consequences to this. -Wall -Werror is useful for
| > keeping your code warning-clean when developing, but shipping code with
| > these options turned on in the build system is asking for trouble when
| > building your code with different GHC versions and platforms. Keep
| > those options for development only. Hackage already rejects packages
| > that include -Wall for this reason.
| >
| > One reason we're raising this now is that it causes problems for the
| > 3-release policy
| >
| (https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fprime.haske
| ll.org%2fwiki%2fLibraries%2f3-Release-
| Policy&data=01%7c01%7csim

RE: type error formatting

[Simon Peyton Jones]

I’m all for it.   Can advise.  (Make a ticket.)

Thanks!

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Evan Laforge
Sent: 24 October 2015 03:48
To: GHC users
Subject: type error formatting

Here's a typical simple type error from GHC:

Derive/Call/India/Pakhawaj.hs:142:62:
Couldn't match type ‘Text’ with ‘(a1, Syllable)’
Expected type: [([(a1, Syllable)], [Sequence Bol])]
  Actual type: [([Syllable], [Sequence Bol])]
Relevant bindings include
  syllables :: [(a1, Syllable)]
(bound at Derive/Call/India/Pakhawaj.hs:141:16)
  best_match :: [(a1, Syllable)]
-> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)]))
(bound at Derive/Call/India/Pakhawaj.hs:141:5)
In the second argument of ‘mapMaybe’, namely ‘all_bols’
In the second argument of ‘($)’, namely
  ‘mapMaybe (match_bols syllables) all_bols’

I've been having more trouble than usual reading GHC's errors, and I finally 
spent some time to think about it.  The problem is that this new "relevant 
bindings include" section gets in between the expected and actual types (I 
still don't like that wording but I've gotten used to it), which is the most 
critical part, and the location context, which is second most critical.  Notice 
the same effect in the previous sentence :)  After I see a type error the next 
thing I want to see is the where it happened, so I have to skip over the 
bindings, which can be long and complicated.  Then I usually know what to do, 
and only look into the bindings if something more complicated is going on, like 
wonky inference.  So how about reordering the message:

Derive/Call/India/Pakhawaj.hs:142:62:
Couldn't match type ‘Text’ with ‘(a1, Syllable)’
Expected type: [([(a1, Syllable)], [Sequence Bol])]
  Actual type: [([Syllable], [Sequence Bol])]
In the second argument of ‘mapMaybe’, namely ‘all_bols’
In the second argument of ‘($)’, namely
  ‘mapMaybe (match_bols syllables) all_bols’
Relevant bindings include
  syllables :: [(a1, Syllable)]
(bound at Derive/Call/India/Pakhawaj.hs:141:16)
  best_match :: [(a1, Syllable)]
-> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)]))
(bound at Derive/Call/India/Pakhawaj.hs:141:5)

After this, why not go one step further and set off the various sections 
visibly to make it easier to scan.  The context section can also be really long 
if it gets an entire do block or record:

Derive/Call/India/Pakhawaj.hs:142:62:
  * Couldn't match type ‘Text’ with ‘(a1, Syllable)’
Expected type: [([(a1, Syllable)], [Sequence Bol])]
  Actual type: [([Syllable], [Sequence Bol])]
  * In the second argument of ‘mapMaybe’, namely ‘all_bols’
In the second argument of ‘($)’, namely
  ‘mapMaybe (match_bols syllables) all_bols’
  * Relevant bindings include
  syllables :: [(a1, Syllable)]
(bound at Derive/Call/India/Pakhawaj.hs:141:16)
  best_match :: [(a1, Syllable)]
-> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)]))
(bound at Derive/Call/India/Pakhawaj.hs:141:5)

Or alternately, taking up a bit more vertical space:

Derive/Call/India/Pakhawaj.hs:142:62:
Couldn't match type ‘Text’ with ‘(a1, Syllable)’
Expected type: [([(a1, Syllable)], [Sequence Bol])]
  Actual type: [([Syllable], [Sequence Bol])]
-
In the second argument of ‘mapMaybe’, namely ‘all_bols’
In the second argument of ‘($)’, namely
  ‘mapMaybe (match_bols syllables) all_bols’
-
Relevant bindings include
  syllables :: [(a1, Syllable)]
(bound at Derive/Call/India/Pakhawaj.hs:141:16)
  best_match :: [(a1, Syllable)]
-> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)]))
(bound at Derive/Call/India/Pakhawaj.hs:141:5)

Thoughts?  It seems simple enough that I could do myself, but of course not 
without buy-in.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: tweaking text on the ghc downloads page

[Simon Peyton Jones]

I’m ok with all of this, but I’d like just to check with Mark L to see how he 
suggests signposting the HP

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Michael Snoyman
Sent: 26 June 2015 15:59
To: Gershom B; Glasgow-Haskell-Users users
Subject: Re: tweaking text on the ghc downloads page

One point I've seen users confused about in the past is that some guides 
recommend downloading GHC directly as part of setting up a full distribution, 
e.g.:

https://www.haskell.org/downloads/linux (manual install)
I'd take the STOP out entirely, and just give a link to the /downloads page, to 
avoid this confusion. The rest of your text looks spot on to me, it's literally 
the one word "STOP" that seems to have people out of sorts most often.

On Fri, Jun 26, 2015 at 5:54 PM Gershom B 
mailto:gersh...@gmail.com>> wrote:
I know there is a plan for some broader ghc webpage redesign.

In the meantime, apparently people find the current "Stop" text terribly 
troublesome. This is because, of course, it points to the platform and now some 
people believe that a minimal distribution is more usable, etc.

Just to take this issue off the agenda, I would like, if there are no 
objections, to just change that text as follows.

Current:

"Stop!

For most users, we recommend installing the _Haskell Platform_ instead of GHC. 
The current Haskell Platform release includes a recent GHC release as well as 
some other tools (such as cabal), and a larger set of libraries that are known 
to work together."

Proposed:

"Stop!

For most users, we recommend installing _a proper distribution_ instead of just 
GHC. A distribution includes a recent GHC release as well as other important 
tools (such as cabal, for installing libraries), and potentially a broader set 
of libraries known to work together."

And where before the "Haskell Platform" text would link to of course the 
platform page, the new "proper distribution" text would now link to 
https://www.haskell.org/downloads where we could then argue to our heart's 
content about the best way to present the various download and installation 
options as we go forward.

So, this doesn't resolve any controversy, but it at least centralizes it.

If there's no objection, I'll try to get to this tomorrow?

--Gershom
___
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: overlapping instances in 7.10.1

[Simon Peyton Jones]

|  This is why I think that  ghc-7.8.3  treats the OI notion in a more
|  natural way than ghc-7.10.1 does.
|  May be, ghc-7.10.1 has a better technical tool for this, but  ghc-
|  7.8.3 corresponds to a natural notion of OI.
|  
|  Can GHC return to a natural OI notion?
|  Or am I missing something?

Well it all depends what you mean by "natural". To me it is profoundly 
un-natural to deliberately have the same type-class constraint solved in two 
different ways in the same program!

To require this would prevent cross-module specialisation. If I have
f :: C a => a -> a
in one module, and I specialise it to
f_spec :: [Int] -> [Int]
in one module, I want to be free to re-use that specialisation in other 
modules.  But under your "natural" story, I cannot do that, because (C [Int]) 
might be resolved differently there.

I'd be interested in what others think.  I've started
https://ghc.haskell.org/trac/ghc/ticket/10526
to collect these points.

Meanwhile, Sergei, it's clear how to fix docon, so you are no longer stuck.

Simon

|  
|  
|  
|  >   I bet that this is not what you intend. This may be a latent bug
|  in
|  > DoCon.
|  
|  If I am not missing anything in my above discourse, then DoCon is all
|  right at this point.
|  
|  
|  > I solved the problem by combining PFact__ and RsePol_ into a single
|  > module.  Then everything works fine.
|  
|  I think that this approach will generally lead to great difficulties
|  in
|  composing an application.
|  
|  Please, consider my above explanation and tell me whether I am missing
|  something.
|  
|  Regards,
|  
|  --
|  Sergei
|  
|  
|  
|  > What are the general lessons here?
|  >
|  >GHC generally assumes that if it generates (C T) in one
|  place,
|  > then it can use that anywhere in the program that (C T) is needed.
|  > That is, there is only one (C T) dictionary.
|  >
|  >
|  > ·   But suppose you have overlapping instance in different
|  > modules; say
|  >
|  > module A where instance C [a]
|  >
|  > module B where import A; instance C [Maybe a]
|  >
|  > If you use (C [Maybe Int]) in A, then of course we won’t see the
|  > instance in B.  So you’ll get a different dictionary than if you
|  > compute C [Maybe Int] in module B.
|  >
|  >
|  >
|  > In short, overlapping instances are OK, but it’s best to put them in
|  > the same module as the instances they overlap.
|  >
|  >
|  >
|  > Could GHC behave as if all instances were calculated afresh in the
|  > module being compiled.  Yes, of course it could, but at the cost of
|  > losing the benefit of cross-module specialisation.  An overloaded
|  > function specialised at, say, [Int] in one module could not be re-
|  used
|  > in another in case the instances changed.
|  >
|  >
|  >
|  > Simon
|  >
|  >
|  
|  > | -Original Message-
|  > | From: ghc-tickets [mailto:ghc-tickets-boun...@haskell.org] On
|  Behalf
|  > Of
|  > | Sergei Meshveliani
|  > | Sent: 23 May 2015 22:08
|  > | To: glasgow-haskell-users@haskell.org
|  > | Cc: glasgow-haskell-b...@haskell.org
|  > | Subject: overlapping instances in 7.10.1
|  
|  > | Dear GHC developers,
|  > |
|  > | This request overrides my previous one of  "7.10.1-err..."
|  > | (it is simpler and more precise).
|  > | The archive
|  
|  > | http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-
|  errReport-
|  > | may23-2015.zip
|  > |
|  > | presents a question about  ghc-7.10.1.
|  >
|  > | Make it, please, with  ghc-7.10.1  by
|  
|  > |  ghc $doconCpOpt -O --make Main
|  > | ,
|  > | $doconCpOpt =
|  
|  > |  -fwarn-unused-matches -fwarn-unused-binds -fwarn-unused-imports
|  > |  -fno-warn-overlapping-patterns -XRecordWildCards -XNamedFieldPuns
|  > |  -XFlexibleContexts -XMultiParamTypeClasses -XUndecidableInstances
|  > |  -XTypeSynonymInstances -XFlexibleInstances -fcontext-stack=30
|  >
|  > |
|  > | as it is written there in  README.txt.
|  > | README.txt  explains which two instances are wrongly resolved
|  > | -- as I expect.
|  
|  > | In  ghc-7.8.2  they are resolved in a correct way
|  > | (and there is a different pragma syntax).
|  > | I conclude this from running the test in  docon-2.12.
|  
|  > | Am I missing something?
|  > | Please, advise,
|  
|  > | --
|  > | Sergei
|  

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

RE: overlapping instances in 7.10.1

[Simon Peyton Jones]

Sergei



I finally found time to look into what is happening here.  It's a good 
illustration of the dangers of overlapping instances.  Here is the setup:



* Module ResEuc_

  * Contains

instance (...)=> Ring  (ResidueE a)  < (A)

instance (..., Ring (ResidueE a)) => Field (ResidueE a)  < (B)



* Module PFact__

  * Imports Pgcd_, which imports ResEuc_

  * Contains code that needs

   (Field (ResidueE (UPol (ResidueE Integer  <-- (X)

  * To solve (X) we use instance (B) from ResEuc_

  * And hence we need to solve (Ring (ResidueE (UPol (ResidueE Integer

which we do using (A) but not (C)





* Module RsePol_

  * Imports PFact__

  * Contains the specialised instance

  instance (...) => Ring (ResidueE (UPol a)) <-- (C)

which overlaps instance (A)



* Module Main

  * Needs an instance for

   Field (ResidueE (UPol (Residue Integer)))  <-- (Y)



  * Although GHC *could* generate this by instance declarations,

which it would do using (B) and then using (C),



instead GHC cleverly sees that it has generated it before,

in module PFact__, and so uses the one from PFact__. And

that is what gives rise to your error



So the real problem is that in PFact__, we make an instance (X) that does not 
see the specialised instance (C).  It *cannot* see that instance because 
RsePol_ imports PFact__.  So whatever code uses (X) is not going to see the 
specialised instance.  I bet that this is not what you intend. This may be a 
latent bug in DoCon.



I solved the problem by combining PFact__ and RsePol_ into a single module.  
Then everything works fine.



What are the general lessons here?



*GHC generally assumes that if it generates (C T) in one place, then it 
can use that anywhere in the program that (C T) is needed.  That is, there is 
only one (C T) dictionary.



*But suppose you have overlapping instance in different modules; say

module A where instance C [a]

module B where import A; instance C [Maybe a]

If you use (C [Maybe Int]) in A, then of course we won't see the instance in B. 
 So you'll get a different dictionary than if you compute C [Maybe Int] in 
module B.



In short, overlapping instances are OK, but it's best to put them in the same 
module as the instances they overlap.



Could GHC behave as if all instances were calculated afresh in the module being 
compiled.  Yes, of course it could, but at the cost of losing the benefit of 
cross-module specialisation.  An overloaded function specialised at, say, [Int] 
in one module could not be re-used in another in case the instances changed.



Simon



| -Original Message-

| From: ghc-tickets [mailto:ghc-tickets-boun...@haskell.org] On Behalf Of

| Sergei Meshveliani

| Sent: 23 May 2015 22:08

| To: glasgow-haskell-users@haskell.org

| Cc: glasgow-haskell-b...@haskell.org

| Subject: overlapping instances in 7.10.1

|

| Dear GHC developers,

|

| This request overrides my previous one of  "7.10.1-err..."

| (it is simpler and more precise).

| The archive

|

| 
http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport-

| 
may23-2015.zip

|

| presents a question about  ghc-7.10.1.

|

| Make it, please, with  ghc-7.10.1  by

|

|  ghc $doconCpOpt -O --make Main

| ,

| $doconCpOpt =

|  -fwarn-unused-matches -fwarn-unused-binds -fwarn-unused-imports

|  -fno-warn-overlapping-patterns -XRecordWildCards -XNamedFieldPuns

|  -XFlexibleContexts -XMultiParamTypeClasses -XUndecidableInstances

|  -XTypeSynonymInstances -XFlexibleInstances -fcontext-stack=30

|

|

| as it is written there in  README.txt.

|

| README.txt  explains which two instances are wrongly resolved

| -- as I expect.

|

| In  ghc-7.8.2  they are resolved in a correct way

| (and there is a different pragma syntax).

| I conclude this from running the test in  docon-2.12.

|

| Am I missing something?

|

| Please, advise,

|

| --

| Sergei

|

|

|

|

| ___

| ghc-tickets mailing list

| ghc-tick...@haskell.org

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

7.10 branch

[Simon Peyton Jones]

Austin
I'm getting these validation failures on the 7.10 branch. Are you?  This is on 
Linux.
Simon

Unexpected failures:

   driverT8959a [bad stderr] (normal)

   ghci/scripts  T9878b [bad stderr] (ghci)

   thT10279 [stderr mismatch] (normal)



Unexpected stat failures:

   perf/should_run  T4830 [stat not good enough] (normal)

   perf/should_run  T7436 [stat not good enough] (normal)
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: Closed Type Families: separate instance groups?

[Simon Peyton Jones]

I think it's pretty good as-is.

* Use an open family (with non-overlapping instances) to get yourself
  into part of the match space:
 type instance OpenF (Foo b c) = FFoo (Foo b c)

* Use a closed family (with overlap and top-to-bottom matching) to
  deal with that part of the space:
  type family FFoo a where
 FFoo (Foo Int c) = ...

Doing this was a HUGE improvement, allowing us to cleanly split the
issues of top-to-bottom matching from those of non-overlapping open
families. 

|  It also BTW cuts us off from using Closed Families as Associated types
|  separated into their Class instances.

I don't understand this comment. Can you give an example that the current setup 
does not handle?

Simon


|  -Original Message-
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  boun...@haskell.org] On Behalf Of AntC
|  Sent: 04 June 2015 01:54
|  To: glasgow-haskell-users@haskell.org
|  Subject: Re: Closed Type Families: separate instance groups?
|  
|  > Richard Eisenberg  cis.upenn.edu> writes:
|  >
|  > You can always define a helper closed type family and have an open
|  > type family instance just call a closed type family.
|  
|  Thank you Richard, you mean like:
|  
|  type family OpenF a
|  
|  ...
|  
|  type instance OpenF (Foo b c) = FFoo (Foo b c)
|  type family FFoo a where
|FFoo (Foo Int c) = ...
|...
|  
|  OK. (Seems rather verbose.)
|  
|  >
|  > Having closed type families, as opposed to branched instances, just
|  > seemed like a cleaner way to package the new functionality.
|  > There really wasn't much to it other than aesthetics, if I recall
|  the
|  > conversations correctly.
|  
|  I recall the conversation quite well.
|  (In fact I think it was me who suggested type family ... where ... ) I
|  think it was less to do with aesthetics, and more to do with reducing
|  verbosity in a common use case.
|  
|  It somehow doesn't seem as clean as old-fashioned overlapping
|  instances.
|  (I agree it does seem cleaner than overlaps with FunDeps.)
|  
|  It also BTW cuts us off from using Closed Families as Associated types
|  separated into their Class instances.
|  I think there's two use cases going on:
|  - one where we want to see all the instances together
| that fits well to type family ... where ...
|  - t'other where we want everything to do with a type constructor
|  together
| that fits better with the separate instances
|  
|  AntC
|  
|  
|  
|  ___
|  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: Increased memory usage with GHC 7.10.1

[Simon Peyton Jones]

It would be amazingly helpful if someone (anyone) could diagnose a bit.

It may be a bug in GHC but it may also be a bug in the pragmas in a library.   
If someone can produce evidence for the former, I’ll gladly look at it.

Simon

From: Greg Weber [mailto:g...@gregweber.info]
Sent: 01 May 2015 16:01
To: Simon Peyton Jones
Cc: Paolino; George Colpitts; Manuel Chakravarty; 
glasgow-haskell-users@haskell.org
Subject: Re: Increased memory usage with GHC 7.10.1

We have observed issues with compile-time inlining taking much longer in newer 
versions of GHC in some cases
https://github.com/larskuhtz/toCaseFoldBuildTimes
This particular issue was reported to the text repo: 
https://github.com/bos/text/issues/116

On Fri, May 1, 2015 at 7:49 AM, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
It would be great if someone could

• create a ticket for Paolio

• investigate what is happening
This smaller test case uses Repa, so it’s not clear that GHC is doing anything 
wrong. Maybe repa is inlining too much?  We need insight.

Thanks

SImon

From: Glasgow-haskell-users 
[mailto:glasgow-haskell-users-boun...@haskell.org<mailto:glasgow-haskell-users-boun...@haskell.org>]
 On Behalf Of Paolino
Sent: 01 May 2015 15:30
To: George Colpitts
Cc: glasgow-haskell-users@haskell.org<mailto:glasgow-haskell-users@haskell.org>
Subject: Re: Increased memory usage with GHC 7.10.1

here is another file , which is small, which cannot be compiled within 4GB  
memory.

https://raw.githubusercontent.com/benl23x5/gloss/master/gloss-examples/raster/Fluid/src-repa/Stage/Linear.hs
I'd just want to add that this problem is a nasty one if one doesn't set the 
max heap: a remote machine frozen that must be rebooted is not a nice adventure 
, hoping the crash remains confined to the vm.
hth, paolino



2015-05-01 15:31 GMT+02:00 George Colpitts 
mailto:george.colpi...@gmail.com>>:
Should we recommend that all library developers compile their libraries with a 
max heap of 4G (to pick an arbitrary number) so that we can catch some of these 
issues earlier?

On Fri, May 1, 2015 at 5:42 AM, Paolino 
mailto:paolo.verone...@gmail.com>> wrote:
Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible with 
-O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host. The file 
making memory explode is  
Graphics.Rendering.OpenGL.Raw.Functions<https://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rendering-OpenGL-Raw-Functions.html>.
 With -O0 it uses 600 MB.
The file is really huge, but I could compile it with prior versions of ghc.
Regards
paolino

2015-04-17 1:33 GMT+02:00 David Laing 
mailto:dave.laing...@gmail.com>>:
Hi all,
I've been playing around with profiling GHC recently, so I thought I'd chime in 
with a pointer that might save people searching for the right docs - you could 
configure a cabal sandbox to work with multiple version of ghc, which I've 
found useful:

https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage

Cheers,

Dave

On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta 
mailto:michal.terep...@gmail.com>> wrote:
Hi Richard,

Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with build 
flavor 'prof' then get the haskell-src-exts sources, install the dependencies 
and finally add +RTS -p -RTS to the cabal file and compile it, the resulting 
ghc.prof contains the profiling information.

For anyone interested about CallArity slowness, the problem is tracked in 
https://ghc.haskell.org/trac/ghc/ticket/10293

Cheers,
Michal

On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg 
mailto:e...@cis.upenn.edu>> wrote:
I've pasted Michal's numbers in #9630, which seems like a good place to track 
this. Michal, would you mind fleshing out a bit precisely what you did to get 
those numbers? That would be helpful (though you've already been very helpful 
indeed in getting the data together)!

Thanks,
Richard

On Apr 14, 2015, at 9:09 PM, Joachim Breitner 
mailto:m...@joachim-breitner.de>> wrote:

> Hi,
>
> Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta:
>> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij
>> mailto:christiaan.ba...@gmail.com>> wrote:
>>> Actually, I meant only with -fno-specialise.
>>
>> Done. Helps quite a bit but CallArity is still a pretty expensive.
>
> I’m on that, and I think I have a quite neat fix for it. I’ll report on
> that in the trac ticket:
> https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4
>
> Greetings,
> Joachim
>
> --
> Joachim “nomeata” Breitner
>  m...@joachim-breitner.de<mailto:m...@joachim-breitner.de> • 
> http://www.joachim-breitner.de/
>  Jabber: nome...@joachim-breitner.de<mailto:nome...@joachim-breitner.de>  • 
> GPG-Key: 0xF0FBF51F
>

RE: Increased memory usage with GHC 7.10.1

[Simon Peyton Jones]

It would be great if someone could

· create a ticket for Paolio

· investigate what is happening
This smaller test case uses Repa, so it’s not clear that GHC is doing anything 
wrong. Maybe repa is inlining too much?  We need insight.

Thanks

SImon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Paolino
Sent: 01 May 2015 15:30
To: George Colpitts
Cc: glasgow-haskell-users@haskell.org
Subject: Re: Increased memory usage with GHC 7.10.1

here is another file , which is small, which cannot be compiled within 4GB  
memory.

https://raw.githubusercontent.com/benl23x5/gloss/master/gloss-examples/raster/Fluid/src-repa/Stage/Linear.hs

I'd just want to add that this problem is a nasty one if one doesn't set the 
max heap: a remote machine frozen that must be rebooted is not a nice adventure 
, hoping the crash remains confined to the vm.
hth, paolino



2015-05-01 15:31 GMT+02:00 George Colpitts 
mailto:george.colpi...@gmail.com>>:
Should we recommend that all library developers compile their libraries with a 
max heap of 4G (to pick an arbitrary number) so that we can catch some of these 
issues earlier?

On Fri, May 1, 2015 at 5:42 AM, Paolino 
mailto:paolo.verone...@gmail.com>> wrote:
Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible with 
-O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host. The file 
making memory explode is  
Graphics.Rendering.OpenGL.Raw.Functions.
 With -O0 it uses 600 MB.
The file is really huge, but I could compile it with prior versions of ghc.
Regards
paolino

2015-04-17 1:33 GMT+02:00 David Laing 
mailto:dave.laing...@gmail.com>>:
Hi all,
I've been playing around with profiling GHC recently, so I thought I'd chime in 
with a pointer that might save people searching for the right docs - you could 
configure a cabal sandbox to work with multiple version of ghc, which I've 
found useful:

https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage

Cheers,

Dave

On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta 
mailto:michal.terep...@gmail.com>> wrote:
Hi Richard,

Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with build 
flavor 'prof' then get the haskell-src-exts sources, install the dependencies 
and finally add +RTS -p -RTS to the cabal file and compile it, the resulting 
ghc.prof contains the profiling information.

For anyone interested about CallArity slowness, the problem is tracked in 
https://ghc.haskell.org/trac/ghc/ticket/10293

Cheers,
Michal

On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg 
mailto:e...@cis.upenn.edu>> wrote:
I've pasted Michal's numbers in #9630, which seems like a good place to track 
this. Michal, would you mind fleshing out a bit precisely what you did to get 
those numbers? That would be helpful (though you've already been very helpful 
indeed in getting the data together)!

Thanks,
Richard

On Apr 14, 2015, at 9:09 PM, Joachim Breitner 
mailto:m...@joachim-breitner.de>> wrote:

> Hi,
>
> Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta:
>> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij
>> mailto:christiaan.ba...@gmail.com>> wrote:
>>> Actually, I meant only with -fno-specialise.
>>
>> Done. Helps quite a bit but CallArity is still a pretty expensive.
>
> I’m on that, and I think I have a quite neat fix for it. I’ll report on
> that in the trac ticket:
> https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4
>
> Greetings,
> Joachim
>
> --
> Joachim “nomeata” Breitner
>  m...@joachim-breitner.de • 
> http://www.joachim-breitner.de/
>  Jabber: nome...@joachim-breitner.de  • 
> GPG-Key: 0xF0FBF51F
>  Debian Developer: nome...@debian.org
> ___
> 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

___
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


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org

RE: Increased memory usage with GHC 7.10.1

[Simon Peyton Jones]

Can you open a ticket, please? And put as much data as you can.  Using 
`-dshow-passes` (both for 7.10 and prior versions) and showing the output would 
be helpful.

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Paolino
Sent: 01 May 2015 09:42
To: glasgow-haskell-users@haskell.org
Subject: Re: Increased memory usage with GHC 7.10.1

Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible with 
-O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host. The file 
making memory explode is  
Graphics.Rendering.OpenGL.Raw.Functions.
 With -O0 it uses 600 MB.
The file is really huge, but I could compile it with prior versions of ghc.
Regards
paolino

2015-04-17 1:33 GMT+02:00 David Laing 
mailto:dave.laing...@gmail.com>>:
Hi all,
I've been playing around with profiling GHC recently, so I thought I'd chime in 
with a pointer that might save people searching for the right docs - you could 
configure a cabal sandbox to work with multiple version of ghc, which I've 
found useful:

https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage

Cheers,

Dave

On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta 
mailto:michal.terep...@gmail.com>> wrote:
Hi Richard,

Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with build 
flavor 'prof' then get the haskell-src-exts sources, install the dependencies 
and finally add +RTS -p -RTS to the cabal file and compile it, the resulting 
ghc.prof contains the profiling information.

For anyone interested about CallArity slowness, the problem is tracked in 
https://ghc.haskell.org/trac/ghc/ticket/10293

Cheers,
Michal

On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg 
mailto:e...@cis.upenn.edu>> wrote:
I've pasted Michal's numbers in #9630, which seems like a good place to track 
this. Michal, would you mind fleshing out a bit precisely what you did to get 
those numbers? That would be helpful (though you've already been very helpful 
indeed in getting the data together)!

Thanks,
Richard

On Apr 14, 2015, at 9:09 PM, Joachim Breitner 
mailto:m...@joachim-breitner.de>> wrote:

> Hi,
>
> Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta:
>> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij
>> mailto:christiaan.ba...@gmail.com>> wrote:
>>> Actually, I meant only with -fno-specialise.
>>
>> Done. Helps quite a bit but CallArity is still a pretty expensive.
>
> I’m on that, and I think I have a quite neat fix for it. I’ll report on
> that in the trac ticket:
> https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4
>
> Greetings,
> Joachim
>
> --
> Joachim “nomeata” Breitner
>  m...@joachim-breitner.de • 
> http://www.joachim-breitner.de/
>  Jabber: nome...@joachim-breitner.de  • 
> GPG-Key: 0xF0FBF51F
>  Debian Developer: nome...@debian.org
> ___
> 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

___
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

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

RE: SIMD

[Simon Peyton Jones]

Geoff Mainland is the originator of the SIMD instruction set work.  Let’s see 
what he says.

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Dominic Steinitz
Sent: 11 April 2015 17:45
To: GHC users
Subject: SIMD

What’s the story with this? I tried to follow the instructions here: 
https://ghc.haskell.org/trac/ghc/wiki/SIMD but I get

~ $ git clone -b simd http://git.haskell.org/ghc.git
Cloning into 'ghc'...
fatal: Remote branch simd not found in upstream origin

Dominic Steinitz
domi...@steinitz.org
http://idontgetoutmuch.wordpress.com

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

RE: Typed splices and type checking

[Simon Peyton Jones]

Good question!  See https://ghc.haskell.org/trac/ghc/ticket/10271.

Simon

| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of J. Garrett Morris
| Sent: 27 March 2015 14:30
| To: GHC users
| Subject: Typed splices and type checking
| 
| Hello,
| 
| I've run into another misunderstanding with Template Haskell and typed
| splices.  For example, I was hoping to use typed splices to generate
| earlier errors from Printf.  Here's the world's least handy printf:
| 
| > class Printf t
| > where printf :: String -> Q (TExp String) -> Q (TExp t)
| >
| > instance Printf String
| > where printf s t | '%' `notElem` s = [|| $$t ++ s ||]
| >  | otherwise   = fail ("Unexpected format %"
| >++ [c])
| >   where (_, _:c:_) = break ('%' ==) s
| >
| > instance Printf t => Printf (Char -> t)
| > where printf s t
| > | c /= 'c' = fail ("Unexpected format %" ++ [c] ++
| >" for character")
| > | otherwise = [|| \c -> $$(printf s''
| >  [|| $$t ++ s' ++ [c] ||])
| >||]
| >   where (s', '%':c:s'') = break ('%' ==) s
| 
| Now, consider these two definitions:
| 
| > f :: Char -> String
| > f = $$(printf "foo %c" [||""||])
| 
| > h :: Char -> String
| > h y = $$(printf "foo %c" [||""||]) y
| 
| I would have expected these to be equivalent, from a type checking
| perspective.  However, while the first types fine, the second generates
| the error message:
| 
| > Printing.hs:14:12:
| >No instance for (Printf t0) arising from a use of `printf'
| >The type variable `t0' is ambiguous
| >Note: there are several potential instances:
| >  instance Printf t => Printf (Char -> t)
| >-- Defined at Printf.hs:20:10
| >  instance Printf String -- Defined at Printf.hs:9:10
| >In the expression: printf "foo %c" [|| "" ||]
| >In the Template Haskell splice
| >  $$(printf "foo %c" [|| "" ||])
| >In the expression: $$(printf "foo %c" [|| "" ||])
| 
| Should I have anticipated this?  Ought the interaction of typed splices
| and eta-expansion be problematic?
| 
|  /g
| 
| --
| The University of Edinburgh is a charitable body, registered in
| Scotland, with registration number SC005336.
| 
| ___
| 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: Binary bloat in 7.10

[Simon Peyton Jones]

Just to check, can someone summarise the conclusion of this thread?  Was it all 
due to -fsplit-objs?  If so, should we add some notes to the user manual to 
explain what may happen if you use -fsplit-objs? What was the business about 
Cabal?

Simon

|  -Original Message-
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  boun...@haskell.org] On Behalf Of Jeremy
|  Sent: 05 April 2015 20:30
|  To: glasgow-haskell-users@haskell.org
|  Subject: Re: Binary bloat in 7.10
|  
|  Thomas Miedema wrote
|  > That suggestion was completely misguided. Compiling with `-split-objs`
|  > makes a library _grow_ in size, but makes executables that link
|  > against it _smaller_.
|  >
|  > All these numbers are not far off from the ones you were getting. I
|  > think you have been comparing a 7.8.4 build of Cabal without split
|  > objects, with a 7.10.1 build of Cabal with split objects.
|  >
|  > I don't think there is a bug here.
|  
|  My GHC build is now back to the 7.8-era size. Thank you!
|  
|  I was wondering why programs compiled with my GHC 7.8 build were bigger
|  than if I used an official build. Perhaps a bug in the 7.8 build system
|  had turned off SplitObjs.
|  
|  
|  
|  --
|  View this message in context:
|  http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-
|  tp5768067p5768274.html
|  Sent from the Haskell - Glasgow-haskell-users mailing list archive at
|  Nabble.com.
|  ___
|  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: Splices returning splices

[Simon Peyton Jones]

Currently it just isn't supported.  Suppose you say

f x = [| $(g y) |]

...$(f 3)

Does $(f 3) mean "run (f 3) returning some code with embedded splices, and then 
run those", or does it mean (as now) "call (f 3), and to do so run (g y) first, 
to generate some code that is spliced into the code returned by f"?

A quasiquoter is really a splice. That is [foo| blah |] is the same as $(foo 
"blah").  So it might be easier to discuss your question in the context of 
ordinary splices and quotes.  You want foo to return code with a splice, thus:

foo input_string = [| ...$(other_fun args) |]

But foo is in the Q monad anyway, so why not just run (other_fun args) right 
there in the quasiquoter?

Or perhaps make a tiny example to show what you mean (but not using 
quasiquotation).

Simon 

|  -Original Message-
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  boun...@haskell.org] On Behalf Of J. Garrett Morris
|  Sent: 23 March 2015 12:47
|  To: GHC users
|  Subject: Splices returning splices
|  
|  Hello,
|  
|  I'm attempting to write a quasiquoter with relatively full antiquotation
|  support.  In doing so, I've arrived at I think an odd problem: the
|  expression grammar in Language.Haskell.TH.Syntax doesn't seem to include
|  splices.  This seems to mean that my antiquotations can't themselves
|  include splices, which is quite limiting.  Am I misinterpreting?  The
|  type system in "Template metaprogramming for Haskell" seems to imply no
|  such restriction on the occurrences of splices.
|  
|  (As an additional complication: what I really need to do is return typed
|  splices; my "quasiquoter" relies on its expected type to determine its
|  behavior.  However, this seems like an uninteresting extension of the
|  above problem.)
|  
|  Thanks,
|  
|   /g
|  
|  --
|  The University of Edinburgh is a charitable body, registered in Scotland,
|  with registration number SC005336.
|  
|  ___
|  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: Qualified names in TH?

[Simon Peyton Jones]

What Edward says also applies to code quotations.  So, for example:


module M

import IntSet



f :: Q Exp -> Q Exp

f blah = [|  fromList $blah |]



module N where

 import M

 h x = $(f [| [x,x] |])

The splice expands to (fromList [x,x]), but the fromList guaranteed to be the 
fromList in scope where f is defined (in M), and NOT whatever other fromList 
might be in scope at the splice site in N.

Moreover, you do not need to import IntSet.

I hope that helps.  Would someone like to add a section to 
https://wiki.haskell.org/Template_Haskell, to explain?  There are several 
tutorials there as well.

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Edward Kmett
Sent: 17 March 2015 05:01
To: J. Garrett Morris
Cc: GHC users
Subject: Re: Qualified names in TH?

Using {-# LANGUAGE TemplateHaskell #-} you can use 'foo and ''Foo to get access 
to the names in scope in the module that is building the splice, rather than 
worrying about what names are in scope in the module the code gets spliced into.

-Edward

On Mon, Mar 16, 2015 at 10:54 PM, J. Garrett Morris 
mailto:garrett.mor...@ed.ac.uk>> wrote:
I'm trying to write some Template Haskell code that (among other
things) manipulates IntSets.  So, for example, I'd like a splice to
generate a call to Data.IntSet.fromList.  However, I'm not sure how
IntSet will be imported in the target module.  Is there a way to
resolve the fully qualified name (or similar) to a TH Name, without
having to know how it's imported in the splicing module?  (The obvious
approach---mkName "Data.IntSet.fromList"---seems not to work in GHC
7.8.)

Thanks!

 /g

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

___
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: [Haskell-cafe] GHC 7.10 Prelude: we need your opinion

[Simon Peyton Jones]

|  What were the objections? Especially the principle ones?

Please read the info pages, which set out the arguments quite carefully.

Also, I spammed several email lists to ensure broad coverage, but it'd be best 
to debate on the librar...@haskell.org, rather than reply-to-all; that's what 
it's for.  (Which I failed to send the announcement to!  I'll fix that.)

Simon

|  -Original Message-
|  From: Miguel Mitrofanov [mailto:miguelim...@yandex.ru]
|  Sent: 10 February 2015 15:59
|  To: Simon Peyton Jones; hask...@haskell.org; Haskell Cafe (haskell-
|  c...@haskell.org); GHC users; ghc-d...@haskell.org
|  Subject: Re: [Haskell-cafe] GHC 7.10 Prelude: we need your opinion
|  
|  What were the objections? Especially the principle ones?
|  
|  10.02.2015, 18:51, "Simon Peyton Jones" :
|  > Haskell Friends
|  >
|  > This email asks for your help in deciding how to proceed with some
|  Prelude changes in GHC 7.10.  Please read on, but all the info is also
|  at the survey link, here: http://goo.gl/forms/XP1W2JdfpX.   Deadline
|  is 21 Feb.
|  >
|  > The ​Core Libraries Committee (CLC) is responsible for developing the
|  core libraries that ship with GHC. This is an important but
|  painstaking task, and we owe the CLC a big vote of thanks for taking
|  it on.
|  >
|  > For over a year the CLC has been working on integrating the Foldable
|  and Traversable classes (shipped in base in GHC 7.8) into the core
|  libraries, and into the Prelude in particular. Detailed planning for
|  GHC 7.10 started in the autumn of 2014, and the CLC went ahead with
|  this integration.
|  >
|  > Then we had a failure of communication.  As these changes affect the
|  Prelude, which is in scope for all users of Haskell, these changes
|  should be held to a higher bar than the regular libraries@ review
|  process.  However, the Foldable/Traversable changes were not
|  particularly well signposted. Many people have only recently woken up
|  to them, and some have objected (both in principle and detail).
|  >
|  > This is an extremely unfortunate situation. On the one hand we are
|  at RC2 for GHC 7.10, so library authors have invested effort in
|  updating their libraries to the new Prelude. On the other, altering
|  the Prelude is in effect altering the language, something we take
|  pretty seriously. We should have had this debate back in 2014, but
|  here we are, and it is unproductive to argue about whose fault it is.
|  We all share responsibility.
|  >
|  > We need to decide what to do now. A small group of us met by Skype
|  and we've decided to do this:
|  >
|  > · Push back GHC 7.10's release by at least a month, to late
|  March.  This delay also gives us breathing space to address an
|  unrelated show-stopping bug, Trac #9858.
|  >
|  > · Invite input from the Haskell community on which of two
|  approaches to adopt (this survey).  The main questions revolve around
|  impact on the Haskell ecosystem (commercial applications, teaching,
|  libraries, etc etc), so we want to ask your opinion rather than guess
|  it.
|  >
|  > · Ask Simon Marlow and Simon Peyton Jones to decide which
|  approach to follow for GHC 7.10.
|  >
|  > Wiki pages have been created summarizing these two primary
|  alternatives, including many more points and counter-points and
|  technical details:
|  >
|  > · Overall summary:
|  https://ghc.haskell.org/trac/ghc/wiki/Prelude710
|  >
|  > · Details of Plan List:
|  https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List
|  >
|  > · Details of Plan FTP:
|  https://ghc.haskell.org/trac/ghc/wiki/Prelude710/FTP
|  >
|  > This survey invites your input on which plan we should follow. Would
|  you please
|  >
|  > · Read the details of the alternative plans on the three
|  wiki pages above
|  >
|  > · Add your response to the survey
|  >
|  > Please do read the background.  Well-informed responses will
|  help.  Thank you!
|  >
|  > DEADLINE: 21 February 2015
|  >
|  > Simon PJ
|  >
|  > ,
|  >
|  > ___
|  > Haskell-Cafe mailing list
|  > haskell-c...@haskell.org
|  > http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

GHC 7.10 Prelude: we need your opinion

[Simon Peyton Jones]

Haskell Friends
This email asks for your help in deciding how to proceed with some Prelude 
changes in GHC 7.10.  Please read on, but all the info is also at the survey 
link, here: http://goo.gl/forms/XP1W2JdfpX.   Deadline is 21 Feb.

The ​Core Libraries Committee (CLC) is responsible for developing the core 
libraries that ship with GHC. This is an important but painstaking task, and we 
owe the CLC a big vote of thanks for taking it on.

For over a year the CLC has been working on integrating the Foldable and 
Traversable classes (shipped in base in GHC 7.8) into the core libraries, and 
into the Prelude in particular. Detailed planning for GHC 7.10 started in the 
autumn of 2014, and the CLC went ahead with this integration.

Then we had a failure of communication.  As these changes affect the Prelude, 
which is in scope for all users of Haskell, these changes should be held to a 
higher bar than the regular libraries@ review process.  However, the 
Foldable/Traversable changes were not particularly well signposted. Many people 
have only recently woken up to them, and some have objected (both in principle 
and detail).

This is an extremely unfortunate situation. On the one hand we are at RC2 for 
GHC 7.10, so library authors have invested effort in updating their libraries 
to the new Prelude. On the other, altering the Prelude is in effect altering 
the language, something we take pretty seriously. We should have had this 
debate back in 2014, but here we are, and it is unproductive to argue about 
whose fault it is. We all share responsibility.

We need to decide what to do now. A small group of us met by Skype and we've 
decided to do this:

· Push back GHC 7.10's release by at least a month, to late March.  
This delay also gives us breathing space to address an unrelated show-stopping 
bug, Trac #9858.

· Invite input from the Haskell community on which of two approaches to 
adopt (this survey<http://goo.gl/forms/XP1W2JdfpX>).  The main questions 
revolve around impact on the Haskell ecosystem (commercial applications, 
teaching, libraries, etc etc), so we want to ask your opinion rather than guess 
it.

· Ask Simon Marlow and Simon Peyton Jones to decide which approach to 
follow for GHC 7.10.

Wiki pages have been created summarizing these two primary alternatives, 
including many more points and counter-points and technical details:

· Overall summary: 
https://ghc.haskell.org/trac/ghc/wiki/Prelude710<https://www.google.com/url?q=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fwiki%2FPrelude710&sa=D&sntz=1&usg=AFQjCNE1p5w-YCXC7ixebvwObayuV7Ut4w>

· Details of Plan List: 
https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List<https://www.google.com/url?q=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fwiki%2FPrelude710%2FList&sa=D&sntz=1&usg=AFQjCNHaufeSwtIsvZwdVXwP9F9G45zLSA>

· Details of Plan FTP: 
https://ghc.haskell.org/trac/ghc/wiki/Prelude710/FTP<https://www.google.com/url?q=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fwiki%2FPrelude710%2FFTP&sa=D&sntz=1&usg=AFQjCNHbhNyIwAbcOd3JfikIhD6S7rc-vw>

This survey invites your input on which plan we should follow. Would you please

· Read the details of the alternative plans on the three wiki pages 
above

· Add your response to the survey<http://goo.gl/forms/XP1W2JdfpX>

Please do read the background.  Well-informed responses will help.  Thank you!

DEADLINE: 21 February 2015
Simon PJ
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Proposal: ValidateMonoLiterals - Initial bikeshed discussion

[Simon Peyton Jones]

I'm all for it.  Syntax sounds like the main difficulty.  Today you could use 
quasiquotatoin
[even| 38 |]
and get the same effect as $$(validate 38).  But it's still noisy.

So: what is the non-noisy scheme you want to propose?  You don't quite get to 
that in the wiki page!

Simon

| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Merijn
| Verstraaten
| Sent: 05 February 2015 14:46
| To: ghc-d...@haskell.org; GHC users
| Subject: Proposal: ValidateMonoLiterals - Initial bikeshed discussion
| 
| I've been repeatedly running into problems with overloaded literals and
| partial conversion functions, so I wrote up an initial proposal
| (https://ghc.haskell.org/trac/ghc/wiki/ValidateMonoLiterals) and I'd like
| to commence with the bikeshedding and hearing other opinions :)
| 
| Cheers,
| Merijn
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Restricted Template Haskell

[Simon Peyton Jones]

Greg (and everyone else)

The TH documentation is even more woeful than I realised.  At the very least 
there should be a section for typed TH and a section for untyped TH in the 
manual.

If I volunteer to write it, it won’t get done.  I’m in too many inner loops.

But here’s an offer: if someone (or a little group) is willing to play author, 
I will review and correct. It could be a good way to learn the details!

Ideally it would be good to have a compact specification in the user manual, 
with more detail on the Haskell wiki (where it’s easier for people to 
edit/improve).  For the latter there is already a page 
here<https://wiki.haskell.org/Template_Haskell>.

I’d really appreciate help with this.

Simon

From: Greg Weber [mailto:g...@gregweber.info]
Sent: 03 February 2015 03:42
To: Simon Peyton Jones
Cc: ghc-d...@haskell.org; GHC users; David Terei; Maxwell Swadling
Subject: Re: Restricted Template Haskell

I would like to figure out how to improve the state of TTH documentation. The 
GHC wiki is usually for things that are changing, and the page is written in 
that future style, so it makes one wonder if all things are finished or if some 
things remain unfinished. Some "this is how it is" documentation in the user 
guide would seem more useful now.

But I am not sure if the user guide [1] is even correct because it indicates a 
type of `Q (TExp a)` where I would expect just `TExp a` from reading the wiki 
[2].

[1] 
https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/template-haskell.html
[2] https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/BlogPostChanges

On Mon, Feb 2, 2015 at 11:31 AM, Greg Weber 
mailto:g...@gregweber.info>> wrote:
Hi Simon,

I am just starting the proposal: gathering interested parties and pointers to 
related information.
Thanks for the pointer to Typed Template Haskell. I was actually unaware of the 
extent to which Typed Template Haskell is restricted. I have not seen any usage 
of Typed Template Haskell in the wild or been able to use it myself 
unfortunately due to backwards compatibility needs (once the next GHC release 
is out libraries will start to consider dropping 7.6 support and we will see 
more usage, although Ubuntu still ships 7.6 by default).
I will study Typed Template Haskell.

Greg Weber

On Mon, Feb 2, 2015 at 9:33 AM, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
The new TH is already split into two 
parts<https://ghc.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal> as 
I’m sure you know

• Typed TH is for expressions only, and doesn’t have reify, nor any Q 
monad.

• Untyped TH is the wild west

Typed TH may get some of what you want?   Certainly you want to acknowledge the 
existing split in your own design.

The proposal could do with examples to illustrate what the difficulties are.  
What bad things happen in the Q monad?  Can you give examples of reasoning that 
would be valid in level 1 but not in level 2.  etc.  More precision please!

Simon

From: Glasgow-haskell-users 
[mailto:glasgow-haskell-users-boun...@haskell.org<mailto:glasgow-haskell-users-boun...@haskell.org>]
 On Behalf Of Greg Weber
Sent: 30 January 2015 23:39
To: ghc-d...@haskell.org<mailto:ghc-d...@haskell.org>; GHC users
Cc: David Terei; Maxwell Swadling
Subject: Restricted Template Haskell

Hello GHC friends!

I am starting up a proposal for variants of Template Haskell that restrict what 
operations are available. The goal is to make TH easier for users to reason 
about and to allow for an easier compilation story.

Here is the proposal page:
https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Restricted

Right now the proposal does not have any details and the goal is to write out a 
clear specification.
If this sounds interesting to you, let me know or leave some feedback on the 
wiki.


Thanks,
Greg Weber




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

RE: Restricted Template Haskell

[Simon Peyton Jones]

The new TH is already split into two 
parts as 
I’m sure you know

· Typed TH is for expressions only, and doesn’t have reify, nor any Q 
monad.

· Untyped TH is the wild west

Typed TH may get some of what you want?   Certainly you want to acknowledge the 
existing split in your own design.

The proposal could do with examples to illustrate what the difficulties are.  
What bad things happen in the Q monad?  Can you give examples of reasoning that 
would be valid in level 1 but not in level 2.  etc.  More precision please!

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Greg Weber
Sent: 30 January 2015 23:39
To: ghc-d...@haskell.org; GHC users
Cc: David Terei; Maxwell Swadling
Subject: Restricted Template Haskell

Hello GHC friends!

I am starting up a proposal for variants of Template Haskell that restrict what 
operations are available. The goal is to make TH easier for users to reason 
about and to allow for an easier compilation story.

Here is the proposal page:
https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Restricted

Right now the proposal does not have any details and the goal is to write out a 
clear specification.
If this sounds interesting to you, let me know or leave some feedback on the 
wiki.


Thanks,
Greg Weber


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

RE: stream fusion, concatMap, exisential seed unboxing

[Simon Peyton Jones]

Ah, well, if it's really the concat/concatMap problem then I'm really not sure 
how to crack it.  

But there are lots of smart people on this list, so maybe someone else can.

The fewer dependencies your test case has the better.  eg Don't use criterion; 
this stuff is huge: you get 10G of allocation in your test run instead of 10M.  
 Or something.

Simon

|  -Original Message-
|  From: Christian Höner zu Siederdissen
|  [mailto:choe...@tbi.univie.ac.at]
|  Sent: 02 February 2015 16:02
|  To: Simon Peyton Jones
|  Cc: Glasgow-Haskell-Users
|  Subject: Re: stream fusion, concatMap, exisential seed unboxing
|  
|  Sure, no problem!
|  
|  Btw. this is not a 'bug' in the usual sense. It is the (neverending)
|  concatMap + stream fusion story.
|  https://ghc.haskell.org/trac/ghc/ticket/915
|  I'm playing a bit with trying to get GHC to look through the
|  existential seed elements and have it constructor-specialize them.
|  
|  Unfortunately, unbox/spec fails with more complex seeds for now. For
|  the more simple cases like the one below, the extra strictness pass
|  works (cool, thanks!). These are sometimes enough if you have just
|  concatMap (\i -> [i .. j]) stuff.
|  
|  However, if the internal stream state is, say, a pair (i,j), then one
|  of those is not completely unboxed. I guess that *if* we could get the
|  passes to continue unbox'ing and ctor-spec'ing, we could end up with a
|  fully fused concatMap.
|  
|  I'll put a complete git repository with criterion + quickcheck modules
|  up (soonishly ;-).
|  
|  Viele Gruesse,
|  Christian
|  
|  * Simon Peyton Jones  [02.02.2015 15:49]:
|  > I think it'd help you to open a Trac ticket, give a fully-
|  reproducible test case, including instructions for how to reproduce,
|  and say what isn't happening that should happen.
|  >
|  > What's odd is that loop_s29q looks strict in its Int arg, yet isn't
|  unboxed.  There is a way to get the strictness analysis to run twice -
|  flate-dmd-anal.  You could try that.
|  >
|  > Simon
|  >
|  > |  -Original Message-
|  > |  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  > | boun...@haskell.org] On Behalf Of Christian Höner zu Siederdissen
|  > |  Sent: 01 February 2015 12:18
|  > |  To: Glasgow-Haskell-Users
|  > |  Subject: stream fusion, concatMap, exisential seed unboxing
|  > |
|  > |  Hi everybody,
|  > |
|  > |  I'm playing around with concatMap in stream fusion (the vector
|  > | package  to be exact).
|  > |
|  > |  concatMapM :: Monad m => (a->m (Stream m b)) -> Stream m a ->
|  > | Stream m  b concatMapM f (Stream ...) = ...
|  > |
|  > |  I can get my concatMap to behave nicely and erase all Stream and
|  > | Step  constructors but due to the existential nature of the Stream
|  > | seeds,  they are re-boxed for the inner stream (which is kind-of
|  > | annoying  given that the seed is immediately unboxed again ;-).
|  seq
|  > | doesn't help  here.
|  > |
|  > |  Otherwise, fusion happens for streams and vectors, so that is ok.
|  > | But  boxing kills performance, criterion says.
|  > |
|  > |  Do we have s.th. in place that could help here? Currently I could
|  > | use  the vector-concatMap which creates intermediate arrays, my
|  > | version  which has boxed seeds, or hermit but that is too
|  > | inconvenient for non-  ghc savy users.
|  > |
|  > |  Viele Gruesse,
|  > |  Christian
|  > |
|  > |
|  > |
|  > |  Fusing concatMapM:
|  > |
|  > |  concatMapM f (SM.Stream ostep t _) = SM.Stream step (Left t)
|  Unknown
|  > |where step (Left t) = do r <- ostep t
|  > | case r of
|  > |  SM.Done   -> return $ SM.Done
|  > |  SM.Skipt' -> return $ SM.Skip
|  (Left
|  > |  t')
|  > |  SM.Yield a t' -> do s <- f a
|  > |  return $ SM.Skip
|  > | (Right (s,t'))
|  > |  step (Right (SM.Stream istep s _,t)) = do r <- istep s
|  > |case r of
|  > |  SM.Done
|  ->
|  > |  return $ SM.Skip(Left t)
|  > |  SM.Skips'
|  ->
|  > |  return $ SM.Skip(Right (SM.Stream istep s' Unknown,t))
|  > |  SM.Yield x s'
|  > | ->  return $ SM.Yield x (Right (SM.Stream istep s' Unknown,t))
|  > |  {-# INLINE [0] step #-}
|  > |  {-# INLINE [1] concatMapM #-}
|  > |
|  > |  testConcatMapM :: Int -> Int
|  > |  testConcatMapM k = seq k $ U.unId

RE: stream fusion, concatMap, exisential seed unboxing

[Simon Peyton Jones]

I think it'd help you to open a Trac ticket, give a fully-reproducible test 
case, including instructions for how to reproduce, and say what isn't happening 
that should happen. 

What's odd is that loop_s29q looks strict in its Int arg, yet isn't unboxed.  
There is a way to get the strictness analysis to run twice -flate-dmd-anal.  
You could try that.

Simon

|  -Original Message-
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  boun...@haskell.org] On Behalf Of Christian Höner zu Siederdissen
|  Sent: 01 February 2015 12:18
|  To: Glasgow-Haskell-Users
|  Subject: stream fusion, concatMap, exisential seed unboxing
|  
|  Hi everybody,
|  
|  I'm playing around with concatMap in stream fusion (the vector package
|  to be exact).
|  
|  concatMapM :: Monad m => (a->m (Stream m b)) -> Stream m a -> Stream m
|  b concatMapM f (Stream ...) = ...
|  
|  I can get my concatMap to behave nicely and erase all Stream and Step
|  constructors but due to the existential nature of the Stream seeds,
|  they are re-boxed for the inner stream (which is kind-of annoying
|  given that the seed is immediately unboxed again ;-). seq doesn't help
|  here.
|  
|  Otherwise, fusion happens for streams and vectors, so that is ok. But
|  boxing kills performance, criterion says.
|  
|  Do we have s.th. in place that could help here? Currently I could use
|  the vector-concatMap which creates intermediate arrays, my version
|  which has boxed seeds, or hermit but that is too inconvenient for non-
|  ghc savy users.
|  
|  Viele Gruesse,
|  Christian
|  
|  
|  
|  Fusing concatMapM:
|  
|  concatMapM f (SM.Stream ostep t _) = SM.Stream step (Left t) Unknown
|where step (Left t) = do r <- ostep t
| case r of
|  SM.Done   -> return $ SM.Done
|  SM.Skipt' -> return $ SM.Skip (Left
|  t')
|  SM.Yield a t' -> do s <- f a
|  return $ SM.Skip
|  (Right (s,t'))
|  step (Right (SM.Stream istep s _,t)) = do r <- istep s
|case r of
|  SM.Done   ->
|  return $ SM.Skip(Left t)
|  SM.Skips' ->
|  return $ SM.Skip(Right (SM.Stream istep s' Unknown,t))
|  SM.Yield x s' ->
|  return $ SM.Yield x (Right (SM.Stream istep s' Unknown,t))
|  {-# INLINE [0] step #-}
|  {-# INLINE [1] concatMapM #-}
|  
|  testConcatMapM :: Int -> Int
|  testConcatMapM k = seq k $ U.unId
|   . SM.foldl' (+) 0
|   . concatMap (\i -> SM.enumFromTo 5 k)
|   $ SM.enumFromTo 3 k
|  {-# NOINLINE testConcatMapM #-}
|  
|  CORE:
|  
|  testConcatMapM
|  testConcatMapM =
|\ k_aCA ->
|  let! { I# ipv_s1xv ~ _ <- k_aCA } in ### inner loop
|  letrec {
|$s$wfoldlM'_loop_s29q
|$s$wfoldlM'_loop_s29q =
|  \ sc_s29i sc1_s29j sc2_s29k ->
|  ### unboxing
|let! { I# x_a1LA ~ _ <- sc1_s29j } in
|case tagToEnum# (<=# x_a1LA ipv_s1xv) of _ {
|  False -> $s$wfoldlM'_loop1_s29c sc_s29i sc2_s29k;
|  True ->
|$s$wfoldlM'_loop_s29q
|  ### reboxing
|  (+# sc_s29i x_a1LA) (I# (+# x_a1LA 1)) sc2_s29k
|};
|  ### outer loop
|$s$wfoldlM'_loop1_s29c
|$s$wfoldlM'_loop1_s29c =
|  \ sc_s29a sc1_s29b ->
|case tagToEnum# (<=# sc1_s29b ipv_s1xv) of _ {
|  False -> sc_s29a;
|  True ->
|case tagToEnum# (<=# 5 ipv_s1xv) of _ {
|  False -> $s$wfoldlM'_loop1_s29c sc_s29a (+# sc1_s29b
|  1); ### boxed seed (I# 6)
|  True -> $s$wfoldlM'_loop_s29q (+# sc_s29a 5) (I# 6)
|  (+# sc1_s29b 1)
|}
|}; } in
|  let! { __DEFAULT ~ ww_s20G <- $s$wfoldlM'_loop1_s29c 0 3 } in
|  I# ww_s20G
|  
|  ___
|  Glasgow-haskell-users mailing list
|  Glasgow-haskell-users@haskell.org
|  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: UNPACK Existential datatype

[Simon Peyton Jones]

I think this is a very reasonable suggestion.  It would take some work to 
implement, but nothing fundamental.

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Nicholas Clarke
Sent: 20 January 2015 13:08
To: glasgow-haskell-users@haskell.org
Subject: Fwd: UNPACK Existential datatype

I'd like to be able to use the UNPACK pragma on an existentially quantified 
datatype. So as in the below example:

{-# LANGUAGE ExistentialQuantification #-}

data Foo = forall a. Show a => Foo !a
instance Show Foo where
  show (Foo a) = "Foo! " ++ show a

data Bar =
Bar {-# UNPACK #-} !Foo
  deriving (Show)

main :: IO ()
main = do
  let foo = Foo "Hello"
  bar = Bar foo
  print bar

I would expect the `Foo` constructor to be unpacked into Bar, as if I had 
written:

data Bar = forall a. Show a => Bar !a

However, instead I get the 'Ignoring unusable UNPACK pragma on the first 
argument of ‘Bar’' warning. Is there a reason this shouldn't work, or a 
workaround to get it to do so?

Cheers,

Nick


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

RE: ghc-7.10.0 type inference regression when faking injective type families

[Simon Peyton Jones]

Yes, I fixed it on the train. Most helpful.  Busy tomorrow but I should have a 
fix committed by the end of the week

Simon

| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Richard Eisenberg
| Sent: 20 January 2015 16:24
| To: adam vogt
| Cc: Glasgow-Haskell-Users
| Subject: Re: ghc-7.10.0 type inference regression when faking injective
| type families
| 
| After quite a bit of thought, I agree that this is a regression and that
| the original program should be accepted.
| 
| Make a bug report!
| 
| Thanks,
| Richard
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: conflicting multi-parameter family instance declarations

[Simon Peyton Jones]

Alas it's deliberate.  See Section 6 of "Closed type families" 
http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/, and the 
recent thread on https://ghc.haskell.org/trac/ghc/ticket/9918

Maybe you can add your example to that ticket, with some indication of why it's 
important to you.

The difficulty is that lifting this restriction actually makes the type system 
unsound.

Simon

|  -Original Message-
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  boun...@haskell.org] On Behalf Of Michal Konecný
|  Sent: 13 January 2015 12:08
|  To: glasgow-haskell-users@haskell.org
|  Subject: conflicting multi-parameter family instance declarations
|  
|  Dear all,
|  
|  The following compiles with ghc 7.6 but fails with ghc 7.8:
|  
|  -
|  {-# LANGUAGE TypeFamilies #-}
|  {-# LANGUAGE FlexibleInstances #-}
|  {-# LANGUAGE MultiParamTypeClasses #-}
|  module Test where
|  
|  class M t s where
|  type T t s
|  
|  data I t = I t
|  
|  instance M t t where
|  type (T t t) = ()
|  
|  instance M t (I t) where
|  type (T t (I t)) = ()
|  -
|  
|  The error I get with ghc 7.8.3 and 7.8.4 is:
|  
|  Test.hs:12:10:
|  Conflicting family instance declarations:
|T t t -- Defined at Test.hs:12:10
|T t (I t) -- Defined at Test.hs:15:10
|  
|  
|  I am curious if this change is an improvement or a bug.  I would be
|  grateful for help as this issue affects a fairly large library I
|  develop.
|  
|  Best regards,
|  Michal
|  --
|  |-| Dr. Michal Konecny, Computer Science, Aston University Room MB212D
|  |
|  |-| Tel +44 121 204 3462 | Fax +44 121 204 3681
|  |-| http://duck.aston.ac.uk/konecnym OpenPGP key
|  |-| http://duck.aston.ac.uk/konecnym/ki.aston
|  
|  ___
|  Glasgow-haskell-users mailing list
|  Glasgow-haskell-users@haskell.org
|  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Changes to the type checker with respect to UndecidableInstances

[Simon Peyton Jones]

UndecidableInstances is supposed to be needed if GHC can't prove that the 
instance declarations terminate.  But here it can be sure they terminate.  GHC 
7.6.3 didn't realise this.

I'll modify the user manual to be clearer on this point.

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Mitsutoshi Aoe
Sent: 28 December 2014 10:47
To: glasgow-haskell-users@haskell.org
Subject: Changes to the type checker with respect to UndecidableInstances

Hi,

I found a difference between GHC 7.6.3 and 7.8.3 with respect to 
UndecidableInstances.

https://gist.github.com/maoe/57a4346eb36aee159916

7.6.3 requires UndecidableInstances to compile this snippet whereas 7.8.3 
doesn't. What has changed in the type checker?

Mitsutoshi

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

RE: ANNOUNCE: GHC 7.10.1 Release Candidate 1

[Simon Peyton Jones]

| If I understand correctly, OverloadedRecordFields has not been merged
| yet. Are there any chances to merge it into GHC 7.10.1?

I'm afraid not.  The situation is that Adam has a fairly complete patch for 
overloaded record fields, but neither he nor I are happy with it. It makes some 
fairly complicated and pervasive changes, and feels like a sledgehammer to 
crack a nut. We'd scheduled for Adam to spend a day at MSR for us to work on it 
together, but Adam had to cancel.  We'll hopefully re-arrange.

Meanwhile it'd be motivating to know who, if anyone, is actively keen on it.  
Kazu is presumably one.  I expect there are others, but I couldn't list them.

Simon

| 
| --Kazu
| 
| > We are pleased to announce the first release candidate for GHC 7.10.1:
| >
| > https://downloads.haskell.org/~ghc/7.10.1-rc1/
| >
| > This includes the source tarball and bindists for 64bit/32bit Linux
| > and Windows. Binary builds for other platforms will be available
| > shortly. (CentOS 6.5 binaries are not available at this time like they
| > were for 7.8.x). These binaries and tarballs have an accompanying
| > SHA256SUMS file signed by my GPG key id (0x3B58D86F).
| >
| > We plan to make the 7.10.1 release sometime in February of 2015. We
| > expect another RC to occur during January of 2015.
| >
| > Please test as much as possible; bugs are much cheaper if we find them
| > before the release!
| >
| > --
| > Regards,
| >
| > Austin Seipp, Haskell Consultant
| > Well-Typed LLP, http://www.well-typed.com/
| > ___
| > ghc-devs mailing list
| > ghc-d...@haskell.org
| > http://www.haskell.org/mailman/listinfo/ghc-devs
| ___
| ghc-devs mailing list
| ghc-d...@haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Behavior of touch#

[Simon Peyton Jones]

Would it make sense to elaborate the Haddock docs to explain stuff here?

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Carter Schonwald
Sent: 16 December 2014 06:45
To: Brandon Simmons
Cc: glasgow-haskell-users
Subject: Re: Behavior of touch#

https://github.com/ghc/ghc/blob/8c10b67ba049477cc9ed23e61f5bd119e1cefc29/compiler/cmm/CmmMachOp.hs#L556

and 
https://github.com/ghc/ghc/blob/8c10b67ba049477cc9ed23e61f5bd119e1cefc29/compiler/nativeGen/X86/CodeGen.hs#L1731

spell it out a bit more

so touch is preserved through the CMM level, and then gets erased when doing 
final code gen.
Its meant to ensure on heap pointers remain reachable

On Tue, Dec 16, 2014 at 1:43 AM, Carter Schonwald 
mailto:carter.schonw...@gmail.com>> wrote:
the point of touch is to prevent premature GC, it actually gets erased at the 
CMM level i believe.
That is, it only makes sense to apply touch to lifted types on the heap!

On Mon, Dec 15, 2014 at 4:21 PM, Brandon Simmons 
mailto:brandon.m.simm...@gmail.com>> wrote:
The `primitive` package exports a lifted version of the undocumented `touch#`

http://hackage.haskell.org/package/ghc-prim-0.3.1.0/docs/GHC-Prim.html

which has type:

touch :: PrimMonad m => a -> m ()

I'd like to know if this works correctly in general, or will it suffer
from the same gotches w/r/t unboxing as with addFinalizer and Weak
references? i.e. must it only be passed an unboxed type?

Brandon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Discovery of source dependencies without --make

[Simon Peyton Jones]

I suppose that if --make found Foo.hi, but no Foo.hs, it could simply use the 
Foo.hi.  That would do strictly more than now. I don't know if there would be 
any disadvantages.

Augmenting --make's semantics sounds better to me than inventing a new 
compilation mode.

Maybe a feature request ticket.  Then if people like it maybe someone can 
implement it.

Simon

|  -Original Message-
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  boun...@haskell.org] On Behalf Of Lars Hupel
|  Sent: 28 November 2014 16:26
|  To: Simon Peyton Jones
|  Cc: glasgow-haskell-users@haskell.org
|  Subject: Re: Discovery of source dependencies without --make
|  
|  > How does that differ from ghc --make?  The only difference I can see
|  is that
|  >   - Modules that --make might find, but not listed on
|  > the command line, would not be compiled by --topo-sort
|  
|  "--make" always requires a full view on all sources. That is, any
|  imports which cannot be resolved from the package database are assumed
|  to exist as source files. Imagine the following situation:
|  
|  A.hs
|  > module A where
|  >
|  > import B
|  > import Library
|  
|  B.hs
|  > module B where
|  
|  If I compile these two with "--make", it also needs "Library.hs" as
|  input. If I compile them without "--make", it just needs the interface
|  ("Library.hi") as additional input.
|  
|  Concretely, assuming that only "path/Library.hi" exists, this fails:
|  
|ghc -c -ipath --make A.hs B.hs
|  
|  In contrast to that, I propose that this should work:
|  
|ghc -c -ipath --topo-sort A.hs B.hs
|  ___
|  Glasgow-haskell-users mailing list
|  Glasgow-haskell-users@haskell.org
|  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Discovery of source dependencies without --make

[Simon Peyton Jones]

|  Let's say the hypothetical feature is selected via the GHC flag "--
|  topo-sort". It would add a step before regular compilation and
|  wouldn't affect any other flag:
|  
|ghc -c --topo-sort fileA.hs fileB.hs ...
|  
|  This would first read in the specified source files and look at their
|  module headers and import statements. It would build a graph of module
|  dependencies _between_ the specified source files (ignoring circular
|  dependencies), perform a topological sort on that graph, and proceed
|  with compiling the source files in that order.

Interesting (and quite different from what I anticipated, so it's a good thing 
you wrote it down!).

How does that differ from ghc --make?  The only difference I can see is that
  - Modules that --make might find, but not listed on
the command line, would not be compiled by --topo-sort
 
Simon

|  -Original Message-
|  From: Lars Hupel [mailto:l...@hupel.info]
|  Sent: 28 November 2014 14:42
|  To: Simon Peyton Jones
|  Cc: glasgow-haskell-users@haskell.org; Andrey Mokhov
|  Subject: Re: Discovery of source dependencies without --make
|  
|  > Rather than explain by deltas from something else, it might be
|  easier
|  > just to write down precisely what you seek.
|  
|  Let's say the hypothetical feature is selected via the GHC flag "--
|  topo-sort". It would add a step before regular compilation and
|  wouldn't affect any other flag:
|  
|ghc -c --topo-sort fileA.hs fileB.hs ...
|  
|  This would first read in the specified source files and look at their
|  module headers and import statements. It would build a graph of module
|  dependencies _between_ the specified source files (ignoring circular
|  dependencies), perform a topological sort on that graph, and proceed
|  with compiling the source files in that order.
|  
|  As a consequence, if there is an order in which these modules can be
|  successfully compiled, "--topo-sort" would choose such an order. In
|  that sense, the above invocation would be equivalent to
|  
|ghc -c fileB.hs fileA.hs ...
|  
|  (using some permutation of the original order specified)
|  
|  Another consequence is that any invocation of GHC in the form of
|  
|ghc -c flags... sources.hs...
|  
|  with arbitrary flags would still work as usual when adding "--topo-
|  sort".
|  
|  Quoting from the user manual:
|  
|  > In your program, you import a module Foo by saying import Foo. In
|  > --make mode or GHCi, GHC will look for a source file for Foo and
|  > arrange to compile it first. Without --make, GHC will look for the
|  > interface file for Foo, which should have been created by an earlier
|  > compilation of Foo.
|  
|  The hypothetical "--topo-sort" flag would behave in the latter way,
|  i.e.
|  it would not require a source file for an unknown dependency. Hence,
|  "--topo-sort" and "--make" would be conflicting options.
|  
|  I hope that clears up things a bit.
|  
|  Cheers
|  Lars
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Discovery of source dependencies without --make

[Simon Peyton Jones]

I have only been skimming this thread, but would it be worth writing a tight 
specification of what exactly you want?  Your original message said only "Is 
there any way to get the dependency discovery of '--make' without the rest", 
but I really don't know what that means.  Nor do I know what you mean by "it 
only looks at source files".  

Rather than explain by deltas from something else, it might be easier just to 
write down precisely what you seek.

Andrey Mokhov also wants a way to take a single Haskell module, and discover 
its immediate imports, a kind of non-recursive version of -M.  So 
ghc -M-one-shot Foo.hs
would print out the list of Haskell modules that Foo imports.  (There are 
doubtless complications to do with CPP too, but that's the general idea.)

I don't know if that is what you want too.

Simon

|  -Original Message-
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  boun...@haskell.org] On Behalf Of Lars Hupel
|  Sent: 28 November 2014 08:53
|  To: Gershom B
|  Cc: glasgow-haskell-users@haskell.org
|  Subject: Re: Discovery of source dependencies without --make
|  
|  Hi Gershom,
|  
|  > Is -M perhaps what you’ve been looking for?
|  
|  sadly, no. Firstly, it behaves in the same way as "--make" (i.e. only
|  looks at source files) and secondly, it produces a Makefile as output.
|  
|  (I'd be happy though to use the GHC API if somebody could tell me
|  whether/where this functionality is exposed.)
|  
|  Cheers
|  Lars
|  
|  ___
|  Glasgow-haskell-users mailing list
|  Glasgow-haskell-users@haskell.org
|  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: More flexible literate Haskell extensions (Trac #9789), summary on wiki

[Simon Peyton Jones]

Marijn,

Thanks.  Can you make sure that you update the wiki page to reflect what you 
say here?  Email is transitory; the wiki page gives the *specification* of the 
feature, and says unambiguously what you intend.  Misunderstandings expressed 
in email are simply tell you how to improve the wiki page!

thanks

Simon

| -Original Message-
| From: Merijn Verstraaten [mailto:mer...@inconsistent.nl]
| Sent: 16 November 2014 21:42
| To: Simon Peyton Jones
| Cc: ghc-d...@haskell.org; GHC Users Mailing List
| Subject: Re: More flexible literate Haskell extensions (Trac #9789),
| summary on wiki
| 
| Hi Simon,
| 
| Thanks for the comments. I think most of the confusion stems from people
| overthinking the scope of what I was proposing. I'll clear up the page a
| bit as it's currently conflating implementation details with semantics.
| 
| > On 14 Nov 2014, at 2:29, Simon Peyton Jones 
| wrote:
| > Would it be possible to have a section
| >   a) describing a single alternative, as precisely as possible.
| 
| The single alternative would simply be:
| If GHC tries to find the source for a module Foo and none of "Foo.hs",
| "Foo.lhs", "Foo.hsig" or "Foo.lhsig" are found, it will accept any file
| with a "Foo.lhs.*" extension, i.e., "Foo.lhs.md", "Foo.lhs.tex", etc.
| 
| >   b) saying what the effect or meaning of proposal is
| 
| The proposal does NOT modify the way GHC treats the contents of files or
| unlits literate haskell in anyway. While I'm in favour of supporting more
| literate formats, that's orthogonal to this proposal.
| 
| > For (a), is Foo.hs still ok?  Foo.lhs?  What if both exist and/or
| Foo.md.hs or whatever?
| 
| Yes, both "Foo.hs" and "Foo.lhs" are still ok. I don't think the manual
| specifies what GHC does in the case "Foo.hs" AND "Foo.lhs" both exist.
| But the implementation prefers extensions in the following order: "hs",
| "lhs", "hsig" and "lhsig". I would just add the new allowed extension
| behind that as lower priority than the current ones.
| 
| > For (b) what does a suffix of Foo.hs.md mean?  Presumably there is some
| markdown in there.  But how is it delimited?  Is md the only one proposed
| or are there others? Is it meant to be extensible or is there a fixed
| set?
| 
| See my earlier point, I do *not* intend to affect the way GHC
| interprets/unlits the contents of files. Pandoc is already perfectly
| happy to work with literate files, it just currently lacks a way to
| determine what the content type of the non-literate bits is. Which is
| what I hope to deal with here.
| 
| Cheers,
| Merijn
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: More flexible literate Haskell extensions (Trac #9789), summary on wiki

[Simon Peyton Jones]

Thanks.  I don't have strong opinions about any of this.  But I would love to 
have an actual specification of what is proposed.  The wiki page starts with 
"Proposal" but lists a set of alternatives.  Later "Concrete proposal" 
discusses only file suffixes, and has lots of discussion of alternatives.

Would it be possible to have a section
   a) describing a single alternative, as precisely as possible.
   b) saying what the effect or meaning of proposal is

For (a), is Foo.hs still ok?  Foo.lhs?  What if both exist and/or Foo.md.hs or 
whatever?

For (b) what does a suffix of Foo.hs.md mean?  Presumably there is some 
markdown in there.  But how is it delimited?  Is md the only one proposed or 
are there others? Is it meant to be extensible or is there a fixed set?

In short, a *specification* of what is proposed.  I think that would be helpful 
for people who come to this without having participated in the discussion that 
led up to it.

Simon

|  -Original Message-
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  boun...@haskell.org] On Behalf Of Merijn Verstraaten
|  Sent: 14 November 2014 04:22
|  To: ghc-d...@haskell.org; GHC Users Mailing List
|  Subject: More flexible literate Haskell extensions (Trac #9789),
|  summary on wiki
|  
|  As requested on my ticket I summarised the entire proposal on the wiki
|  here: https://ghc.haskell.org/trac/ghc/wiki/FlexibleLiterateExtension
|  
|  I don't expect a lot of disagreement on discussion, aside from minor
|  bike shedding on the flavour of the extension. I've started
|  implementing this already. I'm open to bikesheds on exact extension,
|  as it shouldn't affect the implementation.
|  
|  Unless there's any vehement objections, I'll produce a diff on
|  fabricator asap.
|  
|  Cheers,
|  Merijn
|  ___
|  Glasgow-haskell-users mailing list
|  Glasgow-haskell-users@haskell.org
|  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Thread behavior in 7.8.3

[Simon Peyton Jones]

I wonder if the knowledge embodied in this thread might usefully be summarised 
in the user manual?  Or on the GHC section of the Haskell wiki 
https://www.haskell.org/haskellwiki/GHC?

Simon

|  -Original Message-
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  boun...@haskell.org] On Behalf Of Edward Z. Yang
|  Sent: 30 October 2014 00:41
|  To: John Lato
|  Cc: GHC Users List
|  Subject: Re: Thread behavior in 7.8.3
|  
|  Yes, that's right.
|  
|  I brought it up because you mentioned that there might still be
|  occasional delays, and those might be caused by a thread not being
|  preemptible for a while.
|  
|  Edward
|  
|  Excerpts from John Lato's message of 2014-10-29 17:31:45 -0700:
|  > My understanding is that -fno-omit-yields is subtly different.  I
|  > think that's for the case when a function loops without performing
|  any
|  > heap allocations, and thus would never yield even after the context
|  > switch timeout.  In my case the looping function does perform heap
|  > allocations and does eventually yield, just not until after the
|  timeout.
|  >
|  > Is that understanding correct?
|  >
|  > (technically, doesn't it change to yielding after stack checks or
|  > something like that?)
|  >
|  > On Thu, Oct 30, 2014 at 8:24 AM, Edward Z. Yang 
|  wrote:
|  >
|  > > I don't think this is directly related to the problem, but if you
|  > > have a thread that isn't yielding, you can force it to yield by
|  > > using -fno-omit-yields on your code.  It won't help if the
|  > > non-yielding code is in a library, and it won't help if the
|  problem
|  > > was that you just weren't setting timeouts finely enough (which
|  > > sounds like what was happening). FYI.
|  > >
|  > > Edward
|  > >
|  > > Excerpts from John Lato's message of 2014-10-29 17:19:46 -0700:
|  > > > I guess I should explain what that flag does...
|  > > >
|  > > > The GHC RTS maintains capabilities, the number of capabilities
|  is
|  > > specified
|  > > > by the `+RTS -N` option.  Each capability is a virtual machine
|  > > > that executes Haskell code, and maintains its own runqueue of
|  > > > threads to
|  > > process.
|  > > >
|  > > > A capability will perform a context switch at the next heap
|  block
|  > > > allocation (every 4k of allocation) after the timer expires.
|  The
|  > > > timer defaults to 20ms, and can be set by the -C flag.
|  > > > Capabilities perform context switches in other circumstances as
|  > > > well, such as when a thread yields or blocks.
|  > > >
|  > > > My guess is that either the context switching logic changed in
|  > > > ghc-7.8,
|  > > or
|  > > > possibly your code used to trigger a switch via some other
|  > > > mechanism
|  > > (stack
|  > > > overflow or something maybe?), but is optimized differently now
|  so
|  > > instead
|  > > > it needs to wait for the timer to expire.
|  > > >
|  > > > The problem we had was that a time-sensitive thread was getting
|  > > > scheduled on the same capability as a long-running non-yielding
|  > > > thread, so the time-sensitive thread had to wait for a context
|  > > > switch timeout (even
|  > > though
|  > > > there were free cores available!).  I expect even with -N4
|  you'll
|  > > > still
|  > > see
|  > > > occasional delays (perhaps <5% of calls).
|  > > >
|  > > > We've solved our problem with judicious use of `forkOn`, but
|  that
|  > > > won't help at N1.
|  > > >
|  > > > We did see this behavior in 7.6, but it's definitely worse in
|  7.8.
|  > > >
|  > > > Incidentally, has there been any interest in a work-stealing
|  scheduler?
|  > > > There was a discussion from about 2 years ago, in which Simon
|  > > > Marlow
|  > > noted
|  > > > it might be tricky, but it would definitely help in situations
|  like this.
|  > > >
|  > > > John L.
|  > > >
|  > > > On Thu, Oct 30, 2014 at 8:02 AM, Michael Jones
|  > > > 
|  > > wrote:
|  > > >
|  > > > > John,
|  > > > >
|  > > > > Adding -C0.005 makes it much better. Using -C0.001 makes it
|  > > > > behave more like -N4.
|  > > > >
|  > > > > Thanks. This saves my project, as I need to deploy on a single
|  > > > > core
|  > > Atom
|  > > > > and was stuck.
|  > > > >
|  > > > > Mike
|  > > > >
|  > > > > On Oct 29, 2014, at 5:12 PM, John Lato 
|  wrote:
|  > > > >
|  > > > > By any chance do the delays get shorter if you run your
|  program
|  > > > > with
|  > > `+RTS
|  > > > > -C0.005` ?  If so, I suspect you're having a problem very
|  > > > > similar to
|  > > one
|  > > > > that we had with ghc-7.8 (7.6 too, but it's worse on ghc-7.8
|  for
|  > > > > some reason), involving possible misbehavior of the thread
|  scheduler.
|  > > > >
|  > > > > On Wed, Oct 29, 2014 at 2:18 PM, Michael Jones
|  > > > > 
|  > > wrote:
|  > > > >
|  > > > >> I have a general question about thread behavior in 7.8.3 vs
|  > > > >> 7.6.X
|  > > > >>
|  > > > >> I moved from 7.6 to 7.8 and my application behaves very
|  > > > >> differently. I have three threads, an application t

RE: Type checker plugins

[Simon Peyton Jones]

And can someone update the user manual please?

|  -Original Message-
|  From: Barney Hilken [mailto:b.hil...@ntlworld.com]
|  Sent: 17 October 2014 00:14
|  To: Carter Schonwald
|  Cc: Adam Gundry; Eric Seidel; glasgow-haskell-users@haskell.org; Simon
|  Peyton Jones
|  Subject: Re: Type checker plugins
|  
|  Ok, I hadn't realised that. Looking in the user's guide, I see <= and
|  <=? for Nat, but I couldn't find anything about Symbol. I must try
|  them out!
|  
|  
|  > From: Carter Schonwald 
|  >
|  > the alphabetical ordering on Symbol is already exposed via
|  TypeLits... this would be some machinery to help maintain that
|  ordering with less user intervention?
|  >
|  > On Thu, Oct 16, 2014 at 6:59 PM, Barney Hilken
|   wrote:
|  > I can think of a use for a non-equality constraint: an alphabetical
|  ordering on Symbol. This would allow experimental implementations of
|  extensible records (without shadowing) which keep the labels sorted.
|  >
|  > An order constraint on Nat might be useful, too.
|  >
|  > Barney.
|  >
|  > ___
|  > Glasgow-haskell-users mailing list
|  > Glasgow-haskell-users@haskell.org
|  > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|  >
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Type checker plugins

[Simon Peyton Jones]

| Thanks Simon, your branch does make it a lot more feasible to unflatten,
| so I'll just go ahead and implement that in my plugin for now.

Actually it would be worth pausing.  If you get the latest Unflattening is now 
done by getInertUnsolved, which itself is called by solveFlatWanteds, 
immediately after calling solveFlats.  And solveFlats (which used to be called 
solveInteract) is where Iavor has the plugin interface.

In short, if you'd like to see unflattened constraints, rather than flattened 
ones, that would be easy.

Unflattening yourself is inadvisable.  The unflattening code in 
getInertUnsolved is quite remarkably tricky and it took me some time get it 
right.  (I have to write a long Note before committing it to head.)

All this is in the just-committed wip/new-flatten-skolems-Aug14 branch

Simon

| -Original Message-
| From: Adam Gundry [mailto:a...@well-typed.com]
| Sent: 16 October 2014 21:50
| To: Eric Seidel; Simon Peyton Jones
| Cc: Iavor Diatchki; glasgow-haskell-users@haskell.org
| Subject: Re: Type checker plugins
| 
| Thanks Simon, your branch does make it a lot more feasible to unflatten,
| so I'll just go ahead and implement that in my plugin for now.
| 
| Eric, that's fair enough, and I don't have any concrete use cases for
| non-equality constraints at the moment. I'm just keen to minimize the
| restrictions placed on plugins, because it is much easier to recompile a
| plugin than make changes in GHC itself!
| 
| On that note, I still wonder if it would be better to define TcPluginM
| as a wrapper around TcS rather than TcM. While in principle TcM should
| suffice, in practice GHC sometimes uses TcS for things that a plugin
| might want (I've run into TcSMonad.matchFam, which could easily be
| implemented in TcM instead). Is there any downside to defining a nice
| API in TcPluginM but providing an escape hatch to TcS, not just TcM?
| 
| Thanks,
| 
| Adam
| 
| 
| On 16/10/14 16:21, Eric Seidel wrote:
| > Our branch is actually based on yours Simon, are there any changes in
| the past week that we should pull in for people who want to experiment?
| >
| > Adam, we talked about passing other constraints to the plugins, but
| didn't have a concrete use-case at the time, so we just kept it as simple
| as possible. I don't see a reason to hide constraints if, as you say,
| there are plugins that may want to solve them.
| >
| > Eric
| >
| > Sent from my iPhone
| >
| >> On Oct 16, 2014, at 07:08, Simon Peyton Jones 
| wrote:
| >>
| >> This will become easier, I think. look on wip/new-flatten-skoelms-
| Aug14.  I'm now unflattening after solving the flat constraints.
| >>
| >> Simon
| >>
| >> |  -Original Message-
| >> |  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| >> |  boun...@haskell.org] On Behalf Of Adam Gundry
| >> |  Sent: 16 October 2014 11:59
| >> |  To: Iavor Diatchki
| >> |  Cc: glasgow-haskell-users@haskell.org
| >> |  Subject: Re: Type checker plugins
| >> |
| >> |  Hi Iavor,
| >> |
| >> |
| >> |  On 13/10/14 21:34, Iavor Diatchki wrote:
| >> |  > Hello,
| >> |  >
| >> |  > We now have an implementation of type-checker with plugin
| support.
| >> |  If
| >> |  > you are interested in trying it out:
| >> |  >
| >> |  >   - Checkout and build the `wip/tc-plugins` branch of GHC
| >> |
| >> |
| >> |  Thanks, this is great! I'd been working on a similar
| implementation,
| >> |  but yours is much better integrated. I am trying to adapt my units
| of
| >> |  measure plugin to work with this interface, and work out what else
| I
| >> |  need in TcPluginM.
| >> |
| >> |  One problem I've run into is transforming the flattened CFunEqCans
| >> |  into unflattened form (so the flatten-skolems don't get in the way
| of
| >> |  AG-unification). Do you know if there is an easy way to do this, or
| do
| >> |  I need to rebuild the tree manually in the plugin?
| >> |
| >> |  Also, I notice that you are providing only equality constraints to
| the
| >> |  plugin. Is there any reason we can't make other types of constraint
| >> |  available as well? For example, one might want to introduce a
| >> |  typeclass with a special solution strategy (cf. Coercible, or the
| Has
| >> |  class in OverloadedRecordFields).
| >> |
| >> |
| >> |  Cheers,
| >> |
| >> |  Adam
| >> |
| >> |
| >> |  >   - As an example, I've extracted my work on using an SMT solver
| at
| >> |  > the type level as a separate plugin:
| >> |  >
| >> |  >   https://github.com/yav/type-nat-solver
| >> |  >
| >> |  >- To see how to 

RE: Type checker plugins

[Simon Peyton Jones]

This will become easier, I think. look on wip/new-flatten-skoelms-Aug14.  I'm 
now unflattening after solving the flat constraints. 

Simon

|  -Original Message-
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  boun...@haskell.org] On Behalf Of Adam Gundry
|  Sent: 16 October 2014 11:59
|  To: Iavor Diatchki
|  Cc: glasgow-haskell-users@haskell.org
|  Subject: Re: Type checker plugins
|  
|  Hi Iavor,
|  
|  
|  On 13/10/14 21:34, Iavor Diatchki wrote:
|  > Hello,
|  >
|  > We now have an implementation of type-checker with plugin support.
|  If
|  > you are interested in trying it out:
|  >
|  >   - Checkout and build the `wip/tc-plugins` branch of GHC
|  
|  
|  Thanks, this is great! I'd been working on a similar implementation,
|  but yours is much better integrated. I am trying to adapt my units of
|  measure plugin to work with this interface, and work out what else I
|  need in TcPluginM.
|  
|  One problem I've run into is transforming the flattened CFunEqCans
|  into unflattened form (so the flatten-skolems don't get in the way of
|  AG-unification). Do you know if there is an easy way to do this, or do
|  I need to rebuild the tree manually in the plugin?
|  
|  Also, I notice that you are providing only equality constraints to the
|  plugin. Is there any reason we can't make other types of constraint
|  available as well? For example, one might want to introduce a
|  typeclass with a special solution strategy (cf. Coercible, or the Has
|  class in OverloadedRecordFields).
|  
|  
|  Cheers,
|  
|  Adam
|  
|  
|  >   - As an example, I've extracted my work on using an SMT solver at
|  > the type level as a separate plugin:
|  >
|  >   https://github.com/yav/type-nat-solver
|  >
|  >- To see how to invoke a module that uses a plugin, have a look
|  in
|  > `examples/A.hs`.
|  >  (Currently, the plugin assumes that you have `cvc4` installed
|  and
|  > available in the path).
|  >
|  > - Besides this, we don't have much documentation yet.  For
|  hackers:
|  > we tried to use `tcPlugin` on
|  > `TcPlugin` in the names of all things plugin related, so you
|  could
|  > grep for this.  The basic API
|  >  types and functions are defined in `TcRnTypes` and `TcRnMonad`.
|  >
|  > Happy hacking,
|  > -Iavor
|  
|  
|  --
|  Adam Gundry, Haskell Consultant
|  Well-Typed LLP, http://www.well-typed.com/
|  ___
|  Glasgow-haskell-users mailing list
|  Glasgow-haskell-users@haskell.org
|  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: status of rebindable syntax for arrows

[Simon Peyton Jones]

|  It already has a bug entry: #7828.  What would help is to know the
|  kind of use you have in mind, to see whether it fits with the proposed
|  solution.

Indeed.  Moreover #7828 is stalled; it needs some arrow-savvy person to focus 
cycles on it.  If rebindable syntax for arrows is considered important.

Meanwhile I think you should not rely on rebindable syntax for arrows. The user 
manual is misleading on this point.

Simon

|  -Original Message-
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  boun...@haskell.org] On Behalf Of Ross Paterson
|  Sent: 15 October 2014 06:56
|  To: glasgow-haskell-users
|  Subject: Re: status of rebindable syntax for arrows
|  
|  On Tue, Oct 14, 2014 at 10:26:46PM +0200, S. Doaitse Swierstra wrote:
|  > The GHC manual already for quite a number of version states:
|  >
|  >• Arrow notation (see Section 7.17, “Arrow notation ”) uses
|  whatever arr, (>>>), first, app, (|||) and loop functions are in
|  scope.
|  >  But unlike the other constructs, the types of these
|  functions must match the Prelude types very closely. Details are in
|  flux; if you want to use this, ask!
|  >
|  > When using this feature we get the error:
|  >
|  > "Var/Type length mismatch:
|  >[s{tv aVL} [tv]]
|  >[]
|  > ghc: panic! (the 'impossible' happened)  (GHC version 7.8.3 for
|  > x86_64-apple-darwin):
|  >tcTyVarDetails s{tv aVL} [tv]
|  >
|  > Please report this as a GHC bug:
|  http://www.haskell.org/ghc/reportabug";
|  >
|  > So our question is whether we should really report this as a bug,
|  and/or what we can do about this.
|  
|  It already has a bug entry: #7828.  What would help is to know the
|  kind of use you have in mind, to see whether it fits with the proposed
|  solution.
|  ___
|  Glasgow-haskell-users mailing list
|  Glasgow-haskell-users@haskell.org
|  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: The future of the haskell2010/haskell98 packages - AKA Trac #9590

[Simon Peyton Jones]

I hate #1.  Let's avoid if unless it's really crucial to some of our users.

Simon

| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Austin
| Seipp
| Sent: 30 September 2014 21:21
| To: ghc-d...@haskell.org; glasgow-haskell-users@haskell.org
| Subject: The future of the haskell2010/haskell98 packages - AKA Trac
| #9590
| 
| Hello developers, users, friends,
| 
| I'd like you all to weigh in on something - a GHC bug report, that has
| happened as a result of making Applicative a superclass of Monad:
| 
| https://ghc.haskell.org/trac/ghc/ticket/9590
| 
| The very condensed version is this: because haskell2010/haskell98
| packages try to be fairly strictly conforming, they do not have
| modules like Control.Applicative.
| 
| Unfortunately, due to the way these packages are structured, many
| things are simply re-exported from base, like `Monad`. But
| `Applicative` is not, and cannot be imported if you use -XHaskell2010
| and the haskell2010 package.
| 
| The net result here is that haskell98/haskell2010 are hopelessly
| broken in the current state: it's impossible to define an instance of
| `Monad`, because you cannot define an instance of `Applicative`,
| because you can't import it in the first place!
| 
| This leaves us in quite a pickle.
| 
| So I ask: Friends, what do you think we should do? I am particularly
| interested in users/developers of current Haskell2010 packages - not
| just code that may *be* standard Haskell - code that implies a
| dependency on it.
| 
| There was a short discussion between me and Simon Marlow about this in
| the morning, and again on IRC this morning between me, Duncan, Edward
| K, and Herbert.
| 
| Basically, I only see one of two options:
| 
|  - We could make GHC support both: a version of `Monad` without
| `Applicative`, and one with it. This creates some complication in the
| desugarer, where GHC takes care of `do` syntax (and thus needs to be
| aware of `Monad`'s definition and location). But it is, perhaps, quite
| doable.
| 
|  - We change both packages to export `Applicative` and follow the API
| changes in `base` accordingly.
| 
| Note that #1 above is contingent on three things:
| 
|  1) There is interest in this actually happening, and these separate
| APIs being supported. If there is not significant interest in
| maintaining this, it's unclear if we should go for it.
| 
|  2) It's not overly monstrously complex (I don't think it necessarily
| will be, but it might be.)
| 
|  3) You can't like `haskell2010` packages and `base` packages together
| in the general case, but, AFAIK, this wasn't the case before either.
| 
| I'd really appreciate your thoughts. This must be sorted out for 7.10
| somehow; the current situation is hopelessly busted.
| 
| --
| Regards,
| 
| Austin Seipp, Haskell Consultant
| Well-Typed LLP, http://www.well-typed.com/
| ___
| ghc-devs mailing list
| ghc-d...@haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Aliasing current module qualifier

[Simon Peyton Jones]

If there is to be such a language feature, I strongly feel it should be via 
something like
   module Long.Name.M( f, g, h ) as K where ...

I do not want to try to piggy-back on the possible meaning of a self-import; 
it’s just asking for trouble, as Iavor points out.

Using “as M” in the module header would be simple.  It is easy to explain and 
fairly easy to implement.   I don’t think there are any knock-on complications. 
 So if enough people want it, and someone is prepared to implement it (with a 
language extension flag of course), then I’d be OK with that.   I’m unsure that 
it’s worth the effort, but I’m happy to let users decide.

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Iavor Diatchki
Sent: 30 September 2014 13:18
To: j...@repetae.net
Cc: GHC Users Mailing List; ghc-devs; Herbert Valerio Riedel
Subject: Re: Aliasing current module qualifier


Hello,

What semantics are you using for recursive modules?  As far as I see, if you 
take a least fixed point semantics (e.g. as described in "A Formal 
Specification for the Haskell 98 Module System", 
http://yav.github.io/publications/modules98.pdf ) this program is incorrect as 
the module does not export anything.

While this may seem a bit counter intuitive at first, this semantics has the 
benefit of being precise, easily specified, and uniform (e.g it does not 
require any special treatment of the " current " module).  As an example, 
consider the following variation of your program, where I just moved the 
definition in a sperate (still recursive) module:

module A (M.x) where
  import B as M

module B (M.x) where
  import A as M
  x = True

I think that it'd be quite confusing if a single recursive module worked 
differently then a larger recursive group, but it is not at all obvious why B 
should export 'x'.  And for those who like this kind of puzzle: what should 
happen if 'A' also had a definition for 'x'?

Iavor
On Sep 29, 2014 11:02 PM, "John Meacham" 
mailto:j...@repetae.net>> wrote:
You don't need a new language construct, what i do is:

 module AnnoyinglyLongModuleName (M.length, M.null) where

import AnnoyinglongLongModuleName as M

I think ghc would need to be extended a little to make this convienient as it 
doesn't handle recursive module imports as transparently.

John

On Mon, Sep 29, 2014 at 8:47 AM, Brandon Allbery 
mailto:allber...@gmail.com>> wrote:
On Mon, Sep 29, 2014 at 4:19 AM, Herbert Valerio Riedel 
mailto:h...@gnu.org>> wrote:
Now it'd be great if I could do the following instead:

module AnnoyinglyLongModuleName (M.length, M.null) where

import AnnoyinglyLongModuleName as M -- <- does not work

I think if I wanted this syntax, I'd go for:

module AnnoyinglyLongModuleName as M where ...

--
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com 
 ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

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



--
John Meacham - http://notanumber.net/

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

RE: GHC not able to detect impossible GADT pattern

[Simon Peyton Jones]

This is a bug in 7.8.3: https://ghc.haskell.org/trac/ghc/ticket/9433

You should get this error (and do in HEAD):
  Sock.hs:28:5:
Type family 'Readable' should have 1 argument, but has been given none
In the equations for closed type family 'Foo'

So your program is indeed wrong, but the error message you are getting is 
entirely bogus. If you fix the above error you should be good to go.  Indeed, 
if you change the defn of Foo thus, it compiles just fine

type family Foo (op :: SocketOperation) (s :: SocketType) 
  :: Constraint where
Foo 'Read s = Readable s
Foo Write s = Writable s

Sorry about the egregious bug.

Simon

| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Merijn Verstraaten
| Sent: 03 September 2014 09:22
| To: Simon Peyton Jones
| Cc: Tom Schrijvers; GHC Users List
| Subject: Re: GHC not able to detect impossible GADT pattern
| 
| Hi Simon,
| 
| Thanks for the clarification, I attached the code to that ticket. Does
| this mean improvements in this area are supposed to land in 7.10?
| 
| Semi-relatedly, before attempting the current code (which at least
| compiles), I had a few other attempts and I was hoping you (or other
| readers) might be able to shed some light on this baffling error (full
| code at the end):
| 
| Could not deduce (Readable sock) arising from a use of 'f'
| from the context (Readable sock)
|   bound by the type signature for
|  readSocket :: (Readable sock) => Socket sock -> IO Message
|   at test-old.hs:52:15-70
| Relevant bindings include
|   f :: forall (op :: SocketOperation).
|(Foo op sock) =>
|SockOp sock op -> Operation op
| (bound at test-old.hs:53:22)
|   readSocket :: Socket sock -> IO Message (bound at test-old.hs:53:1)
| In the expression: f (SRead :: SockOp sock Read)
| In an equation for 'readSocket':
| readSocket (Socket _ f) = f (SRead :: SockOp sock Read)
| 
| It seems to me that "Readable sock" should be trivially deducible from
| itself?
| 
| Cheers,
| Merijn
| 
| {-# LANGUAGE ConstraintKinds #-}
| {-# LANGUAGE DataKinds #-}
| {-# LANGUAGE GADTs #-}
| {-# LANGUAGE RankNTypes #-}
| {-# LANGUAGE ScopedTypeVariables #-}
| {-# LANGUAGE TypeFamilies #-}
| module Test where
| 
| import Data.Proxy
| import GHC.Exts
| 
| data Message
| 
| data SocketType = Dealer | Push | Pull
| 
| data SocketOperation = Read | Write
| 
| data SockOp :: SocketType -> SocketOperation -> * where
| SRead :: Foo 'Read sock => SockOp sock 'Read
| SWrite :: Foo Write sock => SockOp sock Write
| 
| data Socket :: SocketType -> * where
| Socket :: proxy sock
|-> (forall op . Foo op sock => SockOp sock op -> Operation op)
|-> Socket sock
| 
| type family Foo (op :: SocketOperation) :: SocketType -> Constraint where
| Foo 'Read = Readable
| Foo Write = Writable
| 
| type family Operation (op :: SocketOperation) :: * where
| Operation 'Read = IO Message
| Operation Write = Message -> IO ()
| 
| type family Readable (t :: SocketType) :: Constraint where
| Readable Dealer = ()
| Readable Pull = ()
| 
| type family Writable (t :: SocketType) :: Constraint where
| Writable Dealer = ()
| Writable Push = ()
| 
| dealer :: Socket Dealer
| dealer = undefined
| 
| push :: Socket Push
| push = undefined
| 
| pull :: Socket Pull
| pull = undefined
| 
| readSocket :: forall sock . Readable sock => Socket sock -> IO Message
| readSocket (Socket _ f) = f (SRead :: SockOp sock 'Read)
| 
| On 02 Sep 2014, at 23:21 , Simon Peyton Jones 
| wrote:
| > I believe this is probably an instance of
| > https://ghc.haskell.org/trac/ghc/ticket/3927
| >
| > There are numerous other similar tickets, about GHC's
| inadequate/misleading warnings for non-exhaustive patterns.  A selection
| is
| > #595, #5728, #3927, #5724, #5762, #4139, #6124, #7669, #322, #8016,
| #8494, #8853, #8970, #9113.
| >
| > Tom Schrijvers and colleagues are working on this right now, I'm glad
| to say.
| >
| > Please do add your example to #3927, so that we can be sure to use it
| as a regression test when testing Tom's shiny new version.
| >
| > Simon
| >
| > | -Original Message-
| > | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| > | boun...@haskell.org] On Behalf Of Merijn Verstraaten
| > | Sent: 03 September 2014 06:59
| > | To: GHC Users List
| > | Subject: GHC not able to detect impossible GADT pattern
| > |
| > | I've been trying to stretch GHC's type system again and somehow
| managed
| > | to get myself into a position where GHC warns about a non-exhaustive
| > | pattern where adding the (according to GHC) missing pattern results
| in a
| > | type error (as inten

RE: GHC not able to detect impossible GADT pattern

[Simon Peyton Jones]

I believe this is probably an instance of
https://ghc.haskell.org/trac/ghc/ticket/3927

There are numerous other similar tickets, about GHC's inadequate/misleading 
warnings for non-exhaustive patterns.  A selection is
#595, #5728, #3927, #5724, #5762, #4139, #6124, #7669, #322, #8016, #8494, 
#8853, #8970, #9113.

Tom Schrijvers and colleagues are working on this right now, I'm glad to say.

Please do add your example to #3927, so that we can be sure to use it as a 
regression test when testing Tom's shiny new version.

Simon

| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Merijn Verstraaten
| Sent: 03 September 2014 06:59
| To: GHC Users List
| Subject: GHC not able to detect impossible GADT pattern
| 
| I've been trying to stretch GHC's type system again and somehow managed
| to get myself into a position where GHC warns about a non-exhaustive
| pattern where adding the (according to GHC) missing pattern results in a
| type error (as intended by me). It seems that even with closed type
| families GHC can't infer some patterns can never occur? Complete code to
| reproduce the issue is including below, the non-exhaustive pattern
| happens in the local definitions 'f' of push and pull.
| 
| I'm open to suggestions for other approaches.
| 
| Kind regards,
| Merijn
| 
| {-# LANGUAGE ConstraintKinds #-}
| {-# LANGUAGE DataKinds #-}
| {-# LANGUAGE GADTs #-}
| {-# LANGUAGE RankNTypes #-}
| {-# LANGUAGE ScopedTypeVariables #-}
| {-# LANGUAGE TypeFamilies #-}
| {-# LANGUAGE TypeOperators #-}
| {-# LANGUAGE UndecidableInstances #-}
| module Test where
| 
| import Data.Proxy
| import GHC.Exts
| 
| data Message
| 
| data SocketType = Dealer | Push | Pull
| 
| data SocketOperation = Read | Write
| 
| type family Restrict (a :: SocketOperation) (as :: [SocketOperation]) ::
| Constraint where
| Restrict a (a ': as) = ()
| Restrict x (a ': as) = Restrict x as
| Restrict x '[] = ("Error!" ~ "Tried to apply a restricted type!")
| 
| type family Implements (t :: SocketType) :: [SocketOperation] where
| Implements Dealer = ['Read, Write]
| Implements Push = '[Write]
| Implements Pull = '[ 'Read]
| 
| data SockOp :: SocketType -> SocketOperation -> * where
| SRead :: SockOp sock 'Read
| SWrite :: SockOp sock Write
| 
| data Socket :: SocketType -> * where
| Socket :: proxy sock
|-> (forall op . Restrict op (Implements sock) => SockOp sock
| op -> Operation op)
|-> Socket sock
| 
| type family Operation (op :: SocketOperation) :: * where
| Operation 'Read = IO Message
| Operation Write = Message -> IO ()
| 
| class Restrict 'Read (Implements t) => Readable t where
| readSocket :: Socket t -> Operation 'Read
| readSocket (Socket _ f) = f (SRead :: SockOp t 'Read)
| 
| instance Readable Dealer
| 
| type family Writable (t :: SocketType) :: Constraint where
| Writable Dealer = ()
| Writable Push = ()
| 
| dealer :: Socket Dealer
| dealer = Socket (Proxy :: Proxy Dealer) f
|   where
| f :: Restrict op (Implements Dealer) => SockOp Dealer op -> Operation
| op
| f SRead = undefined
| f SWrite = undefined
| 
| push :: Socket Push
| push = Socket (Proxy :: Proxy Push) f
|   where
| f :: Restrict op (Implements Push) => SockOp Push op -> Operation op
| f SWrite = undefined
| 
| pull :: Socket Pull
| pull = Socket (Proxy :: Proxy Pull) f
|   where
| f :: Restrict op (Implements Pull) => SockOp Pull op -> Operation op
| f SRead = undefined
| 
| foo :: IO Message
| foo = readSocket dealer
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Overlapping and incoherent instances

[Simon Peyton Jones]

| overlappable? In other words, does OVERLAPPABLE instruct the
| type checker to expect overlapping instances even if none of
| them are visible?

No, not at the moment.

Suppose we have
class C a where
  op :: a -> String

instance {-# OVERLAPPABLE #-} C a => C [a] where
  op x = "[a]"

instance {-# OVERLAPPING #-} C [Int] where 
  op x = "[Int]"

foo :: C a => a -> String
foo x = op [x] ++ "urk"

Then we (rightly) get an overlapping instance error when we try to solve the (C 
[a]) constraint arising from op [a] in foo's RHS.

But if we omit the type signature for foo, then GHC will (as before) not 
simplify the (C [a]) constraint, for the same reason, but because it's unsolved 
GHC will abstract over it to give the inferred type
foo :: C [a] => a -> String

But this only happens if the overlapping instance is visible here.  If the C 
[Int] instance is in some other module, then GHC will infer foo :: C a => a -> 
String.

Your point is that if the C [a] instance is marked OVERLAPPABLE, perhaps GHC 
should decline to simplify it, on the grounds that a more specific instance 
might appear.  But then the (C [a]) instance would never, ever be used!   (On 
the grounds that it might be overlapped by some as-yet-unseen instance.  So I 
don't think this would work.

In any case, if the current behaviour doesn't seem precisely defined by the 
user manual, could you suggest some words that would make it clearer?

Simon
| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Bertram Felgenhauer
| Sent: 07 August 2014 16:25
| To: glasgow-haskell-users@haskell.org
| Subject: Re: Overlapping and incoherent instances
| 
| Simon Peyton Jones wrote:
| > | >>On a largely unrelated note, here's another thing I don't
| > | >>understand: when is OVERLAPPABLE at one instance declaration
| > | >>preferable to using only OVERLAPPING at the instance declarations
| > | >>that overlap it?
| >
| > It's a user decision.  GHC allows
| >   - OVERLAPPABLE at the instance that is being overlapped, or
| >   - OVERLAPPING at the instance that is doing the overlapping, or
| >   - both
| 
| I'm curious how this affects simplification of contexts. If I have
| 
|   class Foo a
|   instance Foo a => Foo [a]
| 
| then GHC will simplify
| 
|   foo :: Foo [a] => a -> ()
| 
| to
| 
|   foo :: Foo a => a -> ()
| 
| Would this be prevented by declaring the Foo [a] instance as
| overlappable? In other words, does OVERLAPPABLE instruct the
| type checker to expect overlapping instances even if none of
| them are visible?
| 
| Cheers,
| 
| Bertram
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Overlapping and incoherent instances

[Simon Peyton Jones]

| >>Here's one concern I have with the deprecation of
| >>-XOverlappingInstances: I don't like overlapping instances, I find
| >>them confusing and weird and prefer to use code that doesn't
| >>include them, because they violate my expectations about how type
| >>classes work. When there is a single LANGUAGE pragma, that's a
| >>simple, easily-checkable signpost of "this code uses techniques
| >>that Ben doesn't understand". When it is all controlled by pragmas
| >>I basically have to check every instance declaration individually.

I see your point.  Though you could just grep for OVERLAP!

I suppose that -XOverlappingInstances could mean "silently honour 
OVERLAPPABLE/OVERLAPPING pragmas", while lacking it would mean "honour 
OVERLAPPABLE/OVERLAPPING pragmas, but emit noisy warnings" or even "don't 
honour them and warn".

But that is different to the behaviour today, so we'd need a new LANGUAGE 
pragma.  Perhaps -XHonourOverlappingInstances or something.

My sense is that the extra faff is not worth it.

| >>On a largely unrelated note, here's another thing I don't
| >>understand: when is OVERLAPPABLE at one instance declaration
| >>preferable to using only OVERLAPPING at the instance declarations
| >>that overlap it?

It's a user decision.  GHC allows
  - OVERLAPPABLE at the instance that is being overlapped, or
  - OVERLAPPING at the instance that is doing the overlapping, or
  - both

Another possible choice would be to require both.  One or t'other wouldn't do.  
But the current choice (with the LANGUAGE pragmas -XOverlappingInstances) is 
the either/or choice, and I had no user pressure to change that.  There *is* 
user pressure for the either/or semantics, so that you can *later* add an 
un-anticipated OVERLAPPING instance.

| >{-# LANGUAGE FlexibleInstances #-}
| >module M where
| >class C a where f :: a -> a
| >instance C a where f x = x
| >instance C Int where f x = x + 1
| >
| >I suspect many people have the intuition that NoOverlappingInstances
| >should forbid the above, but in fact OverlappingInstances or no only
| >controls instance *resolution*. I imagine you all already knew this
| >but I did not until I carefully reread things.

It's pretty clearly stated in the manual, but I'd be delighted to add a 
paragraph or two, or an example, if you can draft something and say where a 
good place for it would be (ie where you'd have looked).

Thanks

Simon

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

RE: Overlapping and incoherent instances

[Simon Peyton Jones]

| My proposal is to have just one pragma, e.g. OVERLAP, that allows
| overlap in either direction.  But if you have examples whether the
| extra sophistication introduced by a separation into OVERLAPPABLE and
| OVERLAPPING is needed, I am happy to go along...

Great!  As you'll see the proposal, "OVERLAPS" is precisely what you want.  I 
don't care whether it is called "OVERLAP" or "OVERLAPS".

So it sounds as if you are content.  (I assume you don't want to *prevent* 
careful programmers from saying something more precise.)

Simon

| 
| On 31.07.2014 10:13, Simon Peyton Jones wrote:
| > Andreas, remember that GHC 7.8 already implements (essentially) the
| same algorithm.  The difference is that 7.8 offers only the brutal -
| XOverlappingInstances to control it.  In your example of the decision
| you make when writing
| > instance Bla a => Bla [a]
| > vs
| > instance {-# OVERLAPPABLE #-} Bla a => Bla [a] you are, with GHC
| > 7.8, making precisely the same decision when you decide whether or
| not to add {-# LANGUAGE OverlappingInstances #-} to that module.
| Perhaps that wasn't clear in what I wrote; apologies.
| >
| > So your proposal seems to be this
| >
| > don't remove -XOverlappingInstances, because that will prevent
| > programmers from "flipping on/off pragmas until their program
| > goes through".
| >
| > It's hard to argue AGAINST providing the opportunity for more careful
| programmers to express their intentions more precisely, which is what
| the OVERLAP/OVERLAPPABLE pragmas do.
| >
| > Concerning deprecating OverlappingInstances, my gut feel is that it
| is positively a good thing to guide programmers towards a more robust
| programming style.  But my reason for starting this thread was to see
| whether or not others' gut feel is similar.
| >
| > Simon
| >
| > | -Original Message-----
| > | From: Libraries [mailto:libraries-boun...@haskell.org] On Behalf Of
| > | Andreas Abel
| > | Sent: 31 July 2014 08:59
| > | To: Simon Peyton Jones; ghc-devs; GHC users; Haskell Libraries
| > | (librar...@haskell.org)
| > | Subject: Re: Overlapping and incoherent instances
| > |
| > | On 31.07.2014 09:20, Simon Peyton Jones wrote:
| > | > Friends, in sending my message below, I should also have sent a
| > | > link to
| > | >
| > | > https://ghc.haskell.org/trac/ghc/ticket/9242#comment:25
| > |
| > | Indeed.
| > |
| > | Quoting from the spec:
| > |
| > |   * Eliminate any candidate IX for which both of the following
| hold:
| > | * There is another candidate IY that is strictly more specific;
| > |   that is, IY is a substitution instance of IX but not vice
| versa.
| > |
| > | * Either IX is overlappable or IY is overlapping.
| > |
| > | Mathematically, this makes a lot of sense.  But put on the hat of
| > | library writers, and users, and users that don't rtfm.  Looking out
| > | from under this hat, the one may always wonder whether one should
| > | make one's generic instances OVERLAPPABLE or not.
| > |
| > | If I create a library with type class Bla and
| > |
| > |instance Bla a => Bla [a]
| > |
| > | I could be a nice library writer and spare my users from declaring
| > | their Bla String instances as OVERLAPPING, so I'd write
| > |
| > |instance {-# OVERLAPPABLE #-} Bla a => Bla [a]
| > |
| > | Or maybe that would be malicious?
| > |
| > | I think the current proposal is too sophisticated.  There are no
| > | convincing examples given in the discussion so far that demonstrate
| > | where this sophistication pays off in practice.
| > |
| > | Keep in mind that 99% of the Haskell users will never study the
| > | instance resolution algorithm or its specification, but just flip
| > | on/off pragmas until their code goes through.  [At least that was
| my
| > | approach: whenever GHC asks for one more LANGUAGE pragma, just
| throw
| > | it in.]
| > |
| > | Cheers,
| > | Andreas
| > |
| > |
| > | > Comment 25 describes the semantics of OVERLAPPING/OVERLAPPABLE
| > | > etc, which I signally failed to do in my message below, leading
| to
| > | > confusion in the follow up messages.  My apologies for that.
| > | >
| > | > Some key points:
| > | >
| > | > *There is a useful distinction between /overlapping/ and
| > | > /overlappable/, but if you don't want to be bothered with it you
| > | > can just say OVERLAPS (which means both).
| > | >
| > | > *Overlap between two candidate instances is allowed if /either/
| > | > has the relevant property.  This is a bit sloppy, but reduces the
| > | > annotation burden.  Actually, with this per-instance stuff I
| think
| &

RE: Overlapping and incoherent instances

[Simon Peyton Jones]

Andreas, remember that GHC 7.8 already implements (essentially) the same 
algorithm.  The difference is that 7.8 offers only the brutal 
-XOverlappingInstances to control it.  In your example of the decision you make 
when writing 
   instance Bla a => Bla [a]
vs
   instance {-# OVERLAPPABLE #-} Bla a => Bla [a]
you are, with GHC 7.8, making precisely the same decision when you decide 
whether or not to add {-# LANGUAGE OverlappingInstances #-} to that module.  
Perhaps that wasn't clear in what I wrote; apologies.

So your proposal seems to be this

don't remove -XOverlappingInstances, because that will prevent
programmers from "flipping on/off pragmas until their program
goes through".

It's hard to argue AGAINST providing the opportunity for more careful 
programmers to express their intentions more precisely, which is what the 
OVERLAP/OVERLAPPABLE pragmas do.

Concerning deprecating OverlappingInstances, my gut feel is that it is 
positively a good thing to guide programmers towards a more robust programming 
style.  But my reason for starting this thread was to see whether or not 
others' gut feel is similar.

Simon

| -Original Message-
| From: Libraries [mailto:libraries-boun...@haskell.org] On Behalf Of
| Andreas Abel
| Sent: 31 July 2014 08:59
| To: Simon Peyton Jones; ghc-devs; GHC users; Haskell Libraries
| (librar...@haskell.org)
| Subject: Re: Overlapping and incoherent instances
| 
| On 31.07.2014 09:20, Simon Peyton Jones wrote:
| > Friends, in sending my message below, I should also have sent a link
| > to
| >
| > https://ghc.haskell.org/trac/ghc/ticket/9242#comment:25
| 
| Indeed.
| 
| Quoting from the spec:
| 
|   * Eliminate any candidate IX for which both of the following hold:
| * There is another candidate IY that is strictly more specific;
|   that is, IY is a substitution instance of IX but not vice versa.
| 
| * Either IX is overlappable or IY is overlapping.
| 
| Mathematically, this makes a lot of sense.  But put on the hat of
| library writers, and users, and users that don't rtfm.  Looking out
| from under this hat, the one may always wonder whether one should make
| one's generic instances OVERLAPPABLE or not.
| 
| If I create a library with type class Bla and
| 
|instance Bla a => Bla [a]
| 
| I could be a nice library writer and spare my users from declaring
| their Bla String instances as OVERLAPPING, so I'd write
| 
|instance {-# OVERLAPPABLE #-} Bla a => Bla [a]
| 
| Or maybe that would be malicious?
| 
| I think the current proposal is too sophisticated.  There are no
| convincing examples given in the discussion so far that demonstrate
| where this sophistication pays off in practice.
| 
| Keep in mind that 99% of the Haskell users will never study the
| instance resolution algorithm or its specification, but just flip
| on/off pragmas until their code goes through.  [At least that was my
| approach: whenever GHC asks for one more LANGUAGE pragma, just throw it
| in.]
| 
| Cheers,
| Andreas
| 
| 
| > Comment 25 describes the semantics of OVERLAPPING/OVERLAPPABLE etc,
| > which I signally failed to do in my message below, leading to
| > confusion in the follow up messages.  My apologies for that.
| >
| > Some key points:
| >
| > *There is a useful distinction between /overlapping/ and
| > /overlappable/, but if you don't want to be bothered with it you can
| > just say OVERLAPS (which means both).
| >
| > *Overlap between two candidate instances is allowed if /either/ has
| > the relevant property.  This is a bit sloppy, but reduces the
| > annotation burden.  Actually, with this per-instance stuff I think
| > it'd be perfectly defensible to require both to be annotated, but
| > that's a different discussion.
| >
| > I hope that helps clarify.
| >
| > I'm really pretty certain that the basic proposal here is good: it
| > implements the current semantics in a more fine-grained manner.  My
| > main motivation was to signal the proposed deprecation of the global
| > per-module flag -XoverlappingInstances.  Happily people generally
| seem
| > fine with this.   It is, after all, precisely what deprecations are
| for
| > ("the old thing still works for now, but it won't do so for ever, and
| > you should change as soon as is convenient").
| >
| > Thanks
| >
| > Simon
| >
| > *From:*Libraries [mailto:libraries-boun...@haskell.org] *On Behalf Of
| > *Simon Peyton Jones
| > *Sent:* 29 July 2014 10:11
| > *To:* ghc-devs; GHC users; Haskell Libraries (librar...@haskell.org)
| > *Subject:* Overlapping and incoherent instances
| >
| > Friends
| >
| > One of GHC's more widely-used features is overlapping (and sometimes
| > incoherent) instances.  The user-manual documentation is here
| > <http:

RE: Overlapping and incoherent instances

[Simon Peyton Jones]

Friends, in sending my message below, I should also have sent a link to
https://ghc.haskell.org/trac/ghc/ticket/9242#comment:25
Comment 25 describes the semantics of OVERLAPPING/OVERLAPPABLE etc, which I 
signally failed to do in my message below, leading to confusion in the follow 
up messages.  My apologies for that.
Some key points:

* There is a useful distinction between overlapping and overlappable, 
but if you don't want to be bothered with it you can just say OVERLAPS (which 
means both).

* Overlap between two candidate instances is allowed if either has the 
relevant property.  This is a bit sloppy, but reduces the annotation burden.  
Actually, with this per-instance stuff I think it'd be perfectly defensible to 
require both to be annotated, but that's a different discussion.
I hope that helps clarify.
I'm really pretty certain that the basic proposal here is good: it implements 
the current semantics in a more fine-grained manner.  My main motivation was to 
signal the proposed deprecation of the global per-module flag 
-XoverlappingInstances.  Happily people generally seem fine with this.   It is, 
after all, precisely what deprecations are for ("the old thing still works for 
now, but it won't do so for ever, and you should change as soon as is 
convenient").
Thanks
Simon

From: Libraries [mailto:libraries-boun...@haskell.org] On Behalf Of Simon 
Peyton Jones
Sent: 29 July 2014 10:11
To: ghc-devs; GHC users; Haskell Libraries (librar...@haskell.org)
Subject: Overlapping and incoherent instances

Friends
One of GHC's more widely-used features is overlapping (and sometimes 
incoherent) instances.  The user-manual documentation is 
here<http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#instance-overlap>.
The use of overlapping/incoherent instances is controlled by LANGUAGE pragmas: 
OverlappingInstances and IncoherentInstances respectively.
However the overlap/incoherent-ness is a property of the *instance declaration* 
itself, and has been for a long time.  Using LANGUAGE OverlappingInstances 
simply sets the "I am an overlapping instance" flag for every instance 
declaration in that module.
This is a Big Hammer.  It give no clue about *which* particular instances the 
programmer is expecting to be overlapped, nor which are doing the overlapping.  
  It brutally applies to every instance in the module.  Moreover, when looking 
at an instance declaration, there is no nearby clue that it might be 
overlapped.  The clue might be in the command line that compiles that module!
Iavor has recently implemented per-instance-declaration pragmas, so you can say

instance {-# OVERLAPPABLE #-} Show a => Show [a] where ...

instance {-# OVERLAPPING #-} Show [Char] where ...
This is much more precise (it affects only those specific instances) and it is 
much clearer (you see it when you see the instance declaration).
This new feature will be in GHC 7.10 and I'm sure you will be happy about that. 
 But I propose also to deprecate the LANGUAGE pragmas OverlappingInstances and 
IncoherentInstances, as way to encourage everyone to use the new feature 
instead of the old big hammer.  The old LANGUAGE pragmas will continue to work, 
of course, for at least another complete release cycle.  We could make that two 
cycles if it was helpful.
However, if you want deprecation-free libraries, it will entail a wave of 
library updates.
This email is just to warn you, and to let you yell if you think this is a bad 
idea.   It would actually not be difficult to retain the old LANGUAGE pragmas 
indefinitely - it just seems wrong not to actively push authors in the right 
direction.
These deprecations of course popped up in the test suite, so I've been 
replacing them with per-instance pragmas there too.  Interestingly in some 
cases, when looking for which instances needed the pragmas, I found...none. So 
OverlappingInstances was entirely unnecessary.  Maybe library authors will find 
that too!
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Overlapping and incoherent instances

[Simon Peyton Jones]

| One other issue this brings up: how does this all interact with -XSafe?
| Right now, Safety can be inferred by looking at the set of LANGUAGE
| pragmas and the import list. (Right?) With the change as implemented,
| Safe inference would require looking at all instance declarations. Is
| this OK?

I'm honestly not sure, but I do know that, in the implementation, each instance 
declaration keeps track of (a) whether it is 
OVERLAPPABLE/OVERLAPPING/INCOHERENT, and (b) the setting of -XSafe in the 
module where the instance declaration is given.

This doesn't change.  So I can't answer your question directly, but I think 
that the behaviour is unchanged from that at present.

Simon

| 
| Richard
| 
| On Jul 29, 2014, at 7:02 AM, Simon Peyton Jones 
| wrote:
| 
| > The current implementation requires the pragma exactly where showed
| it.
| >
| > I'm not keen on allowing it to be separated.
| >
| > I suppose with some more parser jiggery pokery it could be allowed
| immediately before (or, better, after).
| >
| > But cpp would let you say
| >
| > instance
| > #if blah
| >  {-# OVERLAPPABLE #-}
| > #endif
| >  Show a => Show [a] where ...
| >
| > Simon
| >
| > | -Original Message-
| > | From: Johan Tibell [mailto:johan.tib...@gmail.com]
| > | Sent: 29 July 2014 11:02
| > | To: Herbert Valerio Riedel
| > | Cc: Niklas Hambüchen; Haskell Libraries (librar...@haskell.org);
| GHC
| > | users; Simon Peyton Jones; ghc-devs
| > | Subject: Re: Overlapping and incoherent instances
| > |
| > | On Tue, Jul 29, 2014 at 11:50 AM, Herbert Valerio Riedel
| > | 
| > | wrote:
| > | > On 2014-07-29 at 11:29:45 +0200, Niklas Hambüchen wrote:
| > | >>> instance {-# OVERLAPPABLE #-} Show a => Show [a] where .
| > | >>
| > | >> Is the syntax somewhat flexible in where the pragma can be
| placed?
| > | >> For example, some might prefer
| > | >>
| > | >>   {-# OVERLAPPING #-}
| > | >>   instance Show [Char] where .
| > | >
| > | > This variant may also be more convenient in cases where you need
| > | > to CPP-guard that pragma, as it's on a separate line.
| > |
| > | Agreed, and if we remove the old pragma (even with a deprecation
| > | cycle) you'll see quite a few of those as many library authors try
| > | to have their libraries compile with the last 3 major GHC versions.
| > |
| > | P.S. For e.g. INLINABLE we require that you mention the function
| > | name next to the pragma (which means that you can e.g. put the
| > | pragma after the declaration). What's the rationale to not require
| > |
| > | {-# OVERLAPPING Show [Char] #-}
| > |
| > | here? Perhaps it's too annoying to have to repeat the types?
| > ___
| > Glasgow-haskell-users mailing list
| > Glasgow-haskell-users@haskell.org
| > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
| >

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

RE: Overlapping and incoherent instances

[Simon Peyton Jones]

CAN_OVERLAP and CAN_BE_OVERLAPPED?

(instead of OVERLAPPING and OVERLAPPABLE)

Or CAN-OVERLAP, CAN-BE-OVERLAPPED

That’s ok with me if that’s what you all want!

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Krzysztof Skrzetnicki
Sent: 29 July 2014 16:56
To: Brandon Allbery
Cc: Simon Peyton Jones; Andreas Abel; GHC users; Haskell Libraries 
(librar...@haskell.org); ghc-devs
Subject: Re: Overlapping and incoherent instances


How about CAN_OVERLAP?

--
Krzysztof
29-07-2014 15:40, "Brandon Allbery" 
mailto:allber...@gmail.com>> napisał(a):
On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel 
mailto:andreas.a...@ifi.lmu.de>> wrote:
+1. I like Niklas' syntax better.  Also OVERLAPPABLE is a horrible word, 
OVERLAPPING sound less formidable (even though it might be slightly less 
accurrate).

We already get "overlap ok" in instance-related type errors, so OVERLAP_OK 
wouldn't be particularly alien even if it doesn't quite fit in with existing 
pragmas.

--
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com<mailto:allber...@gmail.com> 
 ballb...@sinenomine.net<mailto:ballb...@sinenomine.net>
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

___
Libraries mailing list
librar...@haskell.org<mailto:librar...@haskell.org>
http://www.haskell.org/mailman/listinfo/libraries
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Overlapping and incoherent instances

[Simon Peyton Jones]

The current implementation requires the pragma exactly where showed it.

I'm not keen on allowing it to be separated.

I suppose with some more parser jiggery pokery it could be allowed immediately 
before (or, better, after).

But cpp would let you say

instance
#if blah
  {-# OVERLAPPABLE #-}
#endif
  Show a => Show [a] where ...

Simon

| -Original Message-
| From: Johan Tibell [mailto:johan.tib...@gmail.com]
| Sent: 29 July 2014 11:02
| To: Herbert Valerio Riedel
| Cc: Niklas Hambüchen; Haskell Libraries (librar...@haskell.org); GHC
| users; Simon Peyton Jones; ghc-devs
| Subject: Re: Overlapping and incoherent instances
| 
| On Tue, Jul 29, 2014 at 11:50 AM, Herbert Valerio Riedel 
| wrote:
| > On 2014-07-29 at 11:29:45 +0200, Niklas Hambüchen wrote:
| >>> instance {-# OVERLAPPABLE #-} Show a => Show [a] where …
| >>
| >> Is the syntax somewhat flexible in where the pragma can be placed?
| >> For example, some might prefer
| >>
| >>   {-# OVERLAPPING #-}
| >>   instance Show [Char] where …
| >
| > This variant may also be more convenient in cases where you need to
| > CPP-guard that pragma, as it's on a separate line.
| 
| Agreed, and if we remove the old pragma (even with a deprecation
| cycle) you'll see quite a few of those as many library authors try to
| have their libraries compile with the last 3 major GHC versions.
| 
| P.S. For e.g. INLINABLE we require that you mention the function name
| next to the pragma (which means that you can e.g. put the pragma after
| the declaration). What's the rationale to not require
| 
| {-# OVERLAPPING Show [Char] #-}
| 
| here? Perhaps it's too annoying to have to repeat the types?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Overlapping and incoherent instances

[Simon Peyton Jones]

Friends
One of GHC's more widely-used features is overlapping (and sometimes 
incoherent) instances.  The user-manual documentation is 
here.
The use of overlapping/incoherent instances is controlled by LANGUAGE pragmas: 
OverlappingInstances and IncoherentInstances respectively.
However the overlap/incoherent-ness is a property of the *instance declaration* 
itself, and has been for a long time.  Using LANGUAGE OverlappingInstances 
simply sets the "I am an overlapping instance" flag for every instance 
declaration in that module.
This is a Big Hammer.  It give no clue about *which* particular instances the 
programmer is expecting to be overlapped, nor which are doing the overlapping.  
  It brutally applies to every instance in the module.  Moreover, when looking 
at an instance declaration, there is no nearby clue that it might be 
overlapped.  The clue might be in the command line that compiles that module!
Iavor has recently implemented per-instance-declaration pragmas, so you can say

instance {-# OVERLAPPABLE #-} Show a => Show [a] where ...

instance {-# OVERLAPPING #-} Show [Char] where ...
This is much more precise (it affects only those specific instances) and it is 
much clearer (you see it when you see the instance declaration).
This new feature will be in GHC 7.10 and I'm sure you will be happy about that. 
 But I propose also to deprecate the LANGUAGE pragmas OverlappingInstances and 
IncoherentInstances, as way to encourage everyone to use the new feature 
instead of the old big hammer.  The old LANGUAGE pragmas will continue to work, 
of course, for at least another complete release cycle.  We could make that two 
cycles if it was helpful.
However, if you want deprecation-free libraries, it will entail a wave of 
library updates.
This email is just to warn you, and to let you yell if you think this is a bad 
idea.   It would actually not be difficult to retain the old LANGUAGE pragmas 
indefinitely - it just seems wrong not to actively push authors in the right 
direction.
These deprecations of course popped up in the test suite, so I've been 
replacing them with per-instance pragmas there too.  Interestingly in some 
cases, when looking for which instances needed the pragmas, I found...none. So 
OverlappingInstances was entirely unnecessary.  Maybe library authors will find 
that too!
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: GhcPlugin-writing and "finding things"

[Simon Peyton Jones]

Philip

You are right: there are some missing pieces.

* First you need to ask where your plugin's special library module "Foo" is in 
the file system. This is what findImportedModule is for, and it seems quite 
reasonable.  However, it (or some variant) should be available to you in CoreM.

* Next, suppose you special library module defines a special type "T".  You 
need to get its Name.  For this you a CoreM variant of IfaceEnv.lookupOrig.  
The function CoreMonad.getOrigNameCache is far too low level and should be 
killed.  Instead, CoreMonad should expose 
lookupOrig :: Module -> OccName -> CoreM Name
It should be an easy function to write, using IfaceEnv.lookupOrig; maybe a tiny 
bit of refactoring.

* Next you want to get from T's Name to T's TyCon. Here CoreMonad is fine: it 
offers 
lookupThing :: Name -> CoreM TyThing
This function calls TcEnv.tcLookupGlobal, which will automatically load Foo.hi 
if need be.

So your code should look like

foo_mod <- findImportedModule "Foo"
t_name  <- lookupOrig foo_mod (mkTcOcc "T")
t_tycon <- lookupThing t_name

corresponding to these three steps.  I suspect that the error cases of 
findImported module should be dealt with via exceptions in CoreM, to de-clutter 
the code.


Some of the above suggests a bit of cleaning up of the CoreM API. Would someone 
like to undertake that?  I can advise, but I don't want to lead.

Simon


| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of p.k.f.holzensp...@utwente.nl
| Sent: 23 July 2014 17:07
| To: glasgow-haskell-users@haskell.org
| Subject: GhcPlugin-writing and "finding things"
| 
| Dear GHC-ers,
| 
| I'm working on a plugin for GHC that should help compile the library
| with which this plugin is to ship. What this plugin does is traverse
| the CoreProgram(s) to find things of types defined in my library and
| optimizes them. I have worked out how to "find" things, but I was
| wondering whether the API could be improved for plugin-writers.
| 
| For the sake of argument, I have the following:
|  - module Foo: library for users to import, containing functions, ADTs
| etc
|  - module Foo.Plugin: GhcPlugin that compiles out all uses of things in
| Foo
| 
| > module Foo where
| >
| > data Foo x = Foo x
| >
| > runFoo :: Foo x -> x
| > runFoo (Foo x) = x
| 
| 
| This example is trivial and I imagine GHC will have no trouble
| eliminating most cases of this, but imagine more complex stuff. Now, if
| I want to traverse the CoreProgram in my plugin, I need to find
| occurrences of these, so somewhere there's stuff like:
| 
| > pass tcFoo _ _ (NonRec b expr)
| >   | varType b `containsTyConAnywhere` tcFoo
| > = {- clever stuff to compile out Foo -}
| 
| My problem is "getting" tcFoo in this example. Below is how I do it
| now. Maybe I'm being thick, or maybe there's just no simpler way. This
| is my 'plugin' function in Foo.Plugin:
| 
| > plugin = Plugin $ \opts todo -> do
| >  hsc <- getHscEnv
| >  dfs <- getDynFlags
| >  fr  <- liftIO $ findImportedModule hsc (mkModuleName "Foo") Nothing
| > mod <- case fr of
| >Found ml m -> return m
| >_ -> panic "Failed to (unambiguously) find 'Foo' (using
| findImportedModule)"
| >  onc <- getOrigNameCache
| >  let nms = lookupWithDefaultModuleEnv nms (panic "No names defined
| for module 'Foo'") mod
| >  find_ d occ fnd nm
| >= maybe
| >(fail $ "Failed to find " ++ d ++ " '" ++ nm ++ "'")
| >fnd
| >(lookupOccEnv nms $ occ nm)
| >  tcFind = find_ "TyCon"   mkTcOcc   lookupTyCon
| >  dcFind = find_ "DataCon" mkDataOcc lookupDataCon
| >  idFind = find_ "Id"  mkVarOcc  lookupId
| >  tcFoo<- tcFind "Foo"
| >  dcFoo<- dcFind "Foo"
| >  idRunFoo <- idFind "runFoo"
| >  return $ CoreDoPluginPass "Foo optimisation" (pass tcFoo dcFoo
| > idRunFoo) : todo
| 
| I have the following questions:
| 
|   1) Is this a/the right way to "find" those things in the plugin?
|   2) There seems to be a lot to gain with quasi-quoting a la Template
| Haskell for people writing plugins to go with a library that they
| wrote. Can such QQ be done? Has it been considered?
|   3) Is findImportedModule the right function to find my starting point
| to begin with?
|   4) What is the 'Maybe FastString' argument in findImportedModule for?
| I've been trying to put in the FSs of PackageIDs, but they make the
| lookup fail. This (dumb) example really made me nervous:
| 
| >  fr  <- liftIO $ findImportedModule hsc (mkModuleName "Foo") Nothing
| > mod <- case fr of
| >Found ml m -> do
| >  fr' <- liftIO $ findImportedModule hsc (moduleName m)
| > (packageIdFS $ packageId m)
| 
| Here, fr' should always be a "Found ml' m'" such that ml == ml' and m
| == m', but... it consistently results in NotFound{} for me. Also, I
| find this especially round-about. Shouldn't Paths_Foo.hs (the Cabal-
| generated file) maybe contain variables for every 

RE: Type family stopped compiling on upgrade from GHC 7.6.3 to 7.8.3

[Simon Peyton Jones]

I don't know why 7.6.3 accepts it.  'Float' is a valid type but not a valid 
kind.  For it to be a useful kind we'd need float literal at the type level, 
and we have no such thing.  You can use Nat instead, which does exist at the 
type level.

Simon

| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of cheater00 .
| Sent: 21 July 2014 18:51
| To: glasgow-haskell-users@haskell.org
| Subject: Type family stopped compiling on upgrade from GHC 7.6.3 to
| 7.8.3
| 
| Hi, I was experimenting a bit with type families recently and ran into
| a bit of an issue. Given that I don't know type families that well yet,
| I was wondering if I made an error somewhere. One thing is that I can't
| find any relevant changes in the GHC release notes for 7.8.1, .2 or .3.
| 
| Maybe this code contains an error which 7.6.3 simply wasn't able to
| find?
| 
| Thanks.
| 
| 
| 
| -- this code compiles in 7.6.3, but breaks in 7.8.3 with the following
| message:
| -- TypeFamilies.hs:14:31:
| -- ‘End’ of kind ‘*’ is not promotable
| -- In the kind ‘End’
| -- In 7.6.3, using :kind!, I can see that the type synonyms contained
| in the family do work the way I intend them to.
| 
| 
| {-# Language
| GADTs
|   , TypeFamilies
|   , DataKinds
|#-}
| module TypeFamilies where
| 
| data End = Least | Spot Float | Most
|   deriving (Eq, Show)
| 
| data Interval = IntervalCons { left :: End, right :: End }
|   deriving (Eq, Show)
| 
| type family   Interval2 (a :: End) (b :: End) :: Interval
| type instance Interval2  Least  Most  =  IntervalCons  Least
| Most
| type instance Interval2 (Spot l)Most  =  IntervalCons (Spot l)
| Most
| type instance Interval2  Least (Spot r)   =  IntervalCons  Least
| (Spot r)
| type instance Interval2 (Spot l)   (Spot r)   =  IntervalCons (Spot l)
| (Spot r)
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users