[elm-discuss] [Feature] Ability to suppress some warnings (or don't generate them at all)

[Incomplete]

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.

[Jakub Hampl]

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.

Post by Incomplete
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.

[joseph ni]

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.

Post by Jakub Hampl
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.

Post by Incomplete
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.

[Incomplete]

Seems to be good approach, I'll use it for colors, since it's the major
pain; for others I'll just annotate them, (prefer zero-warning codes
whenever possible).

(Feel the same with white spaces, just changed from four-spaces-indentation
to two spaces).

Post by joseph ni
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.

Post by Jakub Hampl
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.

Post by Incomplete
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.

[joseph ni]

Elm's warnings seems to be fairly restricted to missing annotations or
unused imports, both of which is arguably trivial and doesn't affect the
program's maintainability in any meaningful way imo as the previous
commenter said.

Don't get me wrong about whitespaces, I love what elm-format does. It took
me a greater perspective to see it, but now I love the fact that I don't
care about what it does. Spaces, indentation, comments, ordering, enough
ppl have put their collective brain power into it, just check out the
issues list.

As for me, I'm just glad I don't have to sit through a 2hr meeting with a
10 member team on whether a anonymous function in js should have a space
before the bracket or whether commas should be on the end or begin the next
line or the use of semi-colons. Instead, I hit save, it formats and I can
get on with it.

Post by Incomplete
Seems to be good approach, I'll use it for colors, since it's the major
pain; for others I'll just annotate them, (prefer zero-warning codes
whenever possible).
(Feel the same with white spaces, just changed from
four-spaces-indentation to two spaces).

Post by joseph ni
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.

Post by Jakub Hampl
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.

Post by Incomplete
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 a topic in the
Google Groups "Elm Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/
topic/elm-discuss/n5TNa_PlRSg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.