RE: Concrete syntax for open type kind?
Is it possible to do so with any sort of concrete syntax?
I’m afraid not. And I’m strongly disinclined to add it because we’d then just
delete it again. Are you really really stuck?
S
From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org]
On Behalf Of Conal Elliott
Sent: 19 April 2014 01:11
To: Simon Peyton Jones
Cc: glasgow-haskell-users@haskell.org
Subject: Re: Concrete syntax for open type kind?
Thanks for that explanation, Simon. The new scheme sounds neater, indeed. Looks
like the same trick used for inheritance mentioned in Calling hell from heaven
and heaven from hellhttp://research.microsoft.com/pubs/64260/comserve.ps.gz.
Meanwhile, I think I can work around the limitation, somewhat clumsily, of no
open kinds if I could make a definition polymorphic over unlifted kinds, e.g.,
foo :: #
foo = error foo?
Is it possible to do so with any sort of concrete syntax?
-- Conal
On Wed, Apr 16, 2014 at 2:35 PM, Simon Peyton Jones
simo...@microsoft.commailto:simo...@microsoft.com wrote:
Does anyone remember the justification of not having unlifted or open kinds in
the source language?
They aren’t in the source language because they are a gross hack, with many
messy consequences. Particularly the necessary sub-kinding, and the impact on
inference. I’m not proud of it.
But I do have a plan. Namely to use polymorphism. Currently we have
kindsk ::= * | # | ? | k1 - k2 | ...
Instead I propose
kinds k ::= TYPE bx | k1 - k2 |
boxity bx ::= BOXED | UNBOXED | bv
where bv is a boxity variable
So
•* = TYPE BOXED
•# = TYPE UNBOXED
•? = TYPE bv
Now error is polymorphic:
error :: forall bv. forall (a:TYPE bv). String - a
And now everything will work out smoothly I think. And it should be reasonably
easy to expose in the source language.
All that said, there’s never enough time to do these things.
Simon
From: Glasgow-haskell-users
[mailto:glasgow-haskell-users-boun...@haskell.orgmailto:glasgow-haskell-users-boun...@haskell.org]
On Behalf Of Conal Elliott
Sent: 16 April 2014 18:01
To: Richard Eisenberg
Cc: glasgow-haskell-users@haskell.orgmailto:glasgow-haskell-users@haskell.org
Subject: Re: Concrete syntax for open type kind?
Oops! I was reading ParserCore.y, instead of Parser.y.pp. Thanks.
Too bad it's not possible to replicate this type interpretation of `error` and
`undefined`. I'm doing some Core transformation, and I have a polymorphic
function (reify) that I want to apply to expressions of lifted and unlifted
types, as a way of structuring the transformation. When my transformation gets
to unlifted types, the application violates the *-kindedness of my polymorphic
function. I can probably find a way around. Maybe I'll build the kind-incorrect
applications and then make sure to transform them away in the end. Currently,
the implementation invokes `error`.
Does anyone remember the justification of not having unlifted or open kinds in
the source language?
-- Conal
On Tue, Apr 15, 2014 at 5:09 PM, Richard Eisenberg
e...@cis.upenn.edumailto:e...@cis.upenn.edu wrote:
What version of the GHC code are you looking at? The parser is currently stored
in compiler/parser/Parser.y.pp (note the pp) and doesn’t have these lines. As
far as I know, there is no way to refer to OpenKind from source.
You’re absolutely right about the type of `undefined`. `undefined` (and
`error`) have magical types. GHC knows that GHC.Err defines an `undefined`
symbol and gives it its type by fiat. There is no way (I believe) to reproduce
this behavior.
If you have -fprint-explicit-foralls and -fprint-explicit-kinds enabled,
quantified variables of kind * are not given kinds in the output. So, the lack
of a kind annotation tells you that `a`’s kind is *. Any other kind (assuming
these flags) would be printed.
I hope this helps!
Richard
On Apr 15, 2014, at 7:39 PM, Conal Elliott
co...@conal.netmailto:co...@conal.net wrote:
I see ‘#’ for unlifted and ‘?’ for open kinds in compiler/parser/Parser.y:
akind :: { IfaceKind }
: '*' { ifaceLiftedTypeKind }
| '#' { ifaceUnliftedTypeKind }
| '?' { ifaceOpenTypeKind }
| '(' kind ')' { $2 }
kind:: { IfaceKind }
: akind{ $1 }
| akind '-' kind { ifaceArrow $1 $3 }
However, I don’t know how to get GHC to accept ‘#’ or ‘?’ in a kind annotation.
Are these kinds really available to source programs.
I see that undefined has an open-kinded type:
*Main :i undefined
undefined :: forall (a :: OpenKind). a -- Defined in ‘GHC.Err’
Looking in the GHC.Err source, I just see the following:
undefined :: a
undefined = error Prelude.undefined
However, if I try similarly,
q :: a
q = error q
I don’t see a similar type:
*X :i q
q :: forall a. a-- Defined at ../test/X.hs:12:1
I don't know what kind 'a' has here, nor
Tightening up on inferred type signatures
Friends GHC generally obeys this rule * If GHC infers a type f::type, then it's OK for you to add a type signature saying exactly that. For example, it rejects inferred types that are ambiguous. I think this is a good property; it was certainly the source of many bug reports before inferred ambiguous types were rejected. However, up to now (including in 7.8) GHC hasn't followed this rule consistently. In particular, it will infer types like fold :: (Functor (PF a), Regular a) = (PF a b - b) - a - b (where PF is a type family). If you write this as a type signature, GHC will insist on FlexibleContexts and TypeFamilies. So in https://ghc.haskell.org/trac/ghc/ticket/8883, Jan has made GHC check inferred types in the same way that it checks declared types, thus rejecting the above inferred type unless you give the language extensions. This makes the compiler more consistent. But it does mean that some code may be rejected that 7.8 accepts. This email is just a heads-up that you might want to compile your library with 7.10 (i.e. a snapshot of HEAD) well in advance. There will be other breaking changes of course; e.g Applicative will finally be a superclass of Monad, for example. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [core libraries] Tightening up on inferred type signatures
No objections here. The types involved really *do* have FlexibleContexts in them, so it makes sense to require the extension. The upgrade path for library authors is also clear. It'll complain to add the extension, and they'll fix it by adding the line of code suggested and perhaps realize something about their code in the process. -Edward On Mon, Apr 21, 2014 at 4:30 AM, Simon Peyton Jones simo...@microsoft.comwrote: Friends GHC generally obeys this rule · If GHC infers a type *f::type*, then it’s OK for you to add a type signature saying exactly that. For example, it rejects inferred types that are ambiguous. I think this is a good property; it was certainly the source of many bug reports before inferred ambiguous types were rejected. However, up to now (including in 7.8) GHC hasn’t followed this rule consistently. In particular, it will infer types like fold :: (Functor (PF a), Regular a) = (PF a b - b) - a - b (where PF is a type family). If you write this as a type signature, GHC will insist on FlexibleContexts and TypeFamilies. So in https://ghc.haskell.org/trac/ghc/ticket/8883, Jan has made GHC check inferred types in the same way that it checks declared types, thus rejecting the above inferred type unless you give the language extensions. This makes the compiler more consistent. But it does mean that some code may be rejected that 7.8 accepts. This email is just a heads-up that you might want to compile your library with 7.10 (i.e. a snapshot of HEAD) well in advance. There will be other breaking changes of course; e.g Applicative will finally be a superclass of Monad, for example. Simon -- You received this message because you are subscribed to the Google Groups haskell-core-libraries group. To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Concrete syntax for open type kind?
Thanks, Simon. I wouldn’t say that I’m really really stuck yet, and I’d rather no one wasted time on a dead-end workaround. I like the plan you described using kind polymorphism instead of subkinding, because I think the relaxed kinds would naturally be inferred where I need them. The problem I’m trying to solve here is defining a GADT for statically typed expressions, where some types are lifted and some are unlifted: data E ∷ ? → * where ⋯ App ∷ ∀ (a ∷ ?) (b ∷ ?) . E (a → b) → E a → E b ⋯ All literals would be monomorphic and unlifted, and E itself is lifted, so we’d never need to represent anything of an open-kinded type in GHC’s RTS. Instead, the ? kinds here are purely for managing the type constraints needed to ensure well-typedness of represented expressions while still allowing enough generality, including both lifted and unlifted types. Without support for open kinds (somehow), I don’t know of any way to say what I need to say. I’ll keep trying to find ways to avoid this limitation. Meanwhile, I’d like to explore what it’d take to change over the current subkinding system to the polymorphic one. I’ve not done such a project, but I’d be glad to help and learn my way around in the process. -- Conal On Mon, Apr 21, 2014 at 12:20 AM, Simon Peyton Jones simo...@microsoft.comwrote: Is it possible to do so with any sort of concrete syntax? I’m afraid not. And I’m strongly disinclined to add it because we’d then just delete it again. Are you really really stuck? S *From:* Glasgow-haskell-users [mailto: glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Conal Elliott *Sent:* 19 April 2014 01:11 *To:* Simon Peyton Jones *Cc:* glasgow-haskell-users@haskell.org *Subject:* Re: Concrete syntax for open type kind? Thanks for that explanation, Simon. The new scheme sounds neater, indeed. Looks like the same trick used for inheritance mentioned in Calling *hell*from *heaven* and *heaven* from *hell*http://research.microsoft.com/pubs/64260/comserve.ps.gz . Meanwhile, I think I can work around the limitation, somewhat clumsily, of no open kinds if I could make a definition polymorphic over unlifted kinds, e.g., foo :: # foo = error foo? Is it possible to do so with any sort of concrete syntax? -- Conal On Wed, Apr 16, 2014 at 2:35 PM, Simon Peyton Jones simo...@microsoft.com wrote: Does anyone remember the justification of not having unlifted or open kinds in the source language? They aren’t in the source language because they are a gross hack, with many messy consequences. Particularly the necessary sub-kinding, and the impact on inference. I’m not proud of it. But I do have a plan. Namely to use polymorphism. Currently we have kindsk ::= * | # | ? | k1 - k2 | ... Instead I propose kinds k ::= TYPE bx | k1 - k2 | boxity bx ::= BOXED | UNBOXED | bv where bv is a boxity variable So ·* = TYPE BOXED ·# = TYPE UNBOXED ·? = TYPE bv Now error is polymorphic: error :: forall bv. forall (a:TYPE bv). String - a And now everything will work out smoothly I think. And it should be reasonably easy to expose in the source language. All that said, there’s never enough time to do these things. Simon *From:* Glasgow-haskell-users [mailto: glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Conal Elliott *Sent:* 16 April 2014 18:01 *To:* Richard Eisenberg *Cc:* glasgow-haskell-users@haskell.org *Subject:* Re: Concrete syntax for open type kind? Oops! I was reading ParserCore.y, instead of Parser.y.pp. Thanks. Too bad it's not possible to replicate this type interpretation of `error` and `undefined`. I'm doing some Core transformation, and I have a polymorphic function (reify) that I want to apply to expressions of lifted and unlifted types, as a way of structuring the transformation. When my transformation gets to unlifted types, the application violates the *-kindedness of my polymorphic function. I can probably find a way around. Maybe I'll build the kind-incorrect applications and then make sure to transform them away in the end. Currently, the implementation invokes `error`. Does anyone remember the justification of not having unlifted or open kinds in the source language? -- Conal On Tue, Apr 15, 2014 at 5:09 PM, Richard Eisenberg e...@cis.upenn.edu wrote: What version of the GHC code are you looking at? The parser is currently stored in compiler/parser/Parser.y.pp (note the pp) and doesn’t have these lines. As far as I know, there is no way to refer to OpenKind from source. You’re absolutely right about the type of `undefined`. `undefined` (and `error`) have magical types. GHC knows that GHC.Err defines an `undefined` symbol and gives it its type by fiat. There is no way (I believe) to reproduce this behavior. If you have -fprint-explicit-foralls and
Re: Tightening up on inferred type signatures
] GHC generally obeys this rule ] ] · If GHC infers a type f::type, then it’s OK for you to add a type ] signature saying exactly that. That rule suggests that -XScopedTypeVariables should be on by default, and that you shouldn't need a forall to bring the type variables into scope. I imagine that would lead to harder-to-fix breakage than #8883, but on the other hand type signatures in let/where are pretty rare. Regards, Adam ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] [Haskell.org GSoC] Accepted Proposals
I'm pleased to announce the list of accepted student proposals for haskell.org for the Google Summer of Code 2014. Title Student Mentor Adding profiling support to GHCJS -- JavaScript backend for GHC Ömer Sinan Aǧacan Luite Stegeman Concurrent Lock-Free Hash Map for Haskell Mathias Bartl Ryan Newton Darcs: Hashed Files and Cache Marcio Díaz Eric Kow HDBC Improvements Edisach Nicolas Wu Darcs: History reordering: performance and features Ale Gadea Guillaume Hoffmann Implement Constraint-Based Layout in Diagrams Allan Gardner Daniel Bergey Lensify Diagrams Niklas Haas Brent Yorgey An Efficient Computational Algebra and Symbolic Linear Algebra Library in Haskell Hiromi ISHII Edward Kmett Complete plugins-ng low-level, filewatch, and cabal packages Kẏra Greg Weber Build Interactive Websites with GHCJS and Sodium Kyle Raftogianis Luite Stegeman Pandoc improvements: Embedded base64 images and EPUB 3.0 reader Matthew Pickering John MacFarlane Agda-like Interaction Mode for Emacs Alejandro Serrano David Raymond Christiansen Debugging tool for GHCJS Nathan van Doorn Luite Stegeman Flesh out features of Hackage 2 Chris Wong Duncan Coutts You can explore the abstracts of the accepted proposals at http://www.google-melange.com/gsoc/org2/google/gsoc2014/haskell I would like to take a moment to offer congratulations to all of the students we were able to accept into the program this year. That said, I would also like to offer my condolences to those students whom we were not able to bring into the program. We received 14 slots in total this year - more than we ever received in past years - yet still not nearly enough to accept all of the excellent proposals we received this time around. Please consider applying again next year. I am looking forward to working with you on another Summer of Code, and I hope we can all make an effort as a community to be welcoming and to help you in your projects. If you have any questions or concerns about the process, please feel free to email me or chase me down on #haskell-gsoc on irc.freenode.net. -Edward Kmett ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] [Haskell.org GSoC] Accepted Proposals
Hi, are there long descriptions somewhere? the trac page linked from melange seems to have not been updated since 2012: https://ghc.haskell.org/trac/summer-of-code/report/1 I'd be interested to see the milestones and expected outcomes for some of the projects :) Conrad. On 22 April 2014 06:56, Edward Kmett ekm...@gmail.com wrote: I'm pleased to announce the list of accepted student proposals for haskell.org for the Google Summer of Code 2014. Title Student Mentor Adding profiling support to GHCJS -- JavaScript backend for GHC Ömer Sinan Aǧacan Luite Stegeman Concurrent Lock-Free Hash Map for Haskell Mathias Bartl Ryan Newton Darcs: Hashed Files and Cache Marcio Díaz Eric Kow HDBC Improvements Edisach Nicolas Wu Darcs: History reordering: performance and features Ale Gadea Guillaume Hoffmann Implement Constraint-Based Layout in Diagrams Allan Gardner Daniel Bergey Lensify Diagrams Niklas Haas Brent Yorgey An Efficient Computational Algebra and Symbolic Linear Algebra Library in Haskell Hiromi ISHII Edward Kmett Complete plugins-ng low-level, filewatch, and cabal packages Kẏra Greg Weber Build Interactive Websites with GHCJS and Sodium Kyle Raftogianis Luite Stegeman Pandoc improvements: Embedded base64 images and EPUB 3.0 reader Matthew Pickering John MacFarlane Agda-like Interaction Mode for Emacs Alejandro Serrano David Raymond Christiansen Debugging tool for GHCJS Nathan van Doorn Luite Stegeman Flesh out features of Hackage 2 Chris Wong Duncan Coutts You can explore the abstracts of the accepted proposals at http://www.google-melange.com/gsoc/org2/google/gsoc2014/haskell I would like to take a moment to offer congratulations to all of the students we were able to accept into the program this year. That said, I would also like to offer my condolences to those students whom we were not able to bring into the program. We received 14 slots in total this year - more than we ever received in past years - yet still not nearly enough to accept all of the excellent proposals we received this time around. Please consider applying again next year. I am looking forward to working with you on another Summer of Code, and I hope we can all make an effort as a community to be welcoming and to help you in your projects. If you have any questions or concerns about the process, please feel free to email me or chase me down on #haskell-gsoc on irc.freenode.net. -Edward Kmett ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] [Haskell.org GSoC] Accepted Proposals
The abstracts get published publicly. The details of the proposal milestones are only displayed to the pool of mentors though. This is what Melange does by default. However, I'm not sure what Google's official policy is on revealing more information. Often by the end of the proposal process the project the student has ultimately agreed to bears little resemblance to their original proposal, so I'm not sure it'd be a good idea to show the original submissions in their full glory, even if we had the option. -Edward On Mon, Apr 21, 2014 at 9:56 PM, Conrad Parker con...@metadecks.org wrote: Hi, are there long descriptions somewhere? the trac page linked from melange seems to have not been updated since 2012: https://ghc.haskell.org/trac/summer-of-code/report/1 I'd be interested to see the milestones and expected outcomes for some of the projects :) Conrad. On 22 April 2014 06:56, Edward Kmett ekm...@gmail.com wrote: I'm pleased to announce the list of accepted student proposals for haskell.org for the Google Summer of Code 2014. Title Student Mentor Adding profiling support to GHCJS -- JavaScript backend for GHC Ömer Sinan Aǧacan Luite Stegeman Concurrent Lock-Free Hash Map for Haskell Mathias Bartl Ryan Newton Darcs: Hashed Files and Cache Marcio Díaz Eric Kow HDBC Improvements Edisach Nicolas Wu Darcs: History reordering: performance and features Ale Gadea Guillaume Hoffmann Implement Constraint-Based Layout in Diagrams Allan Gardner Daniel Bergey Lensify Diagrams Niklas Haas Brent Yorgey An Efficient Computational Algebra and Symbolic Linear Algebra Library in Haskell Hiromi ISHII Edward Kmett Complete plugins-ng low-level, filewatch, and cabal packages Kẏra Greg Weber Build Interactive Websites with GHCJS and Sodium Kyle Raftogianis Luite Stegeman Pandoc improvements: Embedded base64 images and EPUB 3.0 reader Matthew Pickering John MacFarlane Agda-like Interaction Mode for Emacs Alejandro Serrano David Raymond Christiansen Debugging tool for GHCJS Nathan van Doorn Luite Stegeman Flesh out features of Hackage 2 Chris Wong Duncan Coutts You can explore the abstracts of the accepted proposals at http://www.google-melange.com/gsoc/org2/google/gsoc2014/haskell I would like to take a moment to offer congratulations to all of the students we were able to accept into the program this year. That said, I would also like to offer my condolences to those students whom we were not able to bring into the program. We received 14 slots in total this year - more than we ever received in past years - yet still not nearly enough to accept all of the excellent proposals we received this time around. Please consider applying again next year. I am looking forward to working with you on another Summer of Code, and I hope we can all make an effort as a community to be welcoming and to help you in your projects. If you have any questions or concerns about the process, please feel free to email me or chase me down on #haskell-gsoc on irc.freenode.net. -Edward Kmett ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [arch-haskell] Yesod Persistent packages
Magnus Therning wrote: They were dropped from the testing branch due to not being buildable with ghc 7.8 at the time.[^1] I'll make an attempt to re-add them. Earlier we had the following three packages, would they be both sufficient and necessary? persistent persistent-sqlite persistent-template /M Yes, those are the only 3 Persistent packages that I had installed. I am only using them as glue for a simple SQLite database in one of my projects. Thanks again for your continued efforts. They are truly appreciated. Best regards, Xyne ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] Yesod Persistent packages
On Mon, Apr 21, 2014 at 02:20:00PM +, Xyne wrote: Magnus Therning wrote: They were dropped from the testing branch due to not being buildable with ghc 7.8 at the time.[^1] I'll make an attempt to re-add them. Earlier we had the following three packages, would they be both sufficient and necessary? persistent persistent-sqlite persistent-template /M Yes, those are the only 3 Persistent packages that I had installed. I am only using them as glue for a simple SQLite database in one of my projects. Thanks again for your continued efforts. They are truly appreciated. They have been added. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay pgpVUmqjpUFTs.pgp Description: PGP signature ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
