Re: HEADS UP: Need 7.10.3?

[Luke Iannini]

Oh, and I guess it was implied, but I'm hugely in favor of a release : )

#10568 breaks linking with GLFW on Mac, and #10672 breaks linking with C++
libraries on Windows (Bullet Physics, in this case).

We're working on and evangelizing Haskell for game and VR dev heavily right
now and those are both directly in the critical path.

Cheers
Luke

On Mon, Sep 14, 2015 at 3:21 PM, Luke Iannini  wrote:

> My two showstoppers are https://ghc.haskell.org/trac/ghc/ticket/10568 and
> https://ghc.haskell.org/trac/ghc/ticket/10672, both of which seem to be
> already on track for 7.10.3, great!
>
> On Mon, Sep 14, 2015 at 7:15 AM, Tuncer Ayaz 
> wrote:
>
>> On Mon, Sep 14, 2015 at 3:53 PM, Austin Seipp wrote:
>> > Hi *,
>> >
>> > (This is an email primarily aimed at users reading this list and
>> > developers who have any interest).
>> >
>> > As some of you may know, there's currently a 7.10.3 milestone and
>> > status page on our wiki:
>> >
>> > https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.3
>> >
>> > The basic summary is best captured on the above page:
>> >
>> > "We have not yet decided when, or even whether, to release GHC
>> > 7.10.3. We will do so if (but only if!) we have documented cases of
>> > "show-stoppers" in 7.10.2. Namely, cases from users where
>> >
>> >   - You are unable to use 7.10.2 because of some bug
>> >   - There is no reasonable workaround, so you are truly stuck
>> >   - We know how to fix it
>> >   - The fix is not too disruptive; i.e. does not risk introducing a
>> > raft of new bugs"
>> >
>> > That is, we're currently not fully sold on the need for a release.
>> > However, the milestone and issue page serve as a useful guide, and
>> > also make it easier to keep track of smaller, point-release worthy
>> > issues.
>> >
>> > So in the wake of the 8.0 roadmap I just sent: If you *need* 7.10.3
>> > because the 7.10.x series has a major regression or problem you
>> > can't work around, let us know!
>> >
>> >   - Find or file a bug in Trac
>> >   - Make sure it's highest priority
>> >   - Assign it to the 7.10.3 milestone
>> >   - Follow up on this email if possible, or edit it on the status page
>> > text above - it would be nice to get some public feedback in one place
>> > about what everyone needs.
>> >
>> > Currently we have two bugs on the listed page in the 'show stopper
>> > category', possibly the same bug, which is a deal-breaker for HERMIT
>> > I believe. Knowing of anything else would be very useful.
>>
>> Would tracking down and fixing some of the reported time and space
>> regressions qualify as 7.10.3 material?
>> ___
>> 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: HEADS UP: Need 7.10.3?

[Luke Iannini]

My two showstoppers are https://ghc.haskell.org/trac/ghc/ticket/10568 and
https://ghc.haskell.org/trac/ghc/ticket/10672, both of which seem to be
already on track for 7.10.3, great!

On Mon, Sep 14, 2015 at 7:15 AM, Tuncer Ayaz  wrote:

> On Mon, Sep 14, 2015 at 3:53 PM, Austin Seipp wrote:
> > Hi *,
> >
> > (This is an email primarily aimed at users reading this list and
> > developers who have any interest).
> >
> > As some of you may know, there's currently a 7.10.3 milestone and
> > status page on our wiki:
> >
> > https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.3
> >
> > The basic summary is best captured on the above page:
> >
> > "We have not yet decided when, or even whether, to release GHC
> > 7.10.3. We will do so if (but only if!) we have documented cases of
> > "show-stoppers" in 7.10.2. Namely, cases from users where
> >
> >   - You are unable to use 7.10.2 because of some bug
> >   - There is no reasonable workaround, so you are truly stuck
> >   - We know how to fix it
> >   - The fix is not too disruptive; i.e. does not risk introducing a
> > raft of new bugs"
> >
> > That is, we're currently not fully sold on the need for a release.
> > However, the milestone and issue page serve as a useful guide, and
> > also make it easier to keep track of smaller, point-release worthy
> > issues.
> >
> > So in the wake of the 8.0 roadmap I just sent: If you *need* 7.10.3
> > because the 7.10.x series has a major regression or problem you
> > can't work around, let us know!
> >
> >   - Find or file a bug in Trac
> >   - Make sure it's highest priority
> >   - Assign it to the 7.10.3 milestone
> >   - Follow up on this email if possible, or edit it on the status page
> > text above - it would be nice to get some public feedback in one place
> > about what everyone needs.
> >
> > Currently we have two bugs on the listed page in the 'show stopper
> > category', possibly the same bug, which is a deal-breaker for HERMIT
> > I believe. Knowing of anything else would be very useful.
>
> Would tracking down and fixing some of the reported time and space
> regressions qualify as 7.10.3 material?
> ___
> 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: Using GHC API to compile Haskell file

[Neil Mitchell]

>> 1) Is there any way to do the two compilations sharing some cached
>> state, e.g. loaded packages/.hi files, so each compilation goes
>> faster.
>
> You can, using withTempSession in the GhcMonad.  The external package
> state will be preserved across calls here, but things put in the HPT
> will get thrown out.

So as far as I can tell, you are suggesting I basically do getSession
in one session, grab the cache bits of the HscEnv, and inject them
into the start of the next session with setSession? (withTempSession
and all the other session functions just seem to be some variation on
that pattern). I tried that, but even storing just hsc_EPS between
sessions (which seemed like it should both be something that never
changes), causes weird compile failures. Is moving things like hsc_EPS
between sessions supported? Or were you suggesting I do something
else?

>> 2) Is there any way to do the link alone through the GHC API.
>
> I am confused by your code. There are two ways you can do linking:
>
> 1. Explicitly specify all of the objects to link together.  This
> works even if the source files aren't available.
>
> 2. Run ghc --make.  This does dependency analysis to figure out what
> objects to link together, but since everything is already compiled,
> it just links.
>
> Your code seems to be trying to do (1) and (2) simultaneously (you set
> the mode to OneShot, but then you call load which calls into GhcMake).
>
> If you want to use (1), stop calling load and call 'oneShot' instead.
> If you want to use (2), just reuse your working --make code.
>
> (BTW, how did I figure this all out? By looking at ghc/Main.hs).

Thanks. I have now started down that rabbit hole, and am currently
peering around. I haven't yet succeeded, but given what I can see, it
just seems like a matter of time.

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

Re: Cannot have GHC in ARMv6 architecture

[João Miguel]

Hello again,

I still can't get the stage 2 binary, as previous messages show. Should
I manually use the stage 1 compiler to do it, along with GCC
cross-compiler, etc.? Because the page
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/RaspberryPi
says that «The build should go successfully all the way to stage 2». Why
isn't it?

Hoping you can continue to help me. All the best,
João Miguel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: download all of Hackage?

[Alan & Kim Zimmerman]

You will probably not be able to compile everything. If you want a
compilable subset, you should probably look at stackage

Alan

On Mon, Sep 14, 2015 at 9:57 PM, Mike Izbicki  wrote:

> Does anyone know approximately how much disk space all of hackage
> takes up when compiled?  And about how long it takes to compile
> everything?
>
> On Mon, Sep 14, 2015 at 11:37 AM, John Wiegley 
> wrote:
> >> Brandon Allbery  writes:
> >
> >> There's hackage-mirror, but I note it says it mirrors to S3.
> >
> > It mirrors into a directory as well:
> >
> > hackage-mirror --from="http://hackage.haskell.org"; --to="/some/dir"
> >
> > Further, it can incrementally update very quickly.
> >
> > John
> > ___
> > 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
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: download all of Hackage?

[Mike Izbicki]

Does anyone know approximately how much disk space all of hackage
takes up when compiled?  And about how long it takes to compile
everything?

On Mon, Sep 14, 2015 at 11:37 AM, John Wiegley  wrote:
>> Brandon Allbery  writes:
>
>> There's hackage-mirror, but I note it says it mirrors to S3.
>
> It mirrors into a directory as well:
>
> hackage-mirror --from="http://hackage.haskell.org"; --to="/some/dir"
>
> Further, it can incrementally update very quickly.
>
> John
> ___
> 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: download all of Hackage?

[John Wiegley]

> Brandon Allbery  writes:

> There's hackage-mirror, but I note it says it mirrors to S3.

It mirrors into a directory as well:

hackage-mirror --from="http://hackage.haskell.org"; --to="/some/dir"

Further, it can incrementally update very quickly.

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

Re: Converting unboxed sum types in StgCmm

[Ryan Newton]

>
> It seems to me that we just want to rewrite the case altogether into
> something that looks at the tag field of the data constructor. Also, in stg
> we use the same DataCon as in core, but after stg the unboxed sum case
> really only has one constructor (one with the union of all the fields),
> which makes it awkward to reuse the original DataCon.
>

Is there a problem with introducing a totally new datatype at this point in
the compile to represent the product (tag, wordish1, ..., wordishN, ptr1
... ptrM)?  Or, if it is an anonymous product, why can't it use existing
unboxed sum machinery?

Also, as an architecture thing, is there a reason this shouldn't be its own
stg->stg pass?

(P.S. "wordish" above has a weaselly suffix because as Dan pointed out,
some unboxed things are > 64 bits.)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Unlifted data types

[Edward Z. Yang]

I'm not so sure how useful an observation this is, but Dunfield
had a paper at this very ICFP "Elaborating Evaluation-Order
Polymorphism".  He argues that polymorphism over evaluation
order should be thought of as a form of intersection type.

Edward

Excerpts from Richard Eisenberg's message of 2015-09-14 08:59:36 -0700:
> 
> On Sep 11, 2015, at 4:28 AM, Roman Cheplyaka  wrote:
> 
> > On 11/09/15 06:22, Carter Schonwald wrote:
> >> Would this allow having a strict monoid instance for maybe, given the
> >> right hinting at the use site?
> > 
> > That's a fantastic idea, especially if it could be generalized to
> > Applicative functors, where the problem of "inner laziness" is pervasive.
> > 
> > But that'd be tricky, because functions have the Lifted kind, and so
> > <*> would have to be crazily levity-polymorphic. (Or is this not crazy?)
> 
> No more crazy than other things. Right now, we have
> 
> (<*>) :: forall (a :: *) (b :: *) (f :: * -> *). Applicative f => f (a -> b) 
> -> f a -> f b
> 
> Under this proposal, we would have (ignore the Boxity stuff)
> 
> (<*>) :: forall (v1 :: Levity) (v2 :: Levity) (v3 :: Levity)
> (a :: TYPE v1) (b :: TYPE v2) (f :: forall (v4 :: Levity). 
> TYPE v4 -> TYPE v3).
>  Applicative f
>   => f @'Lifted (a -> b) -> f @v1 a -> f @v2 b
> 
> The higher-rank levity-polymorphism is necessary in case `a` and `b` have 
> different levities. This may be getting wildly out-of-hand, but I don't think 
> it's actually breaking.
> 
> I would like to point out that using forall here is really quite wrong. As 
> others have pointed out, levity polymorphism is ad-hoc polymorphism, not 
> parametric. Using 'pi' would be much closer to it, but it implies the 
> existence of more dependent types than we really need for this.
> 
> Richard
> 
> > 
> > Roman
> > 
> > ___
> > 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

Making compilation results deterministic (#4012)

[Bartosz Nitka]

Hello,

For the past couple of weeks I've been working on making compilation
results deterministic.
What I'm focusing on right now is the interface file determinism, I don't
care about binaries being deterministic.

I'd like to give a status update and ask for some advice, since I'm running
into issues that I don't have a good way of solving.

The first question anyone might ask is how did nondeterminism creep into
the compiler. If we're compiling with a single thread there's no reason for
the computation to proceed in non deterministic way. I'm fairly certain
that the issue originates from lazy loading of interface files. Relevant
function:
https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/typecheck/TcRnMonad.hs;12098c2e70b2a432f4ed675ed72b53a396cb2842$1414-1421.
What happens is that if you already have an interface file for a target
you're trying to build the computation will proceed differently.

Why does lazy loading matter? As you load the interface file it needs to
get type-checked and that means it needs to pull some Uniques from a global
UniqSupply. It does that in different order resulting in different Unique
assignment. As far as I can tell, lazy loading is required for performance,
so I abandoned the idea of fixing it. I haven't looked at parallel
compilation yet, but I'd expect it to result in different Unique assignment
as well.

I believe up to this point we're ok. Uniques are non-deterministic, but it
shouldn't be a big deal. Uniques should be opaque enough to not affect the
order of computation, for example the order of binds considered. But they
aren't.

Uniques are used in different ways throughout the compiler and they end up
reordering things:

1) They have an `Ord` instance:
https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/basicTypes/Unique.hs;12098c2e70b2a432f4ed675ed72b53a396cb2842$190-195
.

So far the places it impacts the most are places that use
`stronglyConnCompFromEdgedVertices`, because Unique is used as a Node key
and the result depends on the order of Nodes being considered. Some
examples:
https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/simplCore/OccurAnal.hs;12b0bb6f15caa5b4b01d0330a7a8d23e3c10842c$183,646,681,846
https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/rename/RnSource.hs;12b0bb6f15caa5b4b01d0330a7a8d23e3c10842c$1365
(because Ord for Name uses Unique
https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/basicTypes/Name.hs;12b0bb6f15caa5b4b01d0330a7a8d23e3c10842c$410-411
)

I've tried to see what removing it would entail and the changes would be
far reaching: https://phabricator.haskell.org/P62.

2) VarEnv, NameEnv are implemented in terms of UniqFM, which is just
Data.IntMap with keys being the Unique integer values.

The way this bites us is that when UniqFM's get converted to a list they
end up being sorted on Unique value. This problem is more widespread than
the `stronglyConnCompFromEdgedVertices` issue, there's even a place where
it's implicitly depended on:
https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/nativeGen/RegAlloc/Liveness.hs;12b0bb6f15caa5b4b01d0330a7a8d23e3c10842c$837-842
.

I've tried to fix it by making `toList` return the elements in the order of
insertion (https://phabricator.haskell.org/P63), but that turned out to
have significant cost. My unscientific benchmark on aeson and text showed
10% compilation time increase. It's possible it can be done in less
expensive way, I've tried a couple of approaches, but all of them resulted
in 10% time increase. I've also considered to split UniqFM to two different
types, one that keeps the ordering, and one that can't `toList`, but I
suspect that the cut will not be clean, so I haven't tried that.

In some cases we got away with ordering things by OccName where needed: (
https://phabricator.haskell.org/D1073, https://phabricator.haskell.org/D1192),
but OccName's don't have to be unique in every case and if we try to make
them unique that would make them longer and probably result in even greater
slowdown.

The instance I've recently looked at doesn't look like it can be solved by
sorting by OccName.
The code that triggers the problem (simplified from haskell-src-exts):

  data Decl l = Boring l
deriving (Eq)

  data Binds l
= BDecls  l [Decl l] -- ^ An ordinary binding group
| IPBinds l [IPBind l]   -- ^ A binding group for implicit parameters
  deriving (Eq)

  data IPBind l = Boring2 l
  deriving (Eq)

The end result is:

4449fe3f8368a2c47b2499a1fb033b6a
  $fEqBinds_$c==$Binds :: Eq l => Binds l -> Binds l -> Bool
  {- Arity: 1, HasNoCafRefs, Strictness: ,
 Unfolding: (\ @ l $dEq :: Eq l ->
 let {
   $dEq1 :: Eq (Decl l) = $fEqDecl @ l $dEq
 } in
 let {
   $dEq2 :: Eq (IPBind l) = $fEqIPBind @ l $dEq
 } in
 \ ds :: Binds l ds1 :: Binds l ->
 ca

Re: Converting unboxed sum types in StgCmm

[Johan Tibell]

I've given this a yet some more thought. Given this simple core program:

f [InlPrag=NOINLINE] :: (#|#) Int Char -> Int
[GblId, Arity=1, Str=DmdType]
f =
  \ (ds_dmE :: (#|#) Int Char) ->
case ds_dmE of _ [Occ=Dead] {
  (#_|#) x_amy -> x_amy;
  (#|_#) ipv_smK -> patError @ Int "UnboxedSum.hs:5:1-15|function f"#
}

We will get this stg pre-unarise:

unarise
  [f [InlPrag=NOINLINE] :: (#|#) Int Char -> Int
   [GblId, Arity=1, Str=DmdType, Unf=OtherCon []] =
   \r srt:SRT:[0e :-> patError] [ds_svm]
   case ds_svm of _ [Occ=Dead] {
 (#_|#) x_svo [Occ=Once] -> x_svo;
 (#|_#) _ [Occ=Dead] -> patError "UnboxedSum.hs:5:1-15|function
f"#;
   };]

What do we want it to look like afterwards? I currently, have this, modeled
after unboxed tuples:

post-unarise:
  [f [InlPrag=NOINLINE] :: (#|#) Int Char -> Int
   [GblId, Arity=1, Str=DmdType, Unf=OtherCon []] =
   \r srt:SRT:[0e :-> patError] [ds_gvu ds_gvv]
   case (#_|#) [ds_gvu ds_gvv] of _ [Occ=Dead] {  -- <-- WHAT
SHOULD GO HERE?
 (#_|#) x_svo [Occ=Once] -> x_svo;
 (#|_#) _ [Occ=Dead] -> patError "UnboxedSum.hs:5:1-15|function
f"#;
   };]

Here I have performed the same rewriting of the scrutinee in the case
statement as for unboxed tuples, but note that this doesn't quite work, as
we don't know which data constructor to apply in "..." in case ... of. In
the case of tuples it's easy; there is only one.

It seems to me that we just want to rewrite the case altogether into
something that looks at the tag field of the data constructor. Also, in stg
we use the same DataCon as in core, but after stg the unboxed sum case
really only has one constructor (one with the union of all the fields),
which makes it awkward to reuse the original DataCon.



On Mon, Sep 14, 2015 at 7:27 AM, Ryan Newton  wrote:

>
>>-
>>data RepType = UbxTupleRep [UnaryType]
>>| UbxSumRep [UnaryType]
>>| UnaryRep UnaryType
>>
>> Not, fully following, but ... this reptype business is orthogonal to
> whether you add a normal type to the STG level that models anonymous,
> untagged unions, right?
>
> That is, when using Any for pointer types, they could use indicative
> phantom types, like "Any (Union Bool Char)", even if there's not full
> support for doing anything useful with (Union Bool Char) by itself.  Maybe
> the casting machinery could greenlight a cast from Any (Union Bool Char) to
> Bool at least?
>
> There's already the unboxed union itself, (|# #|) , but that's different
> than a pointer to a union of types...
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Unlifted data types

[Richard Eisenberg]

On Sep 11, 2015, at 4:28 AM, Roman Cheplyaka  wrote:

> On 11/09/15 06:22, Carter Schonwald wrote:
>> Would this allow having a strict monoid instance for maybe, given the
>> right hinting at the use site?
> 
> That's a fantastic idea, especially if it could be generalized to
> Applicative functors, where the problem of "inner laziness" is pervasive.
> 
> But that'd be tricky, because functions have the Lifted kind, and so
> <*> would have to be crazily levity-polymorphic. (Or is this not crazy?)

No more crazy than other things. Right now, we have

(<*>) :: forall (a :: *) (b :: *) (f :: * -> *). Applicative f => f (a -> b) -> 
f a -> f b

Under this proposal, we would have (ignore the Boxity stuff)

(<*>) :: forall (v1 :: Levity) (v2 :: Levity) (v3 :: Levity)
(a :: TYPE v1) (b :: TYPE v2) (f :: forall (v4 :: Levity). TYPE 
v4 -> TYPE v3).
 Applicative f
  => f @'Lifted (a -> b) -> f @v1 a -> f @v2 b

The higher-rank levity-polymorphism is necessary in case `a` and `b` have 
different levities. This may be getting wildly out-of-hand, but I don't think 
it's actually breaking.

I would like to point out that using forall here is really quite wrong. As 
others have pointed out, levity polymorphism is ad-hoc polymorphism, not 
parametric. Using 'pi' would be much closer to it, but it implies the existence 
of more dependent types than we really need for this.

Richard

> 
> Roman
> 
> ___
> 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: download all of Hackage?

[Richard Eisenberg]

That's perfect -- thanks! It's already humming away.

On Sep 14, 2015, at 11:17 AM, Herbert Valerio Riedel  wrote:

> for PKG in $(cabal list --simple | awk '{ print $1 }' | uniq); do cabal get 
> $PKG;done

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

Re: download all of Hackage?

[Christopher Allen]

It's a little out of date, but I've been using that repo I made to do
surveys of Haskell code and figure out how frequently things are used.

I could really do with a Haskell-source-code-aware grep though. Being able
to specify type, data, etc. would be really nice!

On Mon, Sep 14, 2015 at 10:19 AM, Alan & Kim Zimmerman 
wrote:

> You could clone https://github.com/bitemyapp/hackage-packages
>
> Alan
>
> On Mon, Sep 14, 2015 at 5:17 PM, Herbert Valerio Riedel <
> hvrie...@gmail.com> wrote:
>
>> On 2015-09-14 at 16:43:44 +0200, Richard Eisenberg wrote:
>> > Is there an easy way to download (but not compile) all of Hackage? I
>> > know of the hackager package, but that's about compiling. I just want
>> > a whole big load of Haskell code to play with. I thought I could find
>> > a link on Hackage to do this, but failed.
>>
>> It's quite easy, you can iterate through the list of package names and
>> call 'cabal get' like e.g. (untested, but I've done this already -- you
>> may need to protect against execution errors)
>>
>>   for PKG in $(cabal list --simple | awk '{ print $1 }' | uniq); do cabal
>> get $PKG;done
>>
>> another variant is to construct the URLs based on the output;
>>
>> you can also get a list of packages in JSON format via
>>
>>  http://hackage.haskell.org/packages/.json
>>
>> there's many ways to accomplish what you want...
>>
>> ___
>> 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
>
>


-- 
Chris Allen
Currently working on http://haskellbook.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: download all of Hackage?

[Alan & Kim Zimmerman]

You could clone https://github.com/bitemyapp/hackage-packages

Alan

On Mon, Sep 14, 2015 at 5:17 PM, Herbert Valerio Riedel 
wrote:

> On 2015-09-14 at 16:43:44 +0200, Richard Eisenberg wrote:
> > Is there an easy way to download (but not compile) all of Hackage? I
> > know of the hackager package, but that's about compiling. I just want
> > a whole big load of Haskell code to play with. I thought I could find
> > a link on Hackage to do this, but failed.
>
> It's quite easy, you can iterate through the list of package names and
> call 'cabal get' like e.g. (untested, but I've done this already -- you
> may need to protect against execution errors)
>
>   for PKG in $(cabal list --simple | awk '{ print $1 }' | uniq); do cabal
> get $PKG;done
>
> another variant is to construct the URLs based on the output;
>
> you can also get a list of packages in JSON format via
>
>  http://hackage.haskell.org/packages/.json
>
> there's many ways to accomplish what you want...
>
> ___
> 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: download all of Hackage?

[Herbert Valerio Riedel]

On 2015-09-14 at 16:43:44 +0200, Richard Eisenberg wrote:
> Is there an easy way to download (but not compile) all of Hackage? I
> know of the hackager package, but that's about compiling. I just want
> a whole big load of Haskell code to play with. I thought I could find
> a link on Hackage to do this, but failed.

It's quite easy, you can iterate through the list of package names and
call 'cabal get' like e.g. (untested, but I've done this already -- you
may need to protect against execution errors)

  for PKG in $(cabal list --simple | awk '{ print $1 }' | uniq); do cabal get 
$PKG;done

another variant is to construct the URLs based on the output;

you can also get a list of packages in JSON format via

 http://hackage.haskell.org/packages/.json

there's many ways to accomplish what you want...

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

Re: download all of Hackage?

[Brandon Allbery]

On Mon, Sep 14, 2015 at 10:43 AM, Richard Eisenberg 
wrote:

> Is there an easy way to download (but not compile) all of Hackage? I know
> of the hackager package, but that's about compiling. I just want a whole
> big load of Haskell code to play with. I thought I could find a link on
> Hackage to do this, but failed.
>

There's hackage-mirror, but I note it says it mirrors to S3.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

download all of Hackage?

[Richard Eisenberg]

Hi devs,

Is there an easy way to download (but not compile) all of Hackage? I know of 
the hackager package, but that's about compiling. I just want a whole big load 
of Haskell code to play with. I thought I could find a link on Hackage to do 
this, but failed.

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

Re: Converting unboxed sum types in StgCmm

[Ryan Newton]

>
>
>-
>data RepType = UbxTupleRep [UnaryType]
>| UbxSumRep [UnaryType]
>| UnaryRep UnaryType
>
> Not, fully following, but ... this reptype business is orthogonal to
whether you add a normal type to the STG level that models anonymous,
untagged unions, right?

That is, when using Any for pointer types, they could use indicative
phantom types, like "Any (Union Bool Char)", even if there's not full
support for doing anything useful with (Union Bool Char) by itself.  Maybe
the casting machinery could greenlight a cast from Any (Union Bool Char) to
Bool at least?

There's already the unboxed union itself, (|# #|) , but that's different
than a pointer to a union of types...
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: HEADS UP: Need 7.10.3?

[Tuncer Ayaz]

On Mon, Sep 14, 2015 at 3:53 PM, Austin Seipp wrote:
> Hi *,
>
> (This is an email primarily aimed at users reading this list and
> developers who have any interest).
>
> As some of you may know, there's currently a 7.10.3 milestone and
> status page on our wiki:
>
> https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.3
>
> The basic summary is best captured on the above page:
>
> "We have not yet decided when, or even whether, to release GHC
> 7.10.3. We will do so if (but only if!) we have documented cases of
> "show-stoppers" in 7.10.2. Namely, cases from users where
>
>   - You are unable to use 7.10.2 because of some bug
>   - There is no reasonable workaround, so you are truly stuck
>   - We know how to fix it
>   - The fix is not too disruptive; i.e. does not risk introducing a
> raft of new bugs"
>
> That is, we're currently not fully sold on the need for a release.
> However, the milestone and issue page serve as a useful guide, and
> also make it easier to keep track of smaller, point-release worthy
> issues.
>
> So in the wake of the 8.0 roadmap I just sent: If you *need* 7.10.3
> because the 7.10.x series has a major regression or problem you
> can't work around, let us know!
>
>   - Find or file a bug in Trac
>   - Make sure it's highest priority
>   - Assign it to the 7.10.3 milestone
>   - Follow up on this email if possible, or edit it on the status page
> text above - it would be nice to get some public feedback in one place
> about what everyone needs.
>
> Currently we have two bugs on the listed page in the 'show stopper
> category', possibly the same bug, which is a deal-breaker for HERMIT
> I believe. Knowing of anything else would be very useful.

Would tracking down and fixing some of the reported time and space
regressions qualify as 7.10.3 material?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

HEADS UP: Need 7.10.3?

[Austin Seipp]

Hi *,

(This is an email primarily aimed at users reading this list and
developers who have any interest).

As some of you may know, there's currently a 7.10.3 milestone and
status page on our wiki:

https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.3

The basic summary is best captured on the above page:

"We have not yet decided when, or even whether, to release GHC 7.10.3.
We will do so if (but only if!) we have documented cases of
"show-stoppers" in 7.10.2. Namely, cases from users where

  - You are unable to use 7.10.2 because of some bug
  - There is no reasonable workaround, so you are truly stuck
  - We know how to fix it
  - The fix is not too disruptive; i.e. does not risk introducing a
raft of new bugs"

That is, we're currently not fully sold on the need for a release.
However, the milestone and issue page serve as a useful guide, and
also make it easier to keep track of smaller, point-release worthy
issues.

So in the wake of the 8.0 roadmap I just sent: If you *need* 7.10.3
because the 7.10.x series has a major regression or problem you can't
work around, let us know!

  - Find or file a bug in Trac
  - Make sure it's highest priority
  - Assign it to the 7.10.3 milestone
  - Follow up on this email if possible, or edit it on the status page
text above - it would be nice to get some public feedback in one place
about what everyone needs.

Currently we have two bugs on the listed page in the 'show stopper
category', possibly the same bug, which is a deal-breaker for HERMIT I
believe. Knowing of anything else would be very useful.

Thanks all!

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

HEADS UP (devs, users): 8.0.1 Roadmap

[Austin Seipp]

Hi *,

I've returned from vacation, and last week Simon, Simon and I met up
again after a long break, and talked a bit about the upcoming release.

The good news is that it is going to be an exciting one! The flip side
is, there's a lot of work to be done!

The current plan we'd roughly like to follow is...

  - November: Fork the new `ghc-8.0` STABLE branch
- At this point, `master` development will probably slow as we fix bugs.
- This gives us 2 months or so until branch, from Today.
- This is nice as the branch is close to the first RC.
  - December: First release candidate
  - Mid/late February: Final release.

Here's our current feature roadmap (in basically the same place as all
our previous pages):

https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1

As time goes on, this page will be updated to reflect Reality™ and
track it as closely as possible. So keep an eye on it! It's got the
roadmap (near top) and large bug list (bottom).

Now, there are some things we need, so depending on who you are, please...

  - *Users*: please look over the bug list! If there's a bug you need
fixed that isn't there, set it to the 8.0.1 milestone (updated in
Trac). If this bug is critical to you, please let us know! You can
bump the priority (if we disagree, or it's workaround-able, it might
get bumped down). We just need a way to see what you need, so please
let us know somehow!

As a reminder, our regular policy is this: if a bug is NOT marked
highest or high priority, it is essentially 100% the case we will not
look at it. So please make sure this is accurate. Or if you can, write
a patch yourself!

  - *Developers*: double check the roadmap list, _and if you're
responsible for something, make sure it is accurate!_

There are some great things planned to land in HEAD, but we'll have to
work for it. Onward!

  - A better LLVM backend for Tier-1 platforms
  - Types are kinds and kind equality
  - Overloaded record fields!
  - Enhancements to DWARF debugging
  - ApplicativeDo
  - ... and many more...

Thanks everyone!

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Converting unboxed sum types in StgCmm

[Johan Tibell]

Another question, in need to add something to AltType in StgSyn, would this
work

data AltType
  = PolyAlt -- Polymorphic (a type variable)
  | UbxTupAlt Int   -- Unboxed tuple of this arity
  | UbxSumAlt Int   -- Unboxed sum of this arity
  | AlgAltTyCon -- Algebraic data type; the AltCons will be DataAlts
  | PrimAlt   TyCon -- Primitive data type; the AltCons will be LitAlts

or do I also have to capture which alternative was used here? Why do we
capture the arity in *tuple* case here?

On Mon, Sep 14, 2015 at 6:21 AM, Johan Tibell 
wrote:

> I took a stab at this but ran into something I don't understand. For
> recence, the whole implementation of unboxed sums is at
> https://github.com/ghc/ghc/compare/master...tibbe:unboxed-sums and the
> implementation of unarisation is at
> https://github.com/ghc/ghc/compare/master...tibbe:unboxed-sums#diff-f5bc1f9e9c230db4cf882bf18368a818
> .
>
> Running the compiler on the following file:
>
> {-# LANGUAGE UnboxedSums #-}
> module Test where
>
> f :: (# Int | Char #) -> Int
> f (# x | #) = x
> {-# NOINLINE f #-}
>
> g = f (# 1 | #)
>
> Yields an error, like so:
>
> ghc-stage2: panic! (the 'impossible' happened)
>   (GHC version 7.11.20150912 for x86_64-apple-darwin):
> StgCmmEnv: variable not found
>   ds_svq
>   local binds for:
>   ds_gvz
>   ds_gvA
>
> I probably got something wrong in UnariseStg, but I can't see what. I
> printed this debug information to see the stg I'm rewriting:
>
> unarise
>   [f [InlPrag=NOINLINE] :: (#|#) Int Char -> Int
>[GblId, Arity=1, Str=DmdType, Unf=OtherCon []] =
>\r srt:SRT:[0e :-> patError] [ds_svq]
>case ds_svq of _ [Occ=Dead] {
>  (#_|#) x_svs [Occ=Once] -> x_svs;
>  (#|_#) _ [Occ=Dead] -> patError
> "UnboxedSum.hs:5:1-15|function f"#;
>};,
>g :: Int
>[GblId, Str=DmdType] =
>\u srt:SRT:[r1 :-> f] []
>let {
>  sat_svu [Occ=Once] :: Int
>  [LclId, Str=DmdType] =
>  NO_CCS I#! [1#];
>} in
>  case (#_|#) [sat_svu] of sat_svv { __DEFAULT -> f sat_svv; };]
> unariseAlts
>   [81 :-> [realWorld#], svq :-> [ds_gvz, ds_gvA]]
>   UbxTup 2
>   wild_svr
>   [((#_|#), [x_svs], [True], x_svs),
>((#|_#),
> [ipv_svt],
> [False],
> patError "UnboxedSum.hs:5:1-15|function f"#)]
>
> It's ds_svg that's being complained about above. I find that a bit
> confusing as that variable is never used on any RHS.
>
> Some questions that might help me get there:
>
>- I added a new RepType for unboxed sums, like so:
>
>data RepType = UbxTupleRep [UnaryType]
>| UbxSumRep [UnaryType]
>| UnaryRep UnaryType
>
>Does this constructor make sense? I store the already flattened
>representation of the sum in here, rather than having something like
>[[UnaryType]] and storing each alternative.
>- In unariseAlts there's a bndr argument. Is that the binder of the
>scrutinee as a whole (e.g. the 'x' in case e of x { ... -> ... })?
>
> Any other idea what I might have gotten wrong?
>
>
> On Mon, Sep 14, 2015 at 1:03 AM, Simon Marlow  wrote:
>
>> On 10/09/2015 10:37, Simon Peyton Jones wrote:
>>
>>> 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” is strictly jam; indeed never used I
>>> think.  (I could be wrong but I’m pretty sure I’m not wrong in a
>>> fundamental way.
>>>
>>
>> Yes, the only thing the code generator needs to do with types is convert
>> them to PrimReps (see idPrimRep), and all GC pointer types have the same
>> PrimRep (PtrRep).
>>
>> Cheers
>> Simon
>>
>>
>>
>>
>>> SImon
>>>
>>> *From:*Johan Tibell [mailto:johan.tib...@gmail.com]
>>> *Sent:* 09 September 2015 23:22
>>> *To:* Simon Peyton Jones; Simon Marlow; ghc-devs@haskell.org
>>> *Subject:* Converting unboxed sum types in StgCmm
>>>
>>> Hi!
>>>
>>> The original idea for implementing the backend part of the unboxed sums
>>> proposal was to convert from the core representation to the actual data
>>> representation (i.e. a tag followed by some pointer and non-pointer
>>> fields) in the unarise stg-to-stg
>>> <
>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fghc%2fghc%2fblob%2fmaster%2fcompiler%2fsimplStg%2fUnariseStg.hs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cca7beffb01494517d75108d2b9652973%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=U%2bFUNsL87iEemajTnAW9SxD9N5b4%2bG8QB1q19%2fX%2bBI4%3d
>>> >
>>> pass.
>>>
>>> I have now realized that this won't work. The problem is that stg is too
>>> strongly typed. When we "desugar" sum types we need to convert functions
>>> receiving a value e.g. from
>>>
>>>  f :: (# Bool | Char #) -> ...
>>>
>>> to
>>>
>>>  f :: 

Re: Converting unboxed sum types in StgCmm

[Johan Tibell]

I took a stab at this but ran into something I don't understand. For
recence, the whole implementation of unboxed sums is at
https://github.com/ghc/ghc/compare/master...tibbe:unboxed-sums and the
implementation of unarisation is at
https://github.com/ghc/ghc/compare/master...tibbe:unboxed-sums#diff-f5bc1f9e9c230db4cf882bf18368a818
.

Running the compiler on the following file:

{-# LANGUAGE UnboxedSums #-}
module Test where

f :: (# Int | Char #) -> Int
f (# x | #) = x
{-# NOINLINE f #-}

g = f (# 1 | #)

Yields an error, like so:

ghc-stage2: panic! (the 'impossible' happened)
  (GHC version 7.11.20150912 for x86_64-apple-darwin):
StgCmmEnv: variable not found
  ds_svq
  local binds for:
  ds_gvz
  ds_gvA

I probably got something wrong in UnariseStg, but I can't see what. I
printed this debug information to see the stg I'm rewriting:

unarise
  [f [InlPrag=NOINLINE] :: (#|#) Int Char -> Int
   [GblId, Arity=1, Str=DmdType, Unf=OtherCon []] =
   \r srt:SRT:[0e :-> patError] [ds_svq]
   case ds_svq of _ [Occ=Dead] {
 (#_|#) x_svs [Occ=Once] -> x_svs;
 (#|_#) _ [Occ=Dead] -> patError "UnboxedSum.hs:5:1-15|function
f"#;
   };,
   g :: Int
   [GblId, Str=DmdType] =
   \u srt:SRT:[r1 :-> f] []
   let {
 sat_svu [Occ=Once] :: Int
 [LclId, Str=DmdType] =
 NO_CCS I#! [1#];
   } in
 case (#_|#) [sat_svu] of sat_svv { __DEFAULT -> f sat_svv; };]
unariseAlts
  [81 :-> [realWorld#], svq :-> [ds_gvz, ds_gvA]]
  UbxTup 2
  wild_svr
  [((#_|#), [x_svs], [True], x_svs),
   ((#|_#),
[ipv_svt],
[False],
patError "UnboxedSum.hs:5:1-15|function f"#)]

It's ds_svg that's being complained about above. I find that a bit
confusing as that variable is never used on any RHS.

Some questions that might help me get there:

   - I added a new RepType for unboxed sums, like so:

   data RepType = UbxTupleRep [UnaryType]
   | UbxSumRep [UnaryType]
   | UnaryRep UnaryType

   Does this constructor make sense? I store the already flattened
   representation of the sum in here, rather than having something like
   [[UnaryType]] and storing each alternative.
   - In unariseAlts there's a bndr argument. Is that the binder of the
   scrutinee as a whole (e.g. the 'x' in case e of x { ... -> ... })?

Any other idea what I might have gotten wrong?


On Mon, Sep 14, 2015 at 1:03 AM, Simon Marlow  wrote:

> On 10/09/2015 10:37, Simon Peyton Jones wrote:
>
>> 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” is strictly jam; indeed never used I
>> think.  (I could be wrong but I’m pretty sure I’m not wrong in a
>> fundamental way.
>>
>
> Yes, the only thing the code generator needs to do with types is convert
> them to PrimReps (see idPrimRep), and all GC pointer types have the same
> PrimRep (PtrRep).
>
> Cheers
> Simon
>
>
>
>
>> SImon
>>
>> *From:*Johan Tibell [mailto:johan.tib...@gmail.com]
>> *Sent:* 09 September 2015 23:22
>> *To:* Simon Peyton Jones; Simon Marlow; ghc-devs@haskell.org
>> *Subject:* Converting unboxed sum types in StgCmm
>>
>> Hi!
>>
>> The original idea for implementing the backend part of the unboxed sums
>> proposal was to convert from the core representation to the actual data
>> representation (i.e. a tag followed by some pointer and non-pointer
>> fields) in the unarise stg-to-stg
>> <
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fghc%2fghc%2fblob%2fmaster%2fcompiler%2fsimplStg%2fUnariseStg.hs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cca7beffb01494517d75108d2b9652973%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=U%2bFUNsL87iEemajTnAW9SxD9N5b4%2bG8QB1q19%2fX%2bBI4%3d
>> >
>> pass.
>>
>> I have now realized that this won't work. The problem is that stg is too
>> strongly typed. When we "desugar" sum types we need to convert functions
>> receiving a value e.g. from
>>
>>  f :: (# Bool | Char #) -> ...
>>
>> to
>>
>>  f :: NonPointer {-# tag#-} -> Pointer {-# Bool or Char #-} -> ...
>>
>> Since stg is still typed with normal Haskell types (e.g. Bool, Char,
>> etc), this is not possible, as we cannot represent an argument which has
>> two different types.
>>
>> It seems to me that we will have to do the conversion in the stg-to-cmm
>> <
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fghc%2fghc%2fblob%2fmaster%2fcompiler%2fcodeGen%2fStgCmm.hs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cca7beffb01494517d75108d2b9652973%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=aXKZ78eGNKbJ6eZkxZgyJHgsAXpgOBjg3Zvqj%2bq7pk0%3d
>> >
>> pass, which is quite a bit more involved. For example, StgCmmEnv.idToReg
>> function will have to change from
>>
>>  idToReg :: 

Re: Proposal: Include GHC version target in libraries' description

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 14/08/15 11:30, Alexander Berntsen wrote:
>   -make GHC a distribution and use that field,
>   -use the platform feature,
>   -make a new field -- bundled-with, bundles, or similar,
>   -or use the package collection feature.
> 
> [L]et's make a decision.
I get the feeling nobody liked my original proposal of just writing it
in the .cabal file, so I'm reluctant to put effort into a set of patches
that will be rejected. On the other hand I see no progress here. Does
nobody care? I am keen on hacking on either solution if someone would
just give some sort of acknowledgement here.
- -- 
Alexander
alexan...@plaimi.net
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJV9ragAAoJENQqWdRUGk8B70YP/iyRI/F9qNJAVpHxxPX3nxA9
Z7sJ8hO/vazF15Zumcer0x8cm42VCZyexrnE/S+0p513t5GVUAcYndB3kgALgqvX
7UnimodWkNwIFttrHgNIMXkrx2ezBeDg17wPND2AbCeLOajUn6KC4bylfg/ymht+
eXVUaitVM9jva/M3LpooPY+gIeuAOsMrPMzW64Dz3c3PzKrTTXm3GxYygs8iWFgD
euU/ry1zP/UYKdwdoaLd5h87t4RNuahms6BQKXfVFCxnDGlodDk3HI7mhFebiPg7
aHZh332+goUGTW84OoVd2N7oKfY2ge1MGPJxTJWNwv72x8QhmEyd+0DALMx0Ra8T
GTZe1OkZOP+kCrI+CVUeOrxjBvHI7bxedGW2RsJzKO6F6zGf7x4YYNwMcpHlhux+
fK8CxebXDBxmboy0LSjtiNxhX2EiXC1SiqT/Wa3/MnUeM3Z+O5AXcud1MpJXH5qf
hWIBD1gLkAaeovZqqKz9Kf9fLzHtPphMMc+EWwojdgoTwXRc5QQMFpIkBU90gsqL
uEFhoMF9aCIhkymo+0sReAJZsSNFAlgv8Ka56CLipIIzRGIr2z+VU8a3tbT7Cnvg
tnWA9kOpLV2vokxQghEBokSzuTeFUReWYNDvOkm85KqAHn+9jkCzqA5z1B8K7YRy
thN93we1J3EE4Xs7Lezw
=MEGt
-END PGP SIGNATURE-
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Converting unboxed sum types in StgCmm

[Simon Marlow]

On 10/09/2015 10:37, Simon Peyton Jones wrote:

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” is strictly jam; indeed never used I
think.  (I could be wrong but I’m pretty sure I’m not wrong in a
fundamental way.


Yes, the only thing the code generator needs to do with types is convert 
them to PrimReps (see idPrimRep), and all GC pointer types have the same 
PrimRep (PtrRep).


Cheers
Simon





SImon

*From:*Johan Tibell [mailto:johan.tib...@gmail.com]
*Sent:* 09 September 2015 23:22
*To:* Simon Peyton Jones; Simon Marlow; ghc-devs@haskell.org
*Subject:* Converting unboxed sum types in StgCmm

Hi!

The original idea for implementing the backend part of the unboxed sums
proposal was to convert from the core representation to the actual data
representation (i.e. a tag followed by some pointer and non-pointer
fields) in the unarise stg-to-stg

pass.

I have now realized that this won't work. The problem is that stg is too
strongly typed. When we "desugar" sum types we need to convert functions
receiving a value e.g. from

 f :: (# Bool | Char #) -> ...

to

 f :: NonPointer {-# tag#-} -> Pointer {-# Bool or Char #-} -> ...

Since stg is still typed with normal Haskell types (e.g. Bool, Char,
etc), this is not possible, as we cannot represent an argument which has
two different types.

It seems to me that we will have to do the conversion in the stg-to-cmm

pass, which is quite a bit more involved. For example, StgCmmEnv.idToReg
function will have to change from

 idToReg :: DynFlags -> NonVoid Id -> LocalReg

to

 idToReg :: DynFlags -> NonVoid Id -> [LocalReg]

to accommodate the fact that we might need more than one register to
store a binder.

Any ideas for a better solution?

-- Johan


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