Re: Unlifted data types

2015-09-10 Thread Carter Schonwald
Would this allow having a strict monoid instance for maybe, given the right hinting at the use site? On Wednesday, September 9, 2015, Edward Kmett wrote: > I think ultimately the two views of levity that we've been talking diverge > along the same lines as the pi vs forall discussion from your L

Re: Unlifted data types

2015-09-10 Thread Simon Marlow
On 10/09/2015 10:41, Simon Peyton Jones wrote: | > The awkward spot is the runtime system. Currently it goes to some | > lengths to ensure that it never introduces an indirection for a | > boxed-but-unlifted type. Simon Marlow would know exactly where. So | | I *think* we're ok here. The

Re: Shared data type for extension flags

2015-09-10 Thread Adam Sandberg Eriksson
How about ghc-datatypes? ghc-core-data seems like it would have something to do with the Core language and ghc-integration sounds like it is a layer on top of ghc. Using the -types suffix has quite som precedence [1] for packages defining shared datatypes (as does the -core suffix), but given Mal

Re: Shared data type for extension flags

2015-09-10 Thread Brandon Allbery
On Thu, Sep 10, 2015 at 4:28 AM, malcolm.wallace wrote: > "ghc-types" sounds like a package for fancy type hackery. I would never > think to find language extension flags in such a place. How about > "ghc-package-db", or "ghc-language-extensions"? > ghc-integration ghc-core-data -- brandon s

Re: Converting unboxed sum types in StgCmm

2015-09-10 Thread Johan Tibell
I'll give that a try. The main use of the stg types in the stg-to-cmm pass is to call idPrimRep (which call typePrimRep) to figure out which register type we need to use. I guess as long as I rewrite the stg types so they give me the typePrimRep I want in the end I should be fine. On Thu, Sep 10,

Re: more releases

2015-09-10 Thread Eric Crockett
Some people had asked what the users want and about typical usage, so I'll give the my perspective. I consider myself a pretty typical user of Haskell: PhD student (in theory, not languages), but still pushing the boundaries of the compiler. I've filed quite a few bugs, so I have experience with ha

Re: Unlifted data types

2015-09-10 Thread Richard Eisenberg
These observations from Ed and Dan are quite helpful. Could one of you put them on the wiki page? I hadn't considered the possibility of truly parametric levity polymorphism. Thanks! Richard On Sep 9, 2015, at 3:30 PM, Edward Kmett wrote: > I think ultimately the two views of levity that we'v

RE: Unlifted data types

2015-09-10 Thread Simon Peyton Jones
| > The awkward spot is the runtime system. Currently it goes to some | > lengths to ensure that it never introduces an indirection for a | > boxed-but-unlifted type. Simon Marlow would know exactly where. So | | I *think* we're ok here. The RTS doesn't have any special machinery | to av

RE: Converting unboxed sum types in StgCmm

2015-09-10 Thread Simon Peyton Jones
The problem is that stg is too strongly typed It’s not really typed, or at least only in a very half-hearted way. To be concrete I think you can just use Any for any Pointer arg. All STG needs to know, really, is which things are pointers. Detailed type info like “are you a Char or a Bool”

Re: Shared data type for extension flags

2015-09-10 Thread malcolm.wallace
"ghc-types" sounds like a package for fancy type hackery.  I would never think to find language extension flags in such a place.  How about "ghc-package-db", or "ghc-language-extensions"? Regards, Malcolm On 10 Sep, 2015,at 03:30 AM, "Edward Z. Yang" wrote: I don't think it makes very much