Re: Implementation idea for unboxed polymorphic types

[Ömer Sinan Ağacan]

That's a really good question, I think. I tried to make it working here:
https://gist.github.com/osa1/00597c24a79816c7ef90/

In that code, just assume whenever you see a type or constructor with Ubx
prefix it's just magically get unboxed.

I added lots of inline comments about problems and results etc. but in short,
we have a problem that this idea doesn't solve: GHC doesn't generate
specialized functions at all. So if I have a function that's too big to inline
or if I simply don't want to inline for some reason, we're out of luck.

(I don't understand this restriction, specialization without inlining would be
very useful in lots of cases, I think)

Second thing is ideally we shouldn't be using unboxed types in the code
manually. For example, in the `distance` functions we should really write
`distance :: Point a => Point a -> a`. But this means that `Unbox` typeclass
needs to be magical, GHC should recognize it and specialize functions using
Unbox dictionaries.

2015-11-17 10:54 GMT-05:00 Alexey Vagarenko :
> At the moment, GHC does not support type families over kind #,
> but if it did, would this code do the trick
> https://gist.github.com/vagarenko/077c6dd73cd610269aa9 ?
>
> 2015-11-16 22:32 GMT+05:00 Ömer Sinan Ağacan :
>>
>> > But I don't see why you'd need quoting at constructor calls. Couldn't
>> > you
>> > just have a type class like `PointFamily`?
>>
>> This is exactly right, my memory has failed me. My initial implementation
>> didn't use the type family trick, I had further attempts that use type
>> families
>> but honestly I don't remember how good it worked. This was quite a while
>> ago.
>>
>> 2015-11-15 19:41 GMT-05:00 Richard Eisenberg :
>> > After reading Francesco's original post, I immediately thought of Ömer's
>> > proposed approach, of using Template Haskell to produce the right data
>> > family instances. But I don't see why you'd need quoting at constructor
>> > calls. Couldn't you just have a type class like `PointFamily`? I'd be more
>> > interested to see client code in Ömer's version than the TH generation 
>> > code.
>> >
>> > The TH approach would seem to require having a fixed set of
>> > specializations, which is a downside. But I'm not sure it's so much of a
>> > downside that the approach is unusable.
>> >
>> > Richard
>> >
>> > On Nov 15, 2015, at 10:08 AM, Ömer Sinan Ağacan 
>> > wrote:
>> >
>> >> I had started working on exactly the same thing at some point. I had a
>> >> TemplateHaskell-based implementation which _almost_ worked.
>> >>
>> >> The problem was that the syntax was very, very heavy. Because I had to
>> >> use
>> >> quotes for _every_ constructor application(with explicitly passed
>> >> types).
>> >> (because I had a specialized constructor for every instantiation of
>> >> this
>> >> generic type)
>> >>
>> >> Another problem was that because of how TemplateHaskell quotes
>> >> evaluated, I
>> >> couldn't use a `List Int` where `List` is a template without first
>> >> manually
>> >> adding a line for generating specialized version of `List` on `Int`.
>> >>
>> >> When all of these combined it became very hard to use. But it was a
>> >> proof-of-concept and I think it worked.
>> >>
>> >> (Code is horrible so I won't share it here :) I had to maintain a state
>> >> shared
>> >> with different TH quote evaluations etc.)
>> >>
>> >> 2015-11-15 5:26 GMT-05:00 Francesco Mazzoli :
>> >>> (A nicely rendered version of this email can be found at
>> >>> )
>> >>>
>> >>> ## Macro types
>> >>>
>> >>> I very often find myself wanting unboxed polymorphic types
>> >>> (e.g. types that contain `UNPACK`ed type variables). I find
>> >>> it extremely frustrating that it's easier to write fast _and_
>> >>> generic code in C++ than in Haskell.
>> >>>
>> >>> I'd like to submit to the mailing list a very rough proposal
>> >>> on how this could be achieved in a pretty straightforward way
>> >>> in GHC.
>> >>>
>> >>> The proposal is meant to be a proof of concept, just to show that
>> >>> this could be done rather easily. I did not think about a nice
>> >>> interface or the implementation details in GHC. My goal is to
>> >>> check the feasibility of this plan with GHC developers.
>> >>>
>> >>> I'll call such types "macro types", since their effect is similar
>> >>> to defining a macro that defines a new type for each type
>> >>> variable instantiation.
>> >>>
>> >>> Consider
>> >>>
>> >>> ```
>> >>> data #Point a = Point
>> >>>  { x :: {-# UNPACK #-} !a
>> >>>  , y :: {-# UNPACK #-} !a
>> >>>  }
>> >>> ```
>> >>>
>> >>> This definition defines the macro type `#Point`, with one parameter
>> >>> `a`.
>> >>>
>> >>> Macro types definition would be allowed only for single-constructor
>> >>> records. The intent is that if we mention `#Point Double`, it will
>> >>> be equivalent to
>> >>>
>> >>> ```
>> >>> data PointDouble = PointDouble
>> 

uniqAway and collisions

[Bartosz Nitka]

Hi,

I'm running into core lint issues [1] with my determinism patch [2] and
they appear to come down to uniqAway coming up with a Unique that's already
used in the expression. That creates a collision, making next substitution
substitute more than it needs.

I have 2 questions:

1. When is it safe to use uniqAway?

2. Is my conclusion reasonable given this trace: (full trace here [3])?

I. We start out with (line 123):

CallStack (from ImplicitParams):
  pprSTrace, called at compiler/coreSyn/CoreLint.hs:659:12 in ghc:CoreLint
  e: EqConstr
   @ (s_Xpw a_Xpz)
   @ (s_Xpw b_Xpy)
   @ s_Xpw
   @ b_Xpy
   @ a_Xpz
   @~ (_N :: s_Xpw a_Xpz ~# s_Xpw a_Xpz)
   @~ (_N :: s_Xpw b_Xpy ~# s_Xpw b_Xpy)
   dt_aq3
  fun: EqConstr
  args: [TYPE: s_Xpw a_Xpz, TYPE: s_Xpw b_Xpy, TYPE: s_Xpw,
 TYPE: b_Xpy, TYPE: a_Xpz, CO: _N, CO: _N,
 dt_aq3]
  fun_ty: forall a_apr b_aps (s_Xpw :: * -> *) b_Xpy a_Xpz.
  (a_apr ~# s_Xpw a_Xpz, b_aps ~# s_Xpw b_Xpy) =>
  EqTypes a_Xpz b_Xpy -> EqTypes a_apr b_aps

II. Then we create s_Xpz with uniqAway (line 499) which has the same unique
as a_Xpz above

CallStack (from ImplicitParams):
  pprSTrace, called at compiler/types/TyCoRep.hs:1947:5 in ghc:TyCoRep
  old_var: s_Xpy
  new_var: s_Xpz

III. Which causes trouble when we want to substitute s_Xpw for s_Xpz and we
substitute a_Xpz as well (line 733):

CallStack (from ImplicitParams):
  pprSTrace, called at compiler/coreSyn/CoreLint.hs:813:11 in ghc:CoreLint
  substTyWith [tv] [arg_ty] body_ty forall b_XpB a_XpD.
(s_Xpw s_Xpw ~# s_Xpw a_XpD, s_Xpw
b_Xpy ~# s_Xpw b_XpB) =>
EqTypes a_XpD b_XpB -> EqTypes (s_Xpw
s_Xpw) (s_Xpw b_Xpy)

The uniqAway comes from substTyVarBndrCallback which blames to nokinds
patch.

Thanks,
Bartosz
[1] https://phabricator.haskell.org/P77
[2] https://phabricator.haskell.org/P76
[3] https://phabricator.haskell.org/P78
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Generics

[Simon Peyton Jones]

Hi Ryan
In a fit of housekeeping I added a “Generics” keyword to the generics-related 
tickets that you are now masterminding, so that we can have an auto-generated 
list on the Generics home page
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GenericDeriving
Any progress you can make would be great!
Thanks
Simon

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

Re: latest symlink

[Andrew Farmer]

Possibly related, when I use hoogle to look up GHC things ("+ghc
Unique", for instance) and try to click through to the haddocks, it
always 404s.

If I change the link from:

https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc/Unique.html#t:Unique

to:

https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-7.10.3/Unique.html#t:Unique

Then it works.

So, is there a way to point:

https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc

to:

https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-7.10.3

?

On Mon, Jan 4, 2016 at 5:32 PM, Ben Gamari  wrote:
> Joachim Breitner  writes:
>
>> Hi,
>>
>> https://downloads.haskell.org/~ghc/latest/ still points to
>> https://downloads.haskell.org/~ghc/7.10.2/ and not
>> https://downloads.haskell.org/~ghc/7.10.3/
>>
> So you are right. It should be fixed now.
>
> Cheers,
>
> - Ben
>
>
> ___
> 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: Inlining of methods (dictionary accessors) in GHC 7.10?

[Conal Elliott]

Sorry for the editing error. I meant "Did something about change with ...".

On Tue, Jan 5, 2016 at 9:38 PM, Conal Elliott  wrote:

> Did something about change with method inlining between GHC 7.8.2 and
> 7.10.3? I don't mean methods attached to instances, but rather the method
> name itself, which I understand is defined as simple field accessors into a
> dictionary. I do inlining indirectly via HERMIT, and the method names are
> no longer successfully inlining to the accessors. The dictionaries
> themselves inline fine, as do field accessors for algebraic types with
> named fields.
>
> -- Conal
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Inlining of methods (dictionary accessors) in GHC 7.10?

[Andrew Farmer]

I *think* we found our answer here:

https://github.com/ghc/ghc/blob/2db18b8135335da2da9918b722699df684097be9/compiler/typecheck/TcInstDcls.hs#L158

On Tue, Jan 5, 2016 at 9:39 PM, Conal Elliott  wrote:
> Sorry for the editing error. I meant "Did something about change with ...".
>
> On Tue, Jan 5, 2016 at 9:38 PM, Conal Elliott  wrote:
>>
>> Did something about change with method inlining between GHC 7.8.2 and
>> 7.10.3? I don't mean methods attached to instances, but rather the method
>> name itself, which I understand is defined as simple field accessors into a
>> dictionary. I do inlining indirectly via HERMIT, and the method names are no
>> longer successfully inlining to the accessors. The dictionaries themselves
>> inline fine, as do field accessors for algebraic types with named fields.
>>
>> -- Conal
>
>
>
> ___
> 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

Inlining of methods (dictionary accessors) in GHC 7.10?

[Conal Elliott]

Did something about change with method inlining between GHC 7.8.2 and
7.10.3? I don't mean methods attached to instances, but rather the method
name itself, which I understand is defined as simple field accessors into a
dictionary. I do inlining indirectly via HERMIT, and the method names are
no longer successfully inlining to the accessors. The dictionaries
themselves inline fine, as do field accessors for algebraic types with
named fields.

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

Re: latest symlink

[Andrew Farmer]

Yeah, I had to ask for this once before and it broke again with a new
GHC version, so I figured it wasn't the right solution. I take it most
people don't use hoogle on the GHC codebase... but I find it useful to
search by type signature.

Thanks for the temporary fix though!

On Tue, Jan 5, 2016 at 2:48 PM, Ben Gamari  wrote:
> Andrew Farmer  writes:
>
>> Possibly related, when I use hoogle to look up GHC things ("+ghc
>> Unique", for instance) and try to click through to the haddocks, it
>> always 404s.
>>
> I've gone ahead and created a symlink for now. That being said, this
> seems like a very hacky solution.
>
> Moreover, I doubt that the database that the haskell.org Hoogle instance
> is using matches the current state of the code. We should probably try
> to update it.
>
> Cheers,
>
> - Ben
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: uniqAway and collisions

[Edward Z. Yang]

Hello Bartosz,

The principle between uniqAway is described in the "Secrets of the GHC
Inliner" paper

http://research.microsoft.com/en-us/um/people/simonpj/Papers/inlining/

I doubt there's a bug in uniqAway; it's more likely the in scope set is
not correct.

Edward

Excerpts from Bartosz Nitka's message of 2016-01-05 09:39:54 -0800:
> Hi,
> 
> I'm running into core lint issues [1] with my determinism patch [2] and
> they appear to come down to uniqAway coming up with a Unique that's already
> used in the expression. That creates a collision, making next substitution
> substitute more than it needs.
> 
> I have 2 questions:
> 
> 1. When is it safe to use uniqAway?
> 
> 2. Is my conclusion reasonable given this trace: (full trace here [3])?
> 
> I. We start out with (line 123):
> 
> CallStack (from ImplicitParams):
>   pprSTrace, called at compiler/coreSyn/CoreLint.hs:659:12 in ghc:CoreLint
>   e: EqConstr
>@ (s_Xpw a_Xpz)
>@ (s_Xpw b_Xpy)
>@ s_Xpw
>@ b_Xpy
>@ a_Xpz
>@~ (_N :: s_Xpw a_Xpz ~# s_Xpw a_Xpz)
>@~ (_N :: s_Xpw b_Xpy ~# s_Xpw b_Xpy)
>dt_aq3
>   fun: EqConstr
>   args: [TYPE: s_Xpw a_Xpz, TYPE: s_Xpw b_Xpy, TYPE: s_Xpw,
>  TYPE: b_Xpy, TYPE: a_Xpz, CO: _N, CO: _N,
>  dt_aq3]
>   fun_ty: forall a_apr b_aps (s_Xpw :: * -> *) b_Xpy a_Xpz.
>   (a_apr ~# s_Xpw a_Xpz, b_aps ~# s_Xpw b_Xpy) =>
>   EqTypes a_Xpz b_Xpy -> EqTypes a_apr b_aps
> 
> II. Then we create s_Xpz with uniqAway (line 499) which has the same unique
> as a_Xpz above
> 
> CallStack (from ImplicitParams):
>   pprSTrace, called at compiler/types/TyCoRep.hs:1947:5 in ghc:TyCoRep
>   old_var: s_Xpy
>   new_var: s_Xpz
> 
> III. Which causes trouble when we want to substitute s_Xpw for s_Xpz and we
> substitute a_Xpz as well (line 733):
> 
> CallStack (from ImplicitParams):
>   pprSTrace, called at compiler/coreSyn/CoreLint.hs:813:11 in ghc:CoreLint
>   substTyWith [tv] [arg_ty] body_ty forall b_XpB a_XpD.
> (s_Xpw s_Xpw ~# s_Xpw a_XpD, s_Xpw
> b_Xpy ~# s_Xpw b_XpB) =>
> EqTypes a_XpD b_XpB -> EqTypes (s_Xpw
> s_Xpw) (s_Xpw b_Xpy)
> 
> The uniqAway comes from substTyVarBndrCallback which blames to nokinds
> patch.
> 
> Thanks,
> Bartosz
> [1] https://phabricator.haskell.org/P77
> [2] https://phabricator.haskell.org/P76
> [3] https://phabricator.haskell.org/P78
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: latest symlink

[Ben Gamari]

Andrew Farmer  writes:

> Possibly related, when I use hoogle to look up GHC things ("+ghc
> Unique", for instance) and try to click through to the haddocks, it
> always 404s.
>
I've gone ahead and created a symlink for now. That being said, this
seems like a very hacky solution.

Moreover, I doubt that the database that the haskell.org Hoogle instance
is using matches the current state of the code. We should probably try
to update it.

Cheers,

- Ben



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