-
Notifications
You must be signed in to change notification settings - Fork 2
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
Comments
This one is probably too complex/specific |
@gsnewmark Even more specific (r/refined (r/BoundedSizeStr 1 5) (r/Includes "thisiswaytoolong")) |
I've started work on this here There's an interesting question: should we always treat |
@kachayev why numerical? I prefer deriving it from the value, because nothing in it is specific to numbers. |
@gsnewmark Because it's easier to reason about when it's predictable. We use |
🤷♀️ what if I want to check string for equality? |
Let's rename it to something like |
Will we create “Equal” predicate for every type? Im not sure it’s a good idea. Why it can’t be polymorphic? In case of checking for “impossible” predicate it doesn’t matter, you just need to check other preds are satisfied with this value
(And (Equal 3) LowerCase)
(LowerCase 3) ; => not satisfied
… On Jun 27, 2018, at 19:52, Ivan Kryvoruchko ***@***.***> wrote:
Let's rename it to something like NumericEqual then
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
You still have @serzh Deriving type from the value you're still able to catch |
In that case just renaming will be sufficient 👍
… On Jun 27, 2018, at 20:20, Oleksii Kachaiev ***@***.***> wrote:
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.
@sergmarch Deriving type from the value you're still able catch (And (Equal 3) LowerCase) earlier.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@kachayev Can we have a separate exception for that type of error, instead of generic |
@serzh Why? |
I have a use case where I want to analyze that two schemas don't have (or do have) something in common. |
😱 |
For example? I didn't quite get that. |
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 |
That's a kinda tricky thing to do...
From "obvious" steps we can take:
Mark types & predicates as
:seq
,:num
and:string
and converge the predicates tree to the most "common" one. In case of mismatch show the errorFor ordering predicates, we can do basic checks with
:num
types using simple rules to deal with intervalsAnything else...?
A few example of what I want to "catch":
More on "dependent types":
Neat and very nice to have:
The text was updated successfully, but these errors were encountered: