- ghc-devs - Haskell.org

uniqAway and collisions
by Bartosz Nitka 07 Jan '16

07 Jan '16

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 @~ (<s_Xpw a_Xpz>_N :: s_Xpw a_Xpz ~# s_Xpw a_Xpz) @~ (<s_Xpw b_Xpy>_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: <s_Xpw a_Xpz>_N, CO: <s_Xpw b_Xpy>_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

3 5

latest symlink
by Joachim Breitner 07 Jan '16

07 Jan '16

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/ Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

4 5

expandTypeSynonyms panics after kind equality patch
by Ömer Sinan Ağacan 07 Jan '16

07 Jan '16

My branch panicking during stage 2 build and when I tried to debug I realized the panicking function is `unionTCvSubst`, when called by `expandTypeSynonyms`. In my branch I'm doing some type-based transformations and I'm using `expandTypeSynonyms` on type of identifiers for that. According to git blame logs, the function `unionTCvSubst` was added with kind equality patch. The patch made this change in `expandTypeSynonyms`: - = go (mkAppTys (substTy (mkTopTvSubst tenv) rhs) tys') + = let subst' = unionTCvSubst subst (mkTopTCvSubst tenv) in + go subst' (mkAppTys rhs tys') Which is what's causing the panic. The exact place it's panicking during the stage2 build is when I call `expandTypeSynonyms` on type `TvSubstEnv` (i.e. in my transformation I get type of an id and it turns out to be TvSubstEnv, when I call `expandTypeSynonyms` on this type it panics) I figured this much but I don't understand type system details, so, does anyone here have any ideas what's going wrong here? Richard? Note that this panic happens even though I don't do any changes in types - I'm just looking at the types for some transformations but no changes on the types are done.

2 1

Slowdown in concurrent program
by Facundo Domínguez 06 Jan '16

06 Jan '16

Dear devs, The following program shows worse measures when compiled with -O with both ghc-7.10.2 and ghc-7.8.3. Am I hitting a known bug? Or may someone point a mistake in the code? It also shows worse measures when using anything other than -N1. Thanks in advance, Facundo -- /opt/ghc-7.8.3/bin/ghc --make -threaded -fforce-recomp test.hs -- time ./test: 10 seconds -- -- /opt/ghc-7.8.3/bin/ghc --make -threaded -O -fforce-recomp test.hs -- time ./test: 48 seconds -- -- /opt/ghc-7.10.2/bin/ghc --make -threaded -fforce-recomp test.hs -- time ./test: 23 seconds -- -- /opt/ghc-7.10.2/bin/ghc --make -threaded -O -fforce-recomp test.hs -- time ./test: 57 seconds -- import Control.Concurrent import Control.Monad import Data.List main :: IO () main = do let xs = [ 1 .. 400000000] mv <- newEmptyMVar replicateM_ 4 $ forkIO $ putMVar mv $! foldl' (+) 0 xs nums <- replicateM 4 $ takeMVar mv print (nums :: [Integer])

3 3

Generics
by Simon Peyton Jones 05 Jan '16

05 Jan '16

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

1 0

Implementation idea for unboxed polymorphic types
by Francesco Mazzoli 05 Jan '16

05 Jan '16

(A nicely rendered version of this email can be found at <https://gist.github.com/bitonic/52cfe54a2dcdbee1b7f3>) ## 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 { x :: {-# UNPACK #-} !Double , y :: {-# UNPACK #-} !Double } ``` To use `#Point` generically, the following type class would be generated: ``` class PointFamily a where data #Point a :: * -- Family of types generated by @data #Point a@. #Point :: a -> a -> #Point a -- Constructor. #x :: #Point a -> a -- Projection @x@. #y :: #Point a -> a -- Projection @y@. ``` Thi type class lets us work with `#Point`s generically, for example ``` distance :: (PointFamily a, Fractional a) => #Point a -> #Point a -> a distance p1 p2 = let dx = #x p1 - #x p2 dy = #y p1 - #y p2 in sqrt (dx*dx + dy*dy) ``` Internally, for every type appearing for `a`, e.g. `#Point Double`, a new type equivalent to the `PointDouble` above would be generated by GHC, with the corresponding instance ``` instance PointFamily Double where data #Point Double = PointDouble #x = x #y = x ``` If it's not possible to instantiate `#Point` with the provided type (for example because the type is not `UNPACK`able, e.g. `#Point (Maybe A)`), GHC would throw an error. Note that we can compile `distance` in its polymorphic version (as opposed to C++ templates, where template functions _must_ be instantiated at every use). The polymorphic `distance` would require a call to "virtual functions" `#x` and `#y`, as provided by the `PointFamily` dictionary. But if we use `INLINE` or `SPECIALIZE` pragmas the virtual calls to `#x` and `#y` would disappear, making this as efficient as if we were to define `distance` on the manually defined `PointDouble`. Compiler hints would be put in place to always inline functions using macro types, if possible. Note that the inlining is only important so that the `PointFamily` dictionary disappears, e.g. functions containing recursive helpers are fine, such as ``` {-# INLINE leftmost #-} leftmost :: forall a. (PointFamily a, Ord a) => [#Point a] -> #Point a leftmost [] = error "leftmost: no points" leftmost (p0 : ps0) = go p0 ps0 where go :: #Point a -> [#Point a] -> Point# a go candidate (p : ps) = if #x p < #x candidate then go p ps else go candidate ps ``` It might be worth considering throwing a warning when a top-level definition whose type contains a macro type cannot be inlined, since the main performance benefit of using macro types would be lost. We can define instances for these types as normal, for instance ``` instance (Show a, PointFamily a) => Show (#Point a) where {-# INLINE show #-} show pt = "Point{x = " ++ #x pt ++ ", y = " ++ #y pt ++ "}" ``` `deriving` support could also be added. ## Further ideas ### Hide or remove `PointFamily` from the user In the examples above `PointFamily` is manipulated explicitely (e.g. in the type signature for `distance`). In most cases the right constraint could be generated automatically by GHC, although I think direct access to the type class would be beneficial (history shows that direct access to these facilities is good, see upcoming explicit type applications). Maybe the type class associated to a macro type should not even exist -- for example we could simply represent `#Point` as a type family and treat construction and destruction as built-in syntax (the `#` prefix). ### Pattern matching Sugar could be added to pattern match, e.g. ``` foo :: Point# a -> ... distance (Point# x1 y1) = ... or dinstance Point#{..} = ... -- #x and #y are available ``` ### No "record types" limitation Instead of restricting ourselves to single-constructor records, we could simply generate ``` data Point a = Point a { x :: !a , y :: !a } class PointFamily a where data Point# a :: * destruct :: Point# a -> Point a construct :: Point a -> Point# a ``` However, I think it would be harder to guarantee the well-behavedness of the inlined functions if we had this intermediate type. I also don't think macro types would be very useful beyond polymorphic unboxed types.

4 5

Open data kinds
by Jan Stolarek 03 Jan '16

03 Jan '16

Devs, I plan to work on implementing open data kinds (#11080). The idea is that users will be allowed to declare open kinds and then populate them with member types. Perhaps I will also implement closed data kinds. This is already possible using DataKinds, but the idea is to declare a data kind without corresponding data type - see #6024. Now, consider this declaration (syntax subject to bikeshedding): kind K = T In what namespace should T go: type namespace or data constructor namespace? If we put it in type namespace then it is possible for the user to declare a data constructor T that is completely unrelated to type T belonging to kind K. This might be confusing. If we put T in the data namespace then we miss the point of #6024. Thoughts? Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

3 4

Re: Haskeline on Windows
by Ryan Scott 01 Jan '16

01 Jan '16

This is already fixed in the haskeline GitHub repo [1], but I never got around to updating the downstream haskeline repo on git.haskell.org [2] since I don't have push access. Can someone update it for me? Ryan S. ----- [1] https://github.com/judah/haskeline/commit/576e7cbc4cde1195fb97c8540caad38de… [2] http://git.haskell.org/packages/haskeline.git

2 1

RE: Haskeline on Windows
by Tamar Christina 31 Dec '15

31 Dec '15

GHC 8.0 wasn't branched at the time and I forgot to push the mk entry to ignore the warning. But I believe now that GHC has been branched we can just update the submodule. The pull request that fixed this issue had a lot of other unrelated changes and was rather big so it wasn't updated before. Regards, TamarFrom: Ryan Scott Sent: ‎31/‎12/‎2015 23:39 To: ghc-devs(a)haskell.org Subject: Re: Haskeline on Windows This is already fixed in the haskeline GitHub repo [1], but I never got around to updating the downstream haskeline repo on git.haskell.org [2] since I don't have push access. Can someone update it for me? Ryan S. ----- [1] https://github.com/judah/haskeline/commit/576e7cbc4cde1195fb97c8540caad38de… [2] http://git.haskell.org/packages/haskeline.git _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

Haskeline on Windows
by Simon Peyton Jones 31 Dec '15

31 Dec '15

To get ‘haskeline’ to compile on Windows I have to apply the patch below. Otherwise this alignment thing is defined twice and the build fails Could someone fix it properly? Thanks! Simon modified System/Console/Haskeline/Backend/Win32.hsc @@ -167,7 +167,7 @@ getKeyEvent p = do data Coord = Coord {coordX, coordY :: Int} deriving Show -#let alignment t = "%lu", (unsigned long)offsetof(struct {char x__; t (y__); }, y__) +-- #let alignment t = "%lu", (unsigned long)offsetof(struct {char x__; t (y__); }, y__) instance Storable Coord where sizeOf _ = (#size COORD) alignment _ = (#alignment COORD)

1 0