Yes -- sweep it away! > On Feb 14, 2019, at 5:30 PM, Simon Peyton Jones via ghc-devs > <[email protected]> wrote: > > What do you (or anyone else) think about sweeping all that stuff away? See > my comments on > https://gitlab.haskell.org/ghc/ghc/merge_requests/361 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F361&data=02%7C01%7Csimonpj%40microsoft.com%7Cfc2d7f5498a34d68153008d692aaa9ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636857659024990967&sdata=H7euZSJmjiP%2BNE8KD9WD7TeeuHGFvuHzBAGLebPIMPM%3D&reserved=0> > > Simon > > From: Ryan Scott <[email protected]> > Sent: 14 February 2019 18:31 > To: Simon Peyton Jones <[email protected]> > Cc: [email protected] > Subject: Re: scopedSort and kind variable left-biasing > > Ah, I somehow forgot all about FreeKiTyVars. It turns out that the > `freeKiTyVarsAllVars` function [1] is exactly what drives this behavior: > > freeKiTyVarsAllVars :: FreeKiTyVars -> [Located RdrName] > freeKiTyVarsAllVars (FKTV { fktv_kis = kvs, fktv_tys = tvs }) = kvs ++ tvs > > That's about as straightforward as it gets. Thanks! > > Ryan S. > ----- > [1] > https://gitlab.haskell.org/ghc/ghc/blob/5c1f268e2744fab2d36e64c163858995451d7095/compiler/rename/RnTypes.hs#L1604-1605 > > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fblob%2F5c1f268e2744fab2d36e64c163858995451d7095%2Fcompiler%2Frename%2FRnTypes.hs%23L1604-1605&data=02%7C01%7Csimonpj%40microsoft.com%7Cfc2d7f5498a34d68153008d692aaa9ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636857659024990967&sdata=QaWLPwctKWcuIFJFdPAqBhJzA99%2FFtsftSuuAstHVEQ%3D&reserved=0> > > On Thu, Feb 14, 2019 at 12:46 PM Simon Peyton Jones <[email protected] > <mailto:[email protected]>> wrote: > See Note [Kind and type-variable binders] in RnTypes, and Note [Ordering of > implicit variables]. > And the data type FreeKiTyVars. > > But NB: that in https://gitlab.haskell.org/ghc/ghc/merge_requests/361 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F361&data=02%7C01%7Csimonpj%40microsoft.com%7Cfc2d7f5498a34d68153008d692aaa9ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636857659024990967&sdata=H7euZSJmjiP%2BNE8KD9WD7TeeuHGFvuHzBAGLebPIMPM%3D&reserved=0>, > I argue that with this patch we can sweep all this away. > > If we did, we’d probably end up with [j,a,k,b]. > > Perhaps that’s an ergonomic reason for retaining the current rather > cumbersome code. (Maybe it could be simplified.) > > Simon > > From: ghc-devs <[email protected] > <mailto:[email protected]>> On Behalf Of Ryan Scott > Sent: 14 February 2019 15:35 > To: [email protected] <mailto:[email protected]> > Subject: scopedSort and kind variable left-biasing > > Consider this function: > > f :: Proxy (a :: j) -> Proxy (b :: k) > > If you just collect the free type variables of `f`'s type in left-to-right > order, you'd be left with [a,j,b,k]. But the type of `f` is not `forall (a :: > j) j (b :: k) k. Proxy a -> Proxy b`, as that would be ill scoped. `j` must > come before `a`, since `j` appears in `a`'s kind, and similarly, `k` must > come before `b`. > > Fortunately, GHC is quite smart about sorting free variables such that they > respect dependency order. If you ask GHCi what the type of `f` is (with > -fprint-explicit-foralls enabled), it will tell you this: > > λ> :type +v f > f :: forall j k (a :: j) (b :: k). Proxy a -> Proxy b > > As expected, `j` appears before `a`, and `k` appears before `b`. > > In a different context, I've been trying to implement a type variable sorting > algorithm similar to the one that GHC is using. My previous understanding was > that the entirely of this sorting algorithm was implemented in > `Type.scopedSort`. To test my understanding, I decided to write a program > using the GHC API which directly uses `scopedSort` on the example above: > > main :: IO () > main = do > let tv :: String -> Int -> Type -> TyVar > tv n uniq ty = mkTyVar (mkSystemName (mkUniqueGrimily uniq) > (mkTyVarOcc n)) ty > j = tv "j" 0 liftedTypeKind > a = tv "a" 1 (TyVarTy j) > k = tv "k" 2 liftedTypeKind > b = tv "b" 3 (TyVarTy k) > sorted = scopedSort [a, j, b, k] > putStrLn $ showSDocUnsafe $ ppr sorted > > To my surprise, however, running this program does /not/ give the answer > [j,k,a,b], like what :type reported: > > λ> main > [j_0, a_1, k_2, b_3] > > Instead, it gives the answer [j,a,k,b]! Strictly speaking, this answer meets > the specification of ScopedSort, since it respects dependency order and > preserves the left-to-right ordering of variables that don't depend on each > other (i.e., `j` appears to the left of `k`, and `a` appears to the left of > `b`). But it's noticeably different that what :type reports. The order that > :type reports, [j,k,a,b], appears to bias kind variables to the left such > that all kind variables (`j` and `k`) appear before any type variables (`a` > and `b`). > > From what I can tell, scopedSort isn't the full story here. That is, > something else appears to be left-biasing the kind variables. My question is: > which part of GHC is doing this left-biasing? > > > > Ryan S. > > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
