Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[discussion] Catch contradictory predicates when declaring refined type #14

Open
kachayev opened this issue Jun 21, 2018 · 16 comments
Open
Labels

Comments

@kachayev
Copy link
Contributor

kachayev commented Jun 21, 2018

That's a kinda tricky thing to do...

From "obvious" steps we can take:

  1. Mark types & predicates as :seq, :num and :string and converge the predicates tree to the most "common" one. In case of mismatch show the error

  2. For ordering predicates, we can do basic checks with :num types using simple rules to deal with intervals

  3. Anything else...?

A few example of what I want to "catch":

(r/refined s/Str (r/Greater 0))
(r/refined [s/Str] (r/First (r/Greater 0)))
(r/And (r/Greater 0) r/NonEmpty))
(r/refined (r/refined [s/Str] r/NonEmpty) (r/Greater 0))
(r/refined (r/NonEmptyListOf s/Str) (r/First (r/Greater 0)))

More on "dependent types":

(r/And (r/Greater 0) (r/Less 0)) ;; (r/Equal 0)
(r/And (r/Greater 0) (r/Less -1)) ;; error
(r/Or (r/Greater 0) (r/Greater 10)) ;; (r/Greater 0)
(r/refined NonEmptyStr NonEmpty) ;; NonEmptyStr

Neat and very nice to have:

(r/refined [s/Str] (Less 0)) ;; error suggesting to use (On count (Less 0))
(r/refined [s/Str] (On count NonEmpty)) ;; error becuase `count` returns to numeric
(r/refined double (On count NonEmpty)) ;; error becuase `count` does not accept double
@gsnewmark
Copy link
Member

gsnewmark commented Jun 26, 2018

(r/refined s/Num (r/StartsWith "1")) ; error

This one is probably too complex/specific (r/refined r/ASCIILetterChar (r/Includes "ї")) ; error

@kachayev
Copy link
Contributor Author

kachayev commented Jun 26, 2018

@gsnewmark Even more specific

(r/refined (r/BoundedSizeStr 1 5) (r/Includes "thisiswaytoolong")) 

@kachayev
Copy link
Contributor Author

I've started work on this here

There's an interesting question: should we always treat Equal as a numerical predicate? Or derive from the type of the value given? @gsnewmark @serzh Any thoughts on this?

@gsnewmark
Copy link
Member

@kachayev why numerical? I prefer deriving it from the value, because nothing in it is specific to numbers.
We need something like this http://hackage.haskell.org/package/base-4.11.1.0/docs/Data-Eq.html 🙈 🙃

@kachayev
Copy link
Contributor Author

kachayev commented Jun 27, 2018

@gsnewmark Because it's easier to reason about when it's predictable. We use = now, which might be not the best fit for your understanding of "equality". If we keep this straightforward using Less, Greater, Equal are of the same kind... it might help.

@gsnewmark
Copy link
Member

🤷‍♀️ what if I want to check string for equality?

@gsnewmark
Copy link
Member

Let's rename it to something like NumericEqual then

@serzh
Copy link
Contributor

serzh commented Jun 27, 2018 via email

@kachayev
Copy link
Contributor Author

kachayev commented Jun 27, 2018

You still have (s/eq _) and #(= _ %) or whatever. My concern is that Equal is positioned right now as a "companion" for Less, Greater, LessOrEqual, GreaterOrEqual. And for Less/Greater we except only numerical.

@serzh Deriving type from the value you're still able to catch (And (Equal 3) LowerCase) earlier.

@serzh
Copy link
Contributor

serzh commented Jun 27, 2018 via email

@serzh
Copy link
Contributor

serzh commented Jun 29, 2018

@kachayev Can we have a separate exception for that type of error, instead of generic j.l.IllegalArgumentException?

@kachayev
Copy link
Contributor Author

@serzh Why?

@serzh
Copy link
Contributor

serzh commented Jun 29, 2018

I have a use case where I want to analyze that two schemas don't have (or do have) something in common.

@kachayev
Copy link
Contributor Author

😱

@kachayev
Copy link
Contributor Author

For example? I didn't quite get that.

@serzh
Copy link
Contributor

serzh commented Jun 30, 2018

Well, never mind, I just understant that it has to be proven that to types does'nt have anything in common. I have some ideas on bidrectional programming, and I need this type of check to be sure that if is bidrectional

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants