Update to v0.14.0-rc2

[JordanMartinez]

• Builds off of Fix compiler warnings #58
• updates CI to use v0.14.0-rc2
• Updates dependencies to master and drops the proxy dependency as this is now (or soon will be) included in prelude

Note: this does produce the following compiler warning, which I had forgotten about:

[1/1 ImplicitQualifiedImportReExport] .spago/typelevel-prelude/v5.0.2/src/Type/Data/Ordering.purs:15:1

  15  import Prim.Ordering as PO -- refer to kind Ordering via `PO.Ordering`
      ^^^^^^^^^^^^^^^^^^^^^^^^^^
  
  Module Prim.Ordering was imported as PO with unspecified imports.
  As this module is being re-exported, consider using the explicit form:
  
    import Prim.Ordering (EQ, GT, LT, Ordering) as PO

[JordanMartinez]

CI will fail until my "Port proxy to prelude" PR is merged into prelude's master branch

[JordanMartinez]

I believe CI will pass if restarted again.

[JordanMartinez]

Because warnings count as errors, CI is not passing because of this warning:

[1/1 ImplicitQualifiedImportReExport] src/Type/Data/Ordering.purs:15:1

  15  import Prim.Ordering as PO -- refer to kind Ordering via `PO.Ordering`

      ^^^^^^^^^^^^^^^^^^^^^^^^^^

  

  Module Prim.Ordering was imported as PO with unspecified imports.

  As this module is being re-exported, consider using the explicit form:

  

    import Prim.Ordering (EQ, GT, LT, Ordering) as PO

[hdgarrood]

Are you able to apply that suggestion to silence the warning?

[JordanMartinez]

I don't think so. I'd have to look at this again, but I remember this being a problem in a variety of ways because we don't have data kinds yet.
I won't be able to get to this until tomorrow.

[JordanMartinez]

If I apply that suggestion, I get a compiler error:

* Building project in /home/jordan/Programming/Projects/fourteen/purescript-typelevel-prelude
[1/1 KindsDoNotUnify] src/Type/Data/Ordering.purs:29:37

  29  instance isOrderingLT :: IsOrdering LT where reflectOrdering _ = LT
                                          ^^
  
  Could not match kind
  
    Ordering
  
  with kind
  
    Ordering
  
  while checking that type LT
    has kind Ordering
  while inferring the kind of IsOrdering LT
  in type class instance
  
    Type.Data.Ordering.IsOrdering LT

because the Ordering kind isn't also imported:

module Type.Data.Ordering 
  (module PO) 
  where

import Prim.Ordering (EQ, GT, LT, Ordering) as PO
import Prim.Ordering (LT, EQ, GT)
import Data.Ordering (Ordering(..))

When I do import it,

module Type.Data.Ordering 
  (module PO) 
  where

import Prim.Ordering (EQ, GT, LT, Ordering) as PO
import Prim.Ordering (LT, EQ, GT, Ordering) -- <- added Ordering kind here
import Data.Ordering (Ordering(..))

...the warning becomes a compiler error:

[7/7 ScopeConflict] src/Type/Data/Ordering.purs:60:17

  60  class Equals :: Ordering -> Ordering -> Boolean -> Constraint
                      ^^^^^^^^
  
  Conflicting definitions are in scope for type Ordering from the following modules:
  
    Data.Ordering
    Prim.Ordering

[hdgarrood]

Kind unification isn't affected by whether or not the kinds in question are in scope, so that error won't be because Ordering isn't imported. I think you might have been using an older version of the branch, because applying that suggestion (and fixing the Ordreing typo) fixes the build for me.

[JordanMartinez]

I think it was the Ordreing type that messed me up. CI now builds.

I think my understanding our the syntax was also wrong. I thought import Foo (Bar) as F meant one could only reexport F as a module or use F.Bar, but not both.

[hdgarrood]

Could you use the non-unicode versions: forall and -> here, please? I know it's a bit of a nit but we have a policy for the core libraries that we use ASCII syntax. Also, is there a reason not to use a and b as the type variable names? I think it would be good if the signature matched that for the term-level version of $.

Suggested change

	type APPLY ∷ ∀ d c . (d → c) → d → c
	type APPLY ∷ forall a b. (a -> b) -> a -> b

I also don't think APPLY and FLIP belong in Type.Row, since they don't really have anything to do with rows. Perhaps they could go into a new module Type.Function, to mirror the term-level versions which live in Data.Function?

[hdgarrood]

Same here re unicode syntax and type variable names

[JordanMartinez]

I've updated the PR to remove the unicode syntax and moved the APPLY and FLIP to Type.Function.purs