-
-
Notifications
You must be signed in to change notification settings - Fork 546
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: Getting rid of 'null' and "error" in canonical-data? #905
Comments
Okay, so I read this quote as possibly suggesting we do not test I have not read anything in this issue's description that suggests we need to remove the possibility of
And so they would. So, they translate the |
Indeed, there is only the mention of null as input, but not as output or in between. But doesn't this infer nearly the same issues for those languages? How could they expect a null if they don't have a null-concept of any sort? |
Using whatever equivalent concept exists in the target language. If there is a target language that has a problem translating I can start off with saying that in Haskell we will use the Maybe type, and in Rust we will use the Option type when there are outputs that were represented in JSON as So why don't we accept those types in our inputs as well? Well, why would we? The type system helps us prevent it. So no problems from either of those languages currently. Let's hear about any experiences with any other languages that have specific problems. |
But do you really want to only use a We do have the ability in many languages to express that we demand to get a string. If this string can be replaced by some
|
No we don't want to. So we won't. If
If I see
So, does it make sense to in JSON use both The last time I used this example in #336 (comment) I was trying to show people that this is insensible. In Haskell, are we expected to have So, in JSON I would probably recommend to just use Are there no other cases in which we might say "We expect no answer, but it's not an error"? If there are no other cases, sure, let's forbid |
I'd had represented it either as an empty result set/list or as a new ADT roughly But maybe I'm biased on this from an erlang/elixir thinking where we do not need to define static types but just use some tagged tuples. |
Reasonable if the function under test returns a list of all possibilities
Reasonable. If considering these three possibilities, would you think the target language's |
To be honest, I'd even prefer to completely get rid of the JSON data and define canonical data in a haskell-y or ML-y syntax. ADTs included, which would clearly define types for inputs and outputs in terms of some basetypes. An exercises implementor would then apply the target languages idioms to those types. During my studies we often used ADTs to “draft” data representation and a function type declaration in haskell style ( Later on we were able to use those drafts to actually define our system in one of the possible target languages. But there we all had lectures about haskell already, here I'm not sure if everyone could read and apply it, nor can I assume that everyone is willing to learn… Disclaimer: I really never liked JSON because of the |
Understandable. Until a possible day when we move away from JSON (I don't disagree with the proposal but I will say I can't spend my time to make it), I'm on board with declaring that I wonder if it is possible to have https://github.com/exercism/problem-specifications/blob/master/canonical-schema.json forbid nulls! |
OK, since your arguments are quite too technical for me to really comprehend in a single read, I'll try to summarize them:
|
@petertseng has convinced me, that having
I'm in favor of the error object (no statements in JSON as its not a programming language), but I suggest to leave the interpretation of how this has to be dealt with to the implementing language track, since there are many idioms to deal with errors. A language might choose to implement those error-objects as…
And even while I'm not in favor of testing invalid input for exercises which could easily avoided by replacing a string with an array of an enum type (most of the DNA exercises), I do see some room for invalid inputs in other exercises where not even haskells typesystem is suitable to safe you, eg: |
change 1.3.0 As proposed in #1313 #905 (comment) In contrast to the proposal in #336 (comment) Although -1 is a sentinel value, the sentinel value had been overloaded in this JSON file to mean two separate conditions: * "Can't make target" (ostensibly, we might be able to make the target with a different set of coins) * "Target is negative" (no matter what coins we provide, this target is always invalid) To make clear that these two conditions are different, we use an error object describing each. This error object was defined in #401 Note that this commit is not a decree that all languages must represent these conditions as errors; languages should continue to represent the conditions in the usual way for that language. It is simply a declaration that these two conditions bear enough consideration that we'll represent them with a different type and also clearly differentiate between the two. Closes #1313 Checks the related box in #1311
It seems we found quite a deep topic to talk about.
There have been some concerns that show, that the canonical data should not have
null
and the"expected": "error"
structures, because there are quite some inconsistent language concepts in the tracks.E.g. @NobbZ said in #902:
also @stevejb71 said the same independently here: #895 (comment)
So I have a feeling we have to purge these two concepts from the canonical data and from the schema.
I found "error" in the following exercises:
I found
null
in the following exercises:The text was updated successfully, but these errors were encountered: