Normalize all Elm keywords

[madsflensted]

Here is an update the normalizes all the Elm keywords, as listed in the Elm compilers Parser code.

I updated the unit tests to test all keywords, but I am not sure if I like this style, where the test and the code basically share the same data, and therefor testing the whole list bring little extra value over testing a single entry.

[dillonkearns]

@madsflensted fantastic, thank you so much for the PR! That’s fantastic that you linked to the Elm compiler section that includes the list of keywords 💯!

I won’t be at a computer until around Feb. 24 so I won’t be able to do a new release before then. I’ll review this a little more in-depth then. One small thing, though, would you mind running elm-format version 0.7.0-exp on this code to avoid whitespace diff noise?

[madsflensted]

@dillonkearns yes totally agree that was not a very nice PR diff-wize. I have now used the right elm-format version, and also changed the test code to allow for a more precise diff.

No pressure on the release, it is an easy thing to work around for me since I control the server side schema.

Thank you for a great library! I have stumbled on a few mental bumps getting started, I will try to share them on Slack when I have a bit of time.

[dillonkearns]

Hey @madsflensted thanks again for taking the lead on this! I really appreciate it 😄

I did a little experimentation and it appears that several of these are valid top-level identifiers. In particular, alias, left, right, non, effect, command, subscription, true, false, null. Here's an Ellie example that demonstrates that. Do you see any issue with treating these like any other word given that they compile as top-level identifiers?

[dillonkearns]

@madsflensted so it looks like some of these keywords are not reserved words, see Variable.hs#L64-L75. infix is the exception, it isn't listed as a reserved word (only a keyword, see https://en.wikipedia.org/wiki/Reserved_word), but the compiler gets confused when it is used as a top-level identifier so I added it to the list as well.

[dillonkearns]

I went ahead and merged it in, thanks again for the PR @madsflensted!

I agree with your point about the testing style, this article has a good way of looking at that idea (tl;dr: it's okay for your tests to have duplication, in fact if they don't then sometimes it's hard to be confident in them!): http://arlobelshee.com/wet-when-dry-doesnt-apply/. I removed the elmReservedWords from the public interface and added a test of just a subset of the keywords. You can see some of the commits if you're interested: dillonkearns/graphqelm@1a092d0...madsflensted-normalize-all-keywords

Thanks for the help! Let me know if you think anything here could be improved.

[madsflensted]

Sounds like some good choices, and thank you for the linked article.
Should normalization be mentioned in the Fields docs? or somewhere else?

[dillonkearns]

Should normalization be mentioned in the Fields docs? or somewhere else?

That's a great question, it does seem like that would be good to have it documented somewhere. I wonder if the README would be more accessible? And I could link to it in the field docs perhaps.

[dillonkearns]

@madsflensted I added a brief description of the normalization in the FAQ, and linked to the FAQ from the README.

Thanks again for your input on this!

[madsflensted]

Looking good! Keep up the great work on this package.