Re: Kind classes and associated closed type families

[Ryan Scott]

...actually, nevermind, it's not a bug after all. It was just me being
boneheaded. Since Extract has a polymorphic return kind, there's no
way for GHCi to know what the kind of Extract 0 '(Int, Char) will be
unless there's a kind ascription. If you be more explicit, then GHCi
knows what to do:

> :kind! (Extract 0 '(Int, Char) :: *)
(Extract 0 '(Int, Char) :: *) :: *
= Int
> :kind! (Extract 0 '(Int, Char) :: * -> *)
(Extract 0 '(Int, Char) :: * -> *) :: * -> *
= (TypeError ...)

Thanks to Reid Barton for pointing this out to me.

Ryan S.
-
[1] https://ghc.haskell.org/trac/ghc/ticket/10116
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Kind classes and associated closed type families

[Ryan Scott]

Running :kind! twice in a row does nothing, and your hunch was
correct: it does appear to be a bug. Specifically, it's a bug that
affects type families with polymorphic return kinds (like Extract,
which has kind y). I've opened Trac #11275 [1] for this issue.

Ryan S.
-
[1] https://ghc.haskell.org/trac/ghc/ticket/11275
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Kind classes and associated closed type families

[Richard Eisenberg]

On Dec 18, 2015, at 2:03 PM, Ryan Scott  wrote:

> I presumed this was because :kind! didn't do any type family reduction
> whenever something was undecidable in general (to ensure :kind! always
> terminates, I suppose).

No. :kind! isn't that smart.

Out of curiosity, what happens if you try again? As in, run :kind! ... twice, 
exactly the same both times. I seem to recall a ticket saying that worked. 
Regardless, this is just a plain old bug. Please post a report.

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

Re: Kinds of type synonym arguments

[Reid Barton]

On Mon, Dec 21, 2015 at 5:13 AM, Simon Peyton Jones 
wrote:

> newtype T = MkT Int#
>
>
>
> Provided T :: # (i.e. unlifted), I don’t think this would be too hard.
> That is, you can give a new name (via newtype) to an unlifted type like
> Int#, Float#, Double# etc.
>
>
>
> Worth a wiki page and a ticket.
>

There is already a ticket at least,
https://ghc.haskell.org/trac/ghc/ticket/1311.

Regards,
Reid Barton
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Change from 7.10.3 to current master

[Simon Peyton Jones]

|  type instance r1 :++: r2 :> a = (r1 :++: r2) :> a

What do you expect this to mean?  I suppose you could hope that GHC will 
unravel the fixity of :++: and :>, to determine whether you are giving an 
instance for :++: or for :>?

That sounds reasonable, but it's not trivial.

Currently the LHS of a 'type instance' decl is ultimately a TyFamEqn, and it 
looks like this:


data TyFamEqn name pats
  = TyFamEqn
   { tfe_tycon :: Located name
   , tfe_pats  :: pats
   , tfe_rhs   :: LHsType name }


So we've already decided (in the parser) what the type-function name is.  But 
we can't do that in this case, because the parser doesn't understand fixity.

To deal with this we'd need to change to

data TyFamEqn name pats
  = TyFamEqn
   { tfe_lhs  :: LHSType name
   , tfe_rhs   :: LHsType name }

so that the LHS was just a type.  Now the renamer can re-jiggle its fixities in 
the usual way, and only in the type checker will we need to decide exactly 
which type it's an instance of.  Easy!

This might be a good change to make! It's a bit like in ClsInstDecl, you'll see 
that the instance cid_poly_ty is just a LHsSigType, i.e. not decomposed into 
which class it is.


So: my instinct is that the above would be Fine Thing.  Make a ticket?  Add 
these comments to give context?  Excecute?

Thanks

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan
|  & Kim Zimmerman
|  Sent: 20 December 2015 18:55
|  To: ghc-devs@haskell.org
|  Subject: Change from 7.10.3 to current master
|  
|  I am in the process of updating ghc-exactprint for current GHC master.
|  
|  One of the tests has the following in it
|  
|  -
|  {-# LANGUAGE TypeOperators #-}
|  
|  type family (r1 :++: r2); infixr 5 :++:
|  type instance r :++: Nil = r
|  type instance r1 :++: r2 :> a = (r1 :++: r2) :> a
|  --
|  
|  Current GHC master rejects this with
|  
|  /tmp/Foo.hs:5:15: error:
|  Malformed head of type or class declaration: r1 :++: r2 :> a
|  
|  Is this expected, or a bug?
|  
|  Alan
|  ___
|  ghc-devs mailing list
|  ghc-devs@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
|  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c17b33d7be13045d
|  d141308d3096f2bc5%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LGroqdv
|  nYFSxydfZFQydhi2N6lltWwi%2b4tt%2bM3LH0P0%3d
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Kinds of type synonym arguments

[Simon Peyton Jones]

newtype T = MkT Int#

Provided T :: # (i.e. unlifted), I don’t think this would be too hard.  That 
is, you can give a new name (via newtype) to an unlifted type like Int#, 
Float#, Double# etc.

Worth a wiki page and a ticket.

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Edward Kmett
Sent: 21 December 2015 09:10
To: Ömer Sinan Ağacan 
Cc: ghc-devs 
Subject: Re: Kinds of type synonym arguments

I brought up the subject of allowing newtypes in kind # (or even in any kind 
that ends in * or # after a chain of ->'s to get more powerful Coercible 
instances) at ICFP this year and Simon seemed to think it'd be a pretty 
straightforward modification to the typechecker.

I confess, he's likely waiting for me to actually sit down and give the idea a 
nice writeup. ;)

This would be good for many things, especially when it comes to improving the 
type safety of various custom c-- tricks.

-Edward

On Sun, Dec 20, 2015 at 2:14 PM, Ömer Sinan Ağacan 
mailto:omeraga...@gmail.com>> wrote:
I have another related question: What about allowing primitive types
in newtypes?

λ:4> newtype Blah1 = Blah1 Int
λ:5> newtype Blah2 = Blah2 Int#

:5:23: error:
• Expecting a lifted type, but ‘Int#’ is unlifted
• In the type ‘Int#’
  In the definition of data constructor ‘Blah2’
  In the newtype declaration for ‘Blah2’

Ideally second definition should be OK, and kind of Blah2 should be #. Is this
too hard to do?

2015-12-16 17:22 GMT-05:00 Richard Eisenberg 
mailto:e...@cis.upenn.edu>>:
>
> On Dec 16, 2015, at 2:06 PM, Ömer Sinan Ağacan 
> mailto:omeraga...@gmail.com>> wrote:
>>
>> In any case, this is not that big deal. When I read the code I thought this
>> should be a trivial change but apparently it's not.
>
> No, it's not. Your example (`f :: (Int#, b) -> b`) still has an unboxed thing 
> in a boxed tuple. Boxed tuples simply can't (currently) hold unboxed things. 
> And changing that is far from trivial. It's not the polymorphism that's the 
> problem -- it's the unboxed thing in a boxed tuple.
>
> Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

Re: ExprWithTySigOut

[Herbert Valerio Riedel]

Hi,

Btw, I also used that annoying pattern in

  https://phabricator.haskell.org/D1185

to represent type-signature sections before/after typechecking:
  
​  -- | Type-signature operator sections
​
​  | TySigSection(LHsType id)
​   (PostRn id [Name])  -- wildcards
​
​  | TySigSectionOut (LHsType Name)
​   (PostTc id Type)
​   (PostTc id Coercion)

I'd be interested in better ideas as well...

On 2015-12-21 at 09:46:58 +0100, Simon Peyton Jones wrote:
> Yes this is annoying.
>
> The thing is that with the first constructor only we'd get
>   (LHsSigWcType Id)
> after type checking, but we don't have such a thing. `HsTypes` are 
> typechecked to `Types`.  
>
> Perhaps we could have
>   (LHsSigWcType (StopAtRenamer d))
>
> where
>   type family StopAtRenamer a where
>   StopAtRenamer Id = Name
>   StopAtRenamer x = x
>
> If this pattern happened a lot it might be worth it.  But I think this is the 
> only occurrence.
>
> Better ideas welcome.
>
> Simon
>
> |  -Original Message-
> |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan
> |  & Kim Zimmerman
> |  Sent: 19 December 2015 13:15
> |  To: ghc-devs@haskell.org
> |  Subject: ExprWithTySigOut
> |  
> |  At the moment HsExpr includes the following two constructors
> |  
> || ExprWithTySig
> |  (LHsExpr id)
> |  (LHsSigWcType id)
> |  
> || ExprWithTySigOut  -- Post typechecking
> |  (LHsExpr id)
> |  (LHsSigWcType Name)  -- Retain the signature,
> |   -- as HsSigType Name, for
> |   -- round-tripping purposes
> |  
> |  I do not understand why we need the second one, which hard-codes Name
> |  instead of id.
> |  
> |  There are a couple of places where there is an XXXOut variant with
> |  hard coded Name parameter, and these complicate creating any kind of
> |  custom class intended to work on a parameterised AST as it ripples out
> |  and forces Name instances of it everywhere.
> |  
> |  Perhaps we should introduce HsExprLR id id to cope with renaming?
> |  
> |  Alan
> |  ___
> |  ghc-devs mailing list
> |  ghc-devs@haskell.org
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
> |  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c70b008fd4c5b43b
> |  3915e08d308766f7d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MB%2fBX
> |  bBIUeYFlOOH5PGXV27wJpZRNKcHJV%2fTQmfI%2f%2bE%3d
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- 
"Elegance is not optional" -- Richard O'Keefe
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Kinds of type synonym arguments

[Edward Kmett]

I brought up the subject of allowing newtypes in kind # (or even in any
kind that ends in * or # after a chain of ->'s to get more powerful
Coercible instances) at ICFP this year and Simon seemed to think it'd be a
pretty straightforward modification to the typechecker.

I confess, he's likely waiting for me to actually sit down and give the
idea a nice writeup. ;)

This would be good for many things, especially when it comes to improving
the type safety of various custom c-- tricks.

-Edward

On Sun, Dec 20, 2015 at 2:14 PM, Ömer Sinan Ağacan 
wrote:

> I have another related question: What about allowing primitive types
> in newtypes?
>
> λ:4> newtype Blah1 = Blah1 Int
> λ:5> newtype Blah2 = Blah2 Int#
>
> :5:23: error:
> • Expecting a lifted type, but ‘Int#’ is unlifted
> • In the type ‘Int#’
>   In the definition of data constructor ‘Blah2’
>   In the newtype declaration for ‘Blah2’
>
> Ideally second definition should be OK, and kind of Blah2 should be #. Is
> this
> too hard to do?
>
> 2015-12-16 17:22 GMT-05:00 Richard Eisenberg :
> >
> > On Dec 16, 2015, at 2:06 PM, Ömer Sinan Ağacan 
> wrote:
> >>
> >> In any case, this is not that big deal. When I read the code I thought
> this
> >> should be a trivial change but apparently it's not.
> >
> > No, it's not. Your example (`f :: (Int#, b) -> b`) still has an unboxed
> thing in a boxed tuple. Boxed tuples simply can't (currently) hold unboxed
> things. And changing that is far from trivial. It's not the polymorphism
> that's the problem -- it's the unboxed thing in a boxed tuple.
> >
> > Richard
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: ExprWithTySigOut

[Simon Peyton Jones]

Yes this is annoying.

The thing is that with the first constructor only we'd get
(LHsSigWcType Id)
after type checking, but we don't have such a thing. `HsTypes` are typechecked 
to `Types`.  

Perhaps we could have
(LHsSigWcType (StopAtRenamer d))

where
type family StopAtRenamer a where
StopAtRenamer Id = Name
StopAtRenamer x = x

If this pattern happened a lot it might be worth it.  But I think this is the 
only occurrence.

Better ideas welcome.

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan
|  & Kim Zimmerman
|  Sent: 19 December 2015 13:15
|  To: ghc-devs@haskell.org
|  Subject: ExprWithTySigOut
|  
|  At the moment HsExpr includes the following two constructors
|  
|| ExprWithTySig
|  (LHsExpr id)
|  (LHsSigWcType id)
|  
|| ExprWithTySigOut  -- Post typechecking
|  (LHsExpr id)
|  (LHsSigWcType Name)  -- Retain the signature,
|   -- as HsSigType Name, for
|   -- round-tripping purposes
|  
|  I do not understand why we need the second one, which hard-codes Name
|  instead of id.
|  
|  There are a couple of places where there is an XXXOut variant with
|  hard coded Name parameter, and these complicate creating any kind of
|  custom class intended to work on a parameterised AST as it ripples out
|  and forces Name instances of it everywhere.
|  
|  Perhaps we should introduce HsExprLR id id to cope with renaming?
|  
|  Alan
|  ___
|  ghc-devs mailing list
|  ghc-devs@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
|  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c70b008fd4c5b43b
|  3915e08d308766f7d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MB%2fBX
|  bBIUeYFlOOH5PGXV27wJpZRNKcHJV%2fTQmfI%2f%2bE%3d
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: [commit: ghc] master: SrcLoc: Eliminate constructors of RealSrcSpan (987426c)

[Simon Peyton Jones]

1% is huge!  Good to do.

|  -Original Message-
|  From: Ben Gamari [mailto:b...@well-typed.com]
|  Sent: 19 December 2015 11:51
|  To: Simon Peyton Jones ; ghc-devs@haskell.org
|  Subject: RE: [commit: ghc] master: SrcLoc: Eliminate constructors of
|  RealSrcSpan (987426c)
|  
|  Simon Peyton Jones  writes:
|  
|  > Does this change yield any benefits?  Eg. if we can now unbox SrcLoc
|  does something go faster?
|  >
|  Compiler allocations in the testsuite decrease between 0 and 1% [1].
|  
|  Moreover, it still seemed like a reasonable clean-up given it is a net
|  reduction in code length with no loss of clarity.
|  
|  Cheers,
|  
|  - Ben
|  
|  
|  [1] https://perf.haskell.org/ghc/#table-6
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs