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
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
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.
On 11 August 2017 at 11:36, Incomplete <incompl...@aixon.co> wrote:
> 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).
> On Friday, 11 August 2017 07:06:13 UTC+8, joseph ni wrote:
>> 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
>>> 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 a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> To unsubscribe from this group and all its topics, send an email to
> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "Elm
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.