Fix shadow and pattern warnings

[garyb]

unsafeThrow is a bit dodgy, but getting meaningful errors from unsafe failures may be worthwhile? I think we do that in the unsafe FFI in some other places.

[garyb]

I'll use this approach elsewhere too if we're happy with it. I don't really want to make a public unsafeThrow function though, so it will mean duplicating it a bunch of times which probably isn't great either. Thoughts?

[paf31]

I think unsafeThrow is fine, but I wonder if it should go into different package. Seems like it would be useful elsewhere.

I was planning to create purescript-partial if we went with the Partial type class idea on top of the exhaustivity checker, so maybe that would be a good place to put it, and call it patternMatchFailure or something like that?

[paf31]

Everything looks great, by the way.

[garyb]

Yeah that makes sense actually. I assume purescript-partial would be a core library?

[paf31]

Yes I think so. It would probably just define the unsafePartial function we discussed before:

unsafePartial :: forall a. (forall dummy. (Partial) => a) -> a
unsafePartial f = unsafeCoerce f unit

and possibly some helper functions, like something to rethrow the pattern match error with a useful message.

Incidentally, I'd like to be able to remove the forall dummy that's in there. The parser doesn't allow constrained types without a forall right now.

[garyb]

Perhaps we should have it as patternMatchFailure :: Partial => String -> a then too - that way we can use the Partial class without having magic compiler support: to get rid of the warning, you'd use patternMatchFailure, but to use that it imposes the Partial class requirement (unless the unsafePartial coercion is used internally, but we can recommend against that).

[paf31]

But then every module would have a potential dependency on partial right? That seems like it could lead to unhelpful errors. I was thinking I'd just insert a Partial constraint into an otherwise clause in any partial case expression. That way, you'd get a No instance for Partial error, which we could tidy up in Errors.

[garyb]

Re: dependency, that's true: maybe another option would be to put Partial in the Prelude then?

How would it lead to unhelpful errors though? I think adding a Partial constraint in the compiler would more likely lead to unhelpful errors - unless we're saying Partial is defined in Prim - as otherwise it still needs to "come from" somewhere (and you'd still need to include purescript-partial so you could unsafePartial eventually).

[paf31]

Yes, I'm suggesting Partial should go in Prim. I'd like to avoid getting errors like Module Prelude not found. We don't have any hard dependencies, even on Prelude, in the compiler right now, do we? Only in PSCi.

[garyb]

Yeah, that's right.

I suppose the advantage of the compiler adding the constraint is that it turns these exhaustivity warnings into actual errors, in that the Partial constraint will need adding to the function's type... but since we're not doing that right now anyway, what should I do about this for now?

We'll end up with an almost universal purescript-partial dependency if I do do what you suggested above, creating patternMatchFailure in there. Should I just go with this approach everywhere for now, and then we can Partialify all the libraries once the compiler support is there?

[paf31]

Yes, I think that's the best approach. So we'll leave unsafeThrow here for now or create purescript-partial?

[garyb]

Yeah I think so, I'll just duplicate it as needed for now, and then can take it all out again for 0.7.3 or whenever Partial appears.

[paf31]

Sounds good.

[paf31]

🚢