For your CSS issue, you could put it in one function that took in a 
EveryDict and a typed color then give back the hex.
I'd prefer to keep colors together rather than split them out in 2 line 
functions with 2 spaces in between. Man elm-format goes to town with 
whitespaces, such generosity.

On Thursday, 10 August 2017 20:48:37 UTC+10, Jakub Hampl wrote:
> Warnings are really recommendations - if you choose to ignore them you'll 
> be fine. In elm, dangerous things are errors, not warnings. So I suggest if 
> you don't like the suggestions, simply stop using the --warn flag.
> On Wednesday, 9 August 2017 03:44:11 UTC+1, Incomplete wrote:
>> Whenever I `elm-make`, I give it the `--warn` option, however, this often 
>> makes the compiler generate warnings like "Top-level value `foo` does not 
>> have a type annotation.", if there are a lot of these, it would make the 
>> real warnings hard to notice.
>> Sometimes I deliberately omit type annotations for top level values, the 
>> reason is that these values are just some strings and numbers, (like CSS 
>> colors, some constants, etc.), or even initial model of type Model, there 
>> is really no need to annotate them, and annotating them would make the code 
>> looks uglier (because in the case of CSS colors, you often have several 
>> colors in succession, like `white=Css.hex "aabbcc" \n black=Css.hex 
>> "bbccdd" \n green=Css.hex "ccddee", if you annotate them, it becomes 
>> verbose).
>> As someone pointed out, a good consequence of type inference is that you 
>> don't have to write type declarations if you don't want to, however, I 
>> think Elm may have a different opinion on this.

You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to