Superceded - Update to v0.14.0-rc2

[JordanMartinez]

I cherry-picked kl0tli's commit, but resolved the merge conflicts by setting dependencies to master

[kl0tl]

One of those Coercible constraints will become redundant when (if?) we merge purescript/purescript#3930.

[JordanMartinez]

Right, but until that's done, I'm leaving this in.

[hdgarrood]

I'd like to leave out the Coercible superclasses and the removal of the Newtype class's methods for now, mostly because this change will require additional compiler changes due to the compiler having knowledge of the Newtype class.

[JordanMartinez]

Is this due to not wanting to hold up the v0.14.0 release?

[hdgarrood]

Yes

[JordanMartinez]

I've added back in the wrap/unwrap members and removed the Coercible super class. However, I kept @kl0tl's other coerce functions as is.

[JordanMartinez]

CI passes now.

[hdgarrood]

Can you update psa to 0.8.0 in package.json please? It's still using an older version, which is what's causing the raw JSON output in CI.

Also, I'm less sure about this approach - it seems weird to me to use Coercible for half of the conversions, but Newtype for the rest. I'd prefer to spend a bit more time exploring the design space before updating this library to make use of Coercible. Coercible is essentially a more powerful version of Newtype, since it can do everything Newtype can and more, so maybe that raises the question of whether Newtype should continue to exist? For example, we can now write:

un :: forall t a. Coercible t a => (a -> t) -> t -> a
un = coerce

ala :: forall f t a s b. Functor f => Coercible (f t) (f a) => Coercible b s => (a -> t) -> ((b -> s) -> f t) -> f a
ala _ f = coerce (f coerce)

The only reasons I can think of that we wouldn't do this is that type inference won't be quite as good since we don't have the functional dependency that the Newtype class has, and also since it's more power than you need in cases where you only want to unwrap one layer of newtypes. Really I think this is a significant enough change that it needs its own PR.

[JordanMartinez]

maybe that raises the question of whether Newtype should continue to exist?

Good point. I hadn't considered that... Could these functions be ported to safe-coerce then? And should removing the Newtype class be done now or done in the next breaking changes PS release?

[hdgarrood]

I think these functions should exist in a separate non-core library first, and we can consider moving them into core after they've been used for a while and we have a better idea of how useful they are.

[hdgarrood]

I'm not saying we should remove the Newtype class - I think if I had to decide right now I'd actually say we shouldn't remove it. I'm just saying I don't think we've yet explored the design space well enough to make a change like this for a library that so many other libraries depend on.

[JordanMartinez]

Ah, ok. That makes more sense. So, keep this library as it originally was (but updated to v0.14.0) and then explore the design space of this context in a separate non-core repo. Once that gets more mature, migrate that repo into core, correct?

[hdgarrood]

Yes, exactly. The point of the exploration is to decide what to do next: we won't necessarily just migrate this other separate repo into core. We might decide that it supersedes Newtype, and replace the approach we currently have here with that one. Or alternatively, we might decide that it doesn't need to be in core at all.

[JordanMartinez]

The only reasons I can think of that we wouldn't do this is that type inference won't be quite as good since we don't have the functional dependency that the Newtype class has, and also since it's more power than you need in cases where you only want to unwrap one layer of newtypes.

It sounds like Newtype will still need to exist, if only to add those functional dependencies.

[hdgarrood]

Not necessarily - I think it's possible that in practice, the lack of the functional dependency isn't an issue. If you always supply the newtype constructor as the first argument, which I would guess most people probably do, then both types are already determined by that argument, so the functional dependency doesn't give you any additional information.

[JordanMartinez]

In other words, creating a function like un but updating it to use Coercible?

un :: forall t a. Coercible t a => (a -> t) -> t -> a
un _ = coerce

[JordanMartinez]

Closing now that #24 was merged.