RE: Unlifted data types

[Simon Peyton Jones]

| I've added a section on parametric levity polymorphism to the wiki.
| Sorry it took so long.

What's the wiki page?

Simon
| 
| I might add some thoughts about first-class `!a` being the only
| semantic hole in our current strict data type situation later if I
| remember to do so.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Floating and CorePrep

[Simon Peyton Jones]

Luke asks

| Also, can you explain why CorePrep does some floating of its own?

I thought that there was a good reason that CorePrep does floating, but
the more I tried to explain it, the less sense the explanation made. So
here's the reasoning.  Maybe I'm missing things, or maybe there's an
opportunity here to simplify GHC.  So I'm cc'ing ghc-devs.

CorePrep convets to ANF.  So if we have this: 
x = f (g y)
we might naively generate this
x = let a = g y in f a
Instead CorePrep generates this
a = g y
x = f a

However now I think about it again, I'm suddenly not sure why this is important.

* If x is a lazy thunk, the floated version will allocate 'a'
  early.  So we should only float if (f a) is a head-normal form.
  (And that happens; see CorePrep.wantFloatNested).  But if (f a)
  is a HNF, the simplifier will already have ANF'd it in prepareRhs.

* If x is marked demanded (strict), then the naive ANF'ing might
  generate
  case (let a = g y in f a) of 
  because CorePrep converts the 'let x' into a case.  But that's
  OK because I think the code generator is fine with a let nested
  inside a case like that.

So, for nested bindings, maybe we can simply NEVER do floating?  Ah,
there is on gotcha.  Consider
   x = f raise#
where f has arity 2.  Currently raise# responds True to
Id.hasNoBinding, so CorePrep must eta-expand to
   x = f (\x. raise# x)
and now we really would like to ANF to
   z = \x. raise# x
   x = f a
because the (f a) is not a thunk, but it would be if we
introduced a nested let.  Bother.

For top level, things are slightly different.  Here if we see
   x = f (g y)
we do want to float to get
   a = g y
   x = f a
because not the allocation of 'a' is done statically rather than
dynamically.  This is particularly important for large static lists
e.g.
   p = f [a,b,c,d,e]
when we want all those cons cells to be statically allocated.


This is all a bit unsatisfactory.  It would be much cleaner if
all floating was done by the simplifier, and CorePrep did none.

And I think it'd be worth a try at doing that.  I think the needful
stuff would be:

 * Always saturate hsaNoBinding functions in Core, not just at
   CorePrep
 * Be more aggressive about floating top-level bindings like 'p'
   in the simplifier

I'm not likely to undertake this myself soon, but I could advise.

Simon

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

Fwd: Compiling Core Haskell using GHC API

[Marek Wawrzos]

Hello,

I'm trying to compile some module with GHC API. I'm going to feed GHC with
Core generated by me.

So far is noticed, that function compileCoreToObj ends with an runtime
error on each call. In spide of this function produces some *.o and *.hi
files. However, produced interface file does not contain any item in
exports field, what makes compiled module unusable.

Because of this problem, I tried to achieve my goal by using steps
described here: https://wiki.haskell.org/GHC/As_a_library (the second
example)
I was able to print out Core produced form file. If I'm not wrong,
modifying structures passing on between sequent calls does not effect on
produced *.hi and *.o files. Both files are generated by `load
LoadAllTargets' call, and further calls (parseModule, loadModule, ...) does
not effect on generated files.

Could You give me any advices in that topic? Am I right about
compileCoreToObj and functions mentioned above?

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

Re: Unlifted data types

[Ryan Yates]

https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes

On Thu, Oct 8, 2015 at 6:02 AM, Simon Peyton Jones 
wrote:

> | I've added a section on parametric levity polymorphism to the wiki.
> | Sorry it took so long.
>
> What's the wiki page?
>
> Simon
> |
> | I might add some thoughts about first-class `!a` being the only
> | semantic hole in our current strict data type situation later if I
> | remember to do so.
> ___
> 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: Unlifted data types

[Richard Eisenberg]

On Oct 8, 2015, at 6:02 AM, Simon Peyton Jones  wrote:

> What's the wiki page?

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

Re: Fwd: Compiling Core Haskell using GHC API

[Edward Z. Yang]

If we look at the source code for hscCompileCore, it would seem that it
creates a ModGuts with mkModGuts which has an empty mg_exports, which
means that in all cases there will be no exported items.  So it's not
very useful!  You should file a bug.

We should fix this, but in the mean time, you could simply copypaste the
definition of hscCompileCore, and modify it so that you do set up
the ModGuts correctly with a real mg_exports field.

Edward

Excerpts from Marek Wawrzos's message of 2015-10-08 07:22:01 -0700:
> Hello,
> 
> I'm trying to compile some module with GHC API. I'm going to feed GHC with
> Core generated by me.
> 
> So far is noticed, that function compileCoreToObj ends with an runtime
> error on each call. In spide of this function produces some *.o and *.hi
> files. However, produced interface file does not contain any item in
> exports field, what makes compiled module unusable.
> 
> Because of this problem, I tried to achieve my goal by using steps
> described here: https://wiki.haskell.org/GHC/As_a_library (the second
> example)
> I was able to print out Core produced form file. If I'm not wrong,
> modifying structures passing on between sequent calls does not effect on
> produced *.hi and *.o files. Both files are generated by `load
> LoadAllTargets' call, and further calls (parseModule, loadModule, ...) does
> not effect on generated files.
> 
> Could You give me any advices in that topic? Am I right about
> compileCoreToObj and functions mentioned above?
> 
> Best Regards,
> Marek
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Context for typed holes

[David Feuer]

Unless something has changed really recently that I've missed, the typed
holes messages are missing some really important information: instance
information for types in scope. When I am trying to fill in a hole, I look
to the "relevant bindings" to show me what pieces I have available to use.
Those pieces don't include contexts! Is there something fundamentally hard
about adding this information? I'd only want instance information for type
variables--providing it for concrete types would make too much noise. I'd
also want information on equality constraints, of course.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs