elm / error-message-catalog Goto Github PK

View Code? Open in Web Editor NEW

173.0 173.0 17.0 14 KB

A catalog of broken Elm programs / data to improve error messages

License: BSD 3-Clause "New" or "Revised" License

Elm 100.00%

elm

error-message-catalog's People

Contributors

Stargazers

Watchers

Forkers

jadski arsatiki robertjlooby rhaps0dy berry rluiten roman andybalaam gunnarahlberg mikaelmayer neuroradiology pa1234567 sharma7n forkkit niksilver td5 seanwallawalla-forks

error-message-catalog's Issues

Mismatch parenthesis

import Html exposing (text)

(

main =
  text "Hello, World!"

The current error message doesn't mark the parenthesis at line 3.

-- SYNTAX PROBLEM ----------------------------------------------------
I ran into something unexpected when parsing your code!

5| main =

I am looking for one of the following things:

    whitespace

weird syntax error message in repl

> [1,2] ++ case True of
## ERRORS in repl-temp-000.elm #################################################

-- SYNTAX PROBLEM -------------------------------------------- repl-temp-000.elm

I ran into something unexpected when parsing your code!

6| tsol = ()
   ^
I am looking for one of the following things:

    whitespace

The weird thing being tsol = ()

type mismatch highlights an unhelpful expression (List.foldl Array.append)

In the following example, the mistake is that Array.push should be used instead of Array.append:

import Graphics.Element exposing (show)
import Array

main = show <| List.foldl Array.append Array.empty [1,2,3]

The current error message is not helpful:

-- TYPE MISMATCH ---------------------------------------------------- Error2.elm

This argument is causing a type mismatch.

4|                List.foldl Array.append Array.empty [1,2,3]
                                                      ^^^^^^^
To be more specific, type inference is leading to a conflict between this type:

    Array.Array a

and this type:

    number

A more helpful message would show that [1,2,3] and Array.append together are causing the mismatch. It would also be helpful to see the full type List (Array.Array a) and List number (see #10). It would also be helpful to see the full type of Array.append as resolved in this context (a mismatch between number -> Array.Array a -> Array.Array a and Array.Array a -> Array.Array a -> Array.Array a.

differentiate annotation errors from other type inference errors

Given this abbreviated code with a wrong type annotation on the update function

update: Action -> Model -> (Model, Effects)    
update action model =  ...

app = StartApp.start { init = initialModel, update = update, view = myview, inputs = [] }  

main = app.html

the current compiler (0.15.1) yields these error messages

Warning: ## ERRORS in src/index.elm #####################################################

-- TYPE MISMATCH ------------------------------------------------- src/index.elm

The 1st argument to function `start` has an unexpected type.

42|       StartApp.start
43|>    { init = initialModel
44|>    , update = update
45|>    , view = myview
46|>    , inputs = []
47|>    }

As I infer the type of values flowing through your program, I see a conflict
between these two types:

    Effects Action

    Effects


-- TYPE MISMATCH ------------------------------------------------- src/index.elm

The type annotation for `update` does not match its definition.

24| update: Action -> Model -> (Model, Effects)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
As I infer the type of values flowing through your program, I see a conflict
between these two types:

    Effects

    Effects Action Use --force to continue.

Aborted due to warnings.

The first error message bothers me. I do kind of understand why it's there (there is a type mismatch), but the error message is not helping.

So I wonder if it would be a good idea to let the compiler report type annotation mismatches only, until there are no more annotation errors. And only report other type errors in the absence of annotation errors.

Trying to update a record with =

Here's a mistake I've made before: accidentally using = in a record update when I meant <-

record1 : { foo : String, bar : String }
record1 = { foo = "bar", bar = "baz" }

record2 : { foo : String, bar : String }
record2 = { record1 | foo = "baz" } -- whoops!

This yields the following type mismatch:

The type annotation for 'record2' does not match its definition.

record2 : { foo : String, bar : String }

To be more specific, type inference is leading to a conflict between this type:

    { bar : String, foo : String }

and this type:

    { bar : String, foo : String, foo : String }

With the current error message, it took me a bit to figure out what I'd done. ("Why is it making two foo fields? How is that even possible? What's going on here?")

It seems like whenever you get this type error, and the desired record type contains duplicate fields (in this case two entries for foo : String), this would be a great time for a helpful suggestion like so:

Did you mean to use `foo <-` instead of `foo =` in your record update?

failing at string concatenation could have its own error message

When I try to concatenate strings with + it says

-- TYPE MISMATCH -------------------------------------------------- Repotron.elm

The left argument of (+) is causing a type mismatch.

22|                "Name: " + repo.name)
                   ^^^^^^^^
As I infer the type of values flowing through your program, I see a conflict
between these two types:

    number

    String


Detected errors in 1 module.

which is true.
And, it would be super nice if it asked me whether I meant ++, because I spent several minutes looking up how to do string concatenation because I forgot.

Better error when applying a non-function

If you try to apply a value, like 2 3, you get this error message:

This function is expecting 0 argument, but was given 1.

3|   2 3
       ^

Let's leapfrog over how argument should be plural and talk about functions of zero arguments. To the compiler, yes definitions are just degenerate functions. But a better error message might be,

This value is not a function, but was given 1 argument.

Although it's less of a concern to me, the ^ points to the argument, but the line above it talks about the function. So ideally it would be 2 that is underlined.

The error takes a slightly different form when the 'function' is named.

>> e "to the i theta"

Function `e` is expecting 0 argument, but was given 1.

3|   e "to the i theta"
       ^^^^^^^^^^^^^^^^

It would be nice if the compiler didn't lie about e being a function. Again the argument is highlighted, but because the function is named, there's less confusion.

Implementing a fix should be a fairly simple check for zero.

Saying "type" instead of "type alias" could use a better clue

This morning, I declared a useless type when I meant type alias. Details, including code and the compiler output, in this gist.

Does it even make sense to say:

type Action = SomeOtherComponent.Action

I don't think so. I wish it would say, "Yo, that doesn't make sense. Did you mean 'type alias' ? " instead of "conflicting types ..." later on.

Consulted with Richard, he said this surprises him, so I don't feel bad for being hugely frustrated and stymied by it.

Confusing record type error

I just came across this error:

-- TYPE MISMATCH -------------------------------- ./elmsrc/Comp/NewCrossover.elm

The 1st argument to function `inputInt'` has an unexpected type.

82|           inputInt'
83|>            { class = "form-control"
84|>            , name = "rail-dist"
85|>            , placeholder = Just "Spurweite in mm"
86|>            , value = m.railDist
87|>            , min = 0
88|>            , max = 2000
89|>            , step = 5
90|>            , update =
91|>                { fieldUpdate
92|>                    | onInput <-
93|>                        Just (\val ->
94|>                            Just (Signal.message addr (SetRailDist val))
95|>                        )
96|>                }
97|>            }

As I infer the type of values flowing through your program, I see a conflict
between these two types:

    Maybe Int

    number

The type error does not make it clear what went wrong. For example I set min = 0, but the type of min is Maybe Int. The expected error should contain something like Line 87, field min.

errors regarding nested types lack context

In this example:

foo : List (List String) -> Int
foo _ = 0

bar = foo [""]

The following error is produced:

-- TYPE MISMATCH -------------------------------------------------------------- 

This argument is causing a type mismatch.

3| 
4|        foo [""]
5|            ^^^^

To be more specific, as I infer all the types, I am seeing a conflict between
this type:

    List String

and this type:

    String

This message is confusing because the underlined code [""] is of type List String, which makes the error seem to say that there is something of type String that doesn't match, but actually it is List (List String) that doesn't match.

A more helpful error would say that there is a conflict between types List (List String) and List String. (Another alternative, although IMO less-helpful, would be to underline only "" in the code snippet instead of [""].

Improve compiler warning when trying to mutate modules

-- SYNTAX PROBLEM -------------------------------------------- repl-temp-000.elm

I ran into something unexpected when parsing your code!

4|   Mymodule.value = "trying to change this"
                    ^
I am looking for one of the following things:

    end of input
    whitespace

This error message could be improved for people who think modules are mutable.

Consider qualifying labels on simple Type errors

Background

Coming from an untyped background, while I learn Elm I see messages regarding type mismatches quite a bit. But still, in the error text, I can never recall which is the expected type and which is the offending type. IKR.

Suggestion

Revise these labels to evoke test assertions. That is, the type checker might inform

"I expected a type of Int, but your program uses a Float".

Even such a small change would greatly impress anyone assessing the language as being worthy of a "learning-time" investment.

A visual is attached.

When port JS functions throw, Elm reports "notify called synchronously"

To reproduce:

Make an outbound port
Subscribe to it in JS
Have the JS callback that handles the subscription throw an exception.

You'll get this error from Elm:

The notify function has been called synchronously! This can lead to frames being dropped. Definitely report this to <https://github.com/elm-lang/Elm/issues>

This is confusing because it sounds like there's been some sort of crazy Elm bug...but in reality, it's just a garden variety JS exception.

In an ideal world, Elm would catch the exception and log what port caused it, so it would be easier to track down.

Barring that, it would be nicer to just have a message that didn't lead me down the path of thinking my Elm code was broken (or, worse, that the Elm compiler was broken) when in fact the only issue was that my JS code was broken!

Incorrect indentation error message for conditionals

The following compiles successfully:

module Main where

one = if True then 1
              else 0

If you delete the indentation on the last line, you get:

module Main where

one = if True then 1
else 0

## ERRORS in Main.elm ##########################################################

-- SYNTAX PROBLEM ----------------------------------------------------- Main.elm

I ran into something unexpected when parsing your code!

4| else 0
   ^
I am looking for one of the following things:

    an 'else' branch
    whitespace

As reported in elm-lang/elm-platform#16, this situation came up when someone was working through a tutorial on conditionals.

The current message seems confusing because it points to the word else and says that this is invalid, but an 'else' branch would have been acceptable.

show types near the type error

In this example:

import Html

type Action = Change Float

init = { f = 2.5 }
update (Change f) c = { c | f <- f }
render c = toString c |> Html.text

mbox = Signal.mailbox 2.5
actions = Signal.map Change mbox.signal
model = Signal.foldp update init
main = model |> Signal.map render

In this case, the problem is that I forgot to pass actions as the last argument on line 11.

The following error is produced:

-- TYPE MISMATCH -------------------------------------------------------------- 

The right argument of (|>) is causing a type mismatch.

11| 
12|        model |> Signal.map render
13|                 ^^^^^^^^^^^^^^^^^

To be more specific, as I infer all the types, I am seeing a conflict between
this type:

    Signal.Signal Main.Action -> Signal.Signal { f : Float }

and this type:

    Signal.Signal a

The error could be improved by stating that model is the thing of type Signal.Signal Main.Action -> Signal.Signal { f : Float }

@docs to undefined name gives long unhelpful error message

The driving real-life example is signal-extra 5.1.1, which gives:

-- UNDEFINED DOCUMENTATION ------------------------------ ./src/Signal/Extra.elm

Your module documentation includes `filterMap` which is not exported.

 2|>{-| Utility functions that aren't in the `Signal` module from
 3|>`elm-lang/core`. 
 4|>
 5|># Flipped fancy map
 6|>@docs (~>)
 7|>
 8|># Zipping and unzipping
 9|>For those too lazy to write a record or union type.  
10|>@docs zip, zip3, zip4, unzip, unzip3, unzip4
11|>
12|># Stateful
13|>@docs foldp', foldps, foldps', runBuffer, runBuffer', delayRound
14|>
15|># Switching
16|>@docs switchWhen,switchSample
17|>
18|># Filters
19|>@docs keepIf,keepWhen,sampleWhen,keepThen,keepWhenI,filter,filterMap
20|>
21|># Combining
22|>@docs fairMerge, combine, mapMany, applyMany
23|>-}

Is it misspelled? Should it be exported?

The value filterMap was removed in a previous version along with the documentation and the export, but the name in the @docs was mistakenly left in.

This message is too long, and the hints are not exactly describing the situation.

Try to be more precise when type mismatches occur

I don't know how unification works exactly, so this may be too much to ask. But, say you take this example:

x = 1
y = "hello"

z = x + y

which yields this error message:

-- TYPE MISMATCH -------------------------------------------------------------- 

This expression is triggering a type mismatch.

3| 
4| z = x + y
5|     ^^^^^

To be more specific, as I infer all the types, I am seeing a conflict between
this type:

   number

and this type:

   String

which is a great error message. But is it possible to actually tell which of x or y is the number or the string. Like, say something like:

-- TYPE MISMATCH -------------------------------------------------------------- 

This expression is triggering a type mismatch.

3| 
4| z = x + y
5|     ^^^^^

It would seem that you called

(+) : number -> number -> number

with 

x : number

and 

y : String

Special error when insufficiently general annotation is just lowercase

A person on the list ran into this problem.

The type annotation for `start` does not match its definition.

15| start : Config model action -> Signal Html
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Could not unify user provided type variable `action`. The most likely cases are:

  1. The type you wrote down is too general. It says any type can go through
     but in fact only a certain type can.
  2. A type variable is probably being shared between two type annotations.
     They are treated as different things in the current implementation, so
     Try commenting out some type annotations and see what happens.

As I infer the type of values flowing through your program, I see a conflict
between these two types:

    action

    Action

In the special case where the two types differ only by capitalization, it would be nice to provide a more specific error message. Here's a draft.

The type annotation for `start` does not match its definition.

15| start : Config model action -> Signal Html
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You provided type variable `action`, but I infer the type `Action`. Try
fixing the capitalization.

Since we'll only show the error when one possible type is capitalized and the other isn't, filling in the blanks shouldn't be hard.

Output Conciseness

Moving this here from #41

This is not a confusing error message, per say, but it does feel like it could be nicer with a bit of trimming and rearranging:

rtfeldman$ elm make ConciseErrors.elm

## ERRORS in ConciseErrors.elm #################################################

-- ERROR: TYPE MISMATCH --------------------------------------------- ConciseErrors.elm

The 1st argument to function `view` has an unexpected type.

8|        view { username = "", password = "" }
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Looks like a record is missing the field `errors`

As I infer the types of values flowing through your program, I see a conflict
between these two types:

    { b |
        errors : { a | password : String, username : String },
        password : String,
        username : String
        }

    { password : String, username : String }


Detected errors in 1 module. 
rtfeldman$

Based on how I use compiler output, I'd make 3 changes to this message:

"Bottom-line it for me" by putting the most helpful message first, namely Looks like a record is missing the field 'errors'
Cut the ### ERRORS ##### line - all I ever look at are the -- TYPE MISMATCH ----- lines anyway.
Cut Detected errors in 1 module. - this has never been useful to me; seems like more of a candidate for a hypothetical elm-make -v or something.

rtfeldman$ elm make ConciseErrors.elm

-- ERROR: TYPE MISMATCH --------------------------------------------- ConciseErrors.elm

Looks like a record is missing the field `errors`

8|        view { username = "", password = "" }
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The 1st argument to function `view` has an unexpected type. I see a conflict
between these two types:

    { b |
        errors : { a | password : String, username : String },
        password : String,
        username : String
        }

    { password : String, username : String }

rtfeldman$

Trying to use single quotes for strings

Since in JavaScript single quotes work the same way as double quotes, a JS programmer might reflexively try to write the following:

str = 'foo'

Currently this yields the following fairly unhelpful syntax error:

I ran into something unexpected when parsing your code!

1| str = 'foo'
I am looking for one of the following things:

    a closing '''

It would be better if it explained that in Elm, ' is used for single characters only, and " is required for multi-character Strings.

Error message reporting weird types in failed type inference

I noticed that the types in the error resulting from this code were strange.

import Random exposing (..)

perturb : Float -> Seed -> List Float -> (List Float, Seed)
perturb dx seed xs =
  [1.0]

I get the error:

The type annotation for `perturb` does not match its definition.

3| perturb : Float -> Seed -> List Float -> (List Float, Seed)
As I infer the type of values flowing through your program, I see a conflict
between these two types:

    (List Float)

    List

And see the types (List Float) and List, when I should see (List Float, Seed) and List Float

Tab characters disallowed

The following contains no tab characters and compiles successfully:

module Main where

one = if True then 1
              else 0

If you replace any of the spaces before else with a tab character (\t), you get:

## ERRORS in Main.elm ##########################################################

-- SYNTAX PROBLEM ----------------------------------------------------- Main.elm

I ran into something unexpected when parsing your code!

4|              else 0
   ^
I am looking for one of the following things:

    an 'else' branch
    whitespace

This was originally reported in elm-lang/elm-platform#16.

This message could be improved by simply saying something like "You have a tab character here instead of a space. Tab characters are never allowed in Elm files, so please convert this file to use only spaces."

Types should be realiased in error messages

I am working through the Elm architecture tutorial and I was getting an unhelpful unification error message from the compiler. When reporting the expected types and the encountered type, they did not match what I expected from the code.

Here is the code which is causing the error:

type Action
  = Reset
  | AddCounter
  | RemoveCounter
  | Update CounterId Counter.Action

type alias CounterId = Int

type alias Model =
  { counters : List (CounterId, Counter.Model)
  , nextId : CounterId
  }

update : Action -> Model -> Model
update action model =
  case action of
    Update id act -> { model |
      counters <- (List.map
        (\(i, model) ->
          if | i == id -> Counter.update act model
             | otherwise -> model)
        model.counters)
      }

The lambda is returning a Counter.Model when it should be returning a (CounterId, Counter.Model), but the error message says:

-- TYPE MISMATCH ------------------------------------------- ././CounterList.elm

The 2nd branch of this `case` results in an unexpected type of value.

37|   case action of
38|     Reset -> init 0 3
39|     -- AddCounter -> { counters = (model.nextId, Counter.init 0)
40|     --               , nextId = model.nextId + 1
41|     --               }
42|     -- RemoveCounter -> case model.counters of
43|     --   hd::tl -> { counters = tl
44|     --             , nextId = model.nextId - 1
45|     --             }
46|     --   [] -> model
47|>    Update id act -> { model |
48|>      counters <- (List.map
49|>        (\(i, model) ->
50|>          if | i == id -> Counter.update act model
51|>             | otherwise -> model)
52|>        model.counters)
53|>      }

All branches should match so that no matter which one we take, we always get
back the same type of value.

As I infer the type of values flowing through your program, I see a conflict
between these two types:

    (Int, Int)

    Int

I don't understand why it is saying (Int, Int) and Int in the error message, instead of (CounterId, Counter.Model) and Counter.Model. Fixing the type of the lambda causes these messages to disappear.

P.S. There is also an error for the function not matching the signature which gives the same types:

-- TYPE MISMATCH ------------------------------------------- ././CounterList.elm

The type annotation for `update` does not match its definition.

35| update : Action -> Model -> Model
             ^^^^^^^^^^^^^^^^^^^^^^^^
As I infer the type of values flowing through your program, I see a conflict
between these two types:

    (Int, Int)

    Int

Allow trailing commas

I gotta say, I found the Elm coding style really weird at first. You definitely can get used to it, but it's still a source of frustration for me.

I totally understand the reason for the style though, and agree that "diff-ability" (?) and isolated changesets are very important real-world goals.

However, I think there's a simpler way to achieve that: allow trailing commas. This words well in Ruby:

things = [
  "one",
  "two",
  "three",
]

It could work equally well in Elm:

thing = {
  one = "one",
  two = "two",
  three = "three",
}

vs.

thing =
  { one = "one"
  , two = "two"
  , three = "three"
  }

I realize it may be a bit late to change the style, though.

Documentation comment before module definition leads to misleading error message

In elm 0.15.1 try and compile Test.elm

{-| xyz -}
module Test where
f = 5

It will produce the error

I ran into something unexpected when parsing your code!

2| module Test where
         ^
I am looking for one of the following things:

    a value definition

This is not an error in Elm 0.15

Compact error messages

This proposal is to have an option for more terse messages, specifically for people familiar with the elm-compiler error messages who want much smaller messages. I'm not lobbying to for changes in the current error messages!

Consider the following code snippet and corresponding error message in Elm 0.15.1.

import Html

view { username, password, errors } =
  let
    string = "" ++ errors.username ++ errors.password
  in Html.div [] []

main = view { username = "", password = "" }

## ERRORS in compact-errors.elm ################################################

-- TYPE MISMATCH -------------------------------------------- compact-errors.elm

The 1st argument to function `view` has an unexpected type.

8|        view { username = "", password = "" }
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Looks like a record is missing the field `errors`

As I infer the types of values flowing through your program, I see a conflict
between these two types:

    { b |
        errors : { a | password : String, username : String },
        password : String,
        username : String
        }

    { password : String, username : String }


Detected errors in 1 module.

I would prefer a shorter error message, as I'm already used to the kinds of error messages that I get from the compiler. I prefer these shorter messages so I can see the whole error message in a small terminal window, and can quickly scroll and glance over the errors.
For example, something like this:

## ERRORS in compact-errors.elm ################################################

-- TYPE MISMATCH -------------------------------------------- compact-errors.elm

Record is missing field `errors`
8|        view { username = "", password = "" }
    { b |
        errors : { a | password : String, username : String },
        password : String,
        username : String
        }
/=  { password : String, username : String }


Detected errors in 1 module.

(You can use colouring of the code to remove the need for ^^^^^, remove blank lines, only mention the hint. Perhaps there is more that can be done, but I don't want to degrade the information too much. )

Original issue on elm-compiler

Hanging `let` not looking for `in`

Due to my code style I occasionally get a hanging let and nondescript error. Minimal code:

main = let
  text message
message = "Hello, World!"

A hanging brace, bracket, or parens yields the same message. Expected error:

I am looking for one of the following things:
    {{whatever should close the block e.g. `in`}}

Actual error:

I am looking for one of the following things:
    whitespace

Missing module error message

This is something I ran into when doing the Elm architecture tutorial. I've removed all extraneous code, but this is something that actually took me a while to figure out.

You start writing your app: echo "import Html" > Main.elm.
You try to compile elm make Main.elm.

You become sad:

$ elm make Main.elm
Error when searching for modules imported by module 'Main':
    Could not find module 'Html'

Potential problems could be:
  * Misspelled the module name
  * Need to add a source directory or new dependency to elm-package.json

Suggesting that I do elm package install evancz/elm-html would have saved me quite some time. I initially assumed that the Html module would be part of the standard library (maybe it should?) and didn't know about the package system, nor that evancz/elm-html was the HTML library referenced in the tutorial.

Things that would've made me happy:

Having more stuff in the stdlib.
Searching the available packages automatically and suggesting ones that expose the missing module. Maybe rank by popularity.

Make argument type mismatch more precise

This is an issue following the comments on this issue: #3

The idea is that you want the error to tell you which argument in a function has been given an erroneous type (at least, a best guess).

For example,

f x y z = 
  x ++ y ++ z


x = "H"

y = "e"

z = 'l'

a = f x y z

Currently yields:

-- TYPE MISMATCH -------------------------------------------------------------- 

This expression is triggering a type mismatch.

10| 
11| a = f x y z
12|     ^^^^^

To be more specific, as I infer all the types, I am seeing a conflict between
this type:

    Char

and this type:

    String

But, ideally, you'd want something like:

-- TYPE MISMATCH -------------------------------------------------------------- 

This expression is triggering a type mismatch.

10| 
11| a = f x y z
12|          ^^^

It would seem that you called

f : appendable -> appendable -> appendable -> appendable

with

x : String (appendable)

y : String (appendable)

z : Char

@evancz, this is the case you said is significantly more difficult, but I've opened the issue here for future reference.

confusing type mismatch involving Tuple and List

In the following example:

accumulate : (a -> b -> b) -> b -> List a -> List b
accumulate fn init values =
    values
    |> List.foldl (\v (next,rest) -> (fn v next)::rest) (init,[init])
    |> snd

The errors produced, while pointing to the correct place, do not describe the error in a helpful way:

-- TYPE MISMATCH -------------------------------------------------------------- 

This argument is causing a type mismatch.

3| 
4|        List.foldl (\v (next,rest) -> (fn v next)::rest) (init,[init])
5|                                                          ^^^^^^^^^^^

To be more specific, as I infer all the types, I am seeing a conflict between
this type:

    List

and this type:

    (a)


-- TYPE MISMATCH -------------------------------------------------------------- 

This argument is causing a type mismatch.

3| 
4|        List.foldl (\v (next,rest) -> (fn v next)::rest)
5|                                       ^^^^^^^^^^^^^^^^

To be more specific, as I infer all the types, I am seeing a conflict between
this type:

    (a)

and this type:

    List

Both the type (a) and the type List (without a parameter) are confusing--I'm not really sure what either refers to. More helpful in this case would be to say there is a conflict between types (b, List b) and List b.

Add aliasing error message

This code:

type alias Vector2 = 
  { x : Float
  , y : Float
  }

v : Vector2
v = 
  { x = 0 }

triggers this error message:

Type mismatch between the following types on line 9, column 5 to 10:

       Temp32703.Vector2

       { x : Float }

   It is related to the following expression:

       { x = 0 }

The whole "temp" part is super weird and not beginner friendly

Assigning to constants will give partial pattern error

From this comment in the issue elm-lang/elm-compiler#483:

-- PARTIAL PATTERN ----------------------------------------------------- tmp.elm

The pattern used here does not cover all possible values.

4│     3 = "wtf"
       ^
You need to account for the following values:

    <values besides 3>

Switch to a `case` expression to handle all possible patterns.

If you are seeing this error for the first time, check out these hints:
<https://github.com/elm-lang/elm-compiler/blob/0.16.0/hints/missing-patterns.md>
The recommendations about `Debug.crash` and wildcard patterns are important!

In cases where the pattern on the left-hand side of an assignment doesn't introduce new names, this error message can be much more specific. One shouldn't assign to constants!

"a record" vs "this record"

Now that compiler error messages provide such clear context, it feels weird that the "field missing" error doesn't acknowledge that you already know which record is the broken one.

The 1st argument to function `isOver50` has an unexpected type.

9|          isOver50 hermann
                     ^^^^^^^
Looks like a record is missing the field `age`

It seems like this would be nicer, assuming it wouldn't cause confusion in certain cases:

The 1st argument to function `isOver50` has an unexpected type.

9|          isOver50 hermann
                     ^^^^^^^
Looks like this record is missing the field `age`

See further discussion at elm/compiler#974

Accidental infix operator declaration

If you attempt to put an infix character (e.g. $) in the middle of a variable name, you get a surprising error:

It would be clearer if instead defining infix operators in this style required putting spaces on either side of the operator (and really, that might be a good rule for invoking infix operators as well) so that this can be reported as an illegal variable name.

Whitespace before type declaration

When I put a space accidentally before this line:

update : (innerAction -> aModel -> aModel) -> innerAction -> Model aModel -> Model aModel

then I get the compile error:

Detected errors in 1 module.
## ERRORS in InteractionCounter.elm ############################################
-- SYNTAX PROBLEM --------------------------------------- InteractionCounter.elm
I ran into something unexpected when parsing your code!
16|  update : (innerAction -> aModel -> aModel) -> innerAction -> Model aModel -> Model aModel
            ^
I am looking for one of the following things:
    end of input
    whitespace

... which confused me.

Wrong module name when bootstrapping Elm in HTML file

In HTML I want to bootstrap Elm this way:

    <script>
      Elm.fullscreen(Elm.TicketApps);
    </script>

but my module is called TicketApp (without the s).
When I try to load the page, it says:

Cannot read property 'make' of undefined


Open the developer console for more details.

(Opening the developer console doesn't really help at all.)
I propose adding checking for existence of the given module name in the init() function and outputting a more helpful error message, something along the lines of:

You wanted to embed Elm module "TicketApps".

I could not find any module of that name.

Maybe you meant:

    TicketApp
    TicketApp.Canvas
    Tests.TicketApp

Confusing comparable type error with number

The error message for a comparable with number is very confusing.

program:

f = 1 < "hello"

output:

The right argument of (<) is causing a type mismatch.

1| f = 1 < "hello"
As I infer the type of values flowing through your program, I see a conflict
between these two types:

    comparable

    String

Which is confusing because String is a comparable. If the number is instead an Int or Float you get a much clearer error message.

REPL error message, trying to get type of Html.div

$ elm repl
Elm REPL 0.4.2 (Elm Platform 0.15.1)
  See usage examples at <https://github.com/elm-lang/elm-repl>
  Type :help for help, :exit to exit
> import Html
> Html.div
ReferenceError: navigator is not defined

Maybe I can't do things with Html in the repl?

Mismatched type annotations hide quality error messages

I've made this mistake many times, but it only just occurred to me what the common thread was between the errors.

Suppose I have this code:

brokenFunction : a -> String
brokenFunction foo =
    fourArgFunction 1 2 3

fourArgFunction : Int -> Int -> Int -> Int -> String
fourArgFunction one two three four =
    toString (one + two + three + four)

The error message I get is:

The type annotation for `brokenFunction` does not match its definition.

2| brokenFunction : a -> b -> String

As I infer the type of values flowing through your program, I see a conflict
between these two types:

    String

    Int -> String

The real problem, though, is that I've forgotten to pass a fourth argument to fourArgumentFunction.

This comes up a lot when I add an argument to a function, update some of its call sites, but then forget to update other call sites. I often end up confused because the error message mentions the caller but not the callee, so whenever I've made changes to both functions, the message leads me to presume one of my changes to the caller is the culprit, and I go down the wrong path.

A more helpful error message could notice the pattern of "caller was supposed to return foo but instead returned a -> foo as a result of a curried call to a function that takes a as its last argument" and point that out to me, e.g.

The type annotation for `brokenFunction` does not match its definition.

2| brokenFunction : a -> b -> String

As I infer the type of values flowing through your program, I see a conflict
between these two types:

    String

    Int -> String

Did you mean to call `fourArgFunction` with only 3 arguments?
It needs 4 arguments to be fully applied.

Obscure error for bad indentation on multi-line function

Perhaps related to #14.
New to the language. I could not find anything super definitive on the indentation sensitivity for function declarations. There are a few references to indentation sensitivity for specific areas of syntax, such as on the Elm Syntax page for Conditionals and Let Expressions.

Elm REPL 0.4.2 (Elm Platform 0.15.1)
  See usage examples at 
  Type :help for help, :exit to exit

With indentation:

> goodName name = \
|   name == "David"
 : String -> Bool

Without indentation:

> perfectName name = \
| name == "Dave"
## ERRORS in repl-temp-000.elm #################################################

-- SYNTAX PROBLEM -------------------------------------------- repl-temp-000.elm

I ran into something unexpected when parsing your code!

3|   perfectName name = 
                      ^
I am looking for one of the following things:

    end of input
    whitespace



>

Forgetting commas in lists, it doesn't suggest a comma

I often forget to put commas in lists. Because Clojure doesn't require commas, and neither do function parameters.
And then it gives me a type error, and ... I don't know whether it's possible, but it would be lovely if it suggested that maybe I need a comma.

Code here

Error:

-- TYPE MISMATCH ------------------------------------------------ src/Sydron.elm

Function `input` is expecting 2 arguments, but was given 8.

46|        Html.input [ Attr.placeholder "owner", Attr.id "repo-owner"] []
47|>       Html.input [ Attr.placeholder "repository", Attr.id "repo-name"] []
48|>       Html.button [ Attr.style [("background", "url(img/elm-button.jpg")]] []

As I infer the type of values flowing through your program, I see a conflict
between these two types:

    a -> b

    Html

A little more info would help me diagnose a parameter-type error.

With the code in this gist, I get an ordinary type error:

Detected errors in 1 module.
## ERRORS in OneBox.elm ########################################################
-- TYPE MISMATCH ---------------------------------------------------- OneBox.elm
The 1st argument to function `start` has an unexpected type.
6|        StartApp.start 
7|>  { model = Box.init 
8|>   , update = Box.update
9|>   , view = Box.view }
As I infer the type of values flowing through your program, I see a conflict
between these two types:
() -> ()
()

I don't know which type is which. (I also can't see here which piece of the record is the wrong type.)
If the error message printed the type signature of function start, that would help a lot!

Svg Inferred for Html

I was demoing Elm to a student and got confused by an error. Minimal code:

import Html exposing (p, text)
main = p
  text "Hello, World!"

Expected error:

As I infer the type of values flowing through your program, I see a conflict
between these two types:
    List Html.Html
    String

Actual error:

As I infer the type of values flowing through your program, I see a conflict
between these two types:
    List Svg.Svg
    String

Explicitly annotating main fixes one error but not another. I suspect there's an implicit import bungling inference.

Add recommendation for type vs. type alias

It's cool that the compiler recommends the use of types instead of type aliases when things get recursive, but I think that it would be cool if there was a recommendation that goes the other way.

For example:

type Vector = { x : Float, y : Float }

Yields:

-- SYNTAX PROBLEM ------------------------------------------------------------- 

I ran into something unexpected when parsing your code!

0| 
1| type Vector = { x : Float, y : Float }
2|               ^

I am looking for one of the following things:

   a constructor for a union type
   whitespace

Ideally, you'd like something to say:

-- SYNTAX PROBLEM ------------------------------------------------------------- 

I ran into something unexpected when parsing your code!

0| 
1| type Vector = { x : Float, y : Float }
2|               ^

Perhaps you have meant to create a type alias.

    type alias Vector = { x : Float, y : Float }

and then with an explanation of the difference between types and type aliases. This could be useful, especially for people coming from Haskell or beginners who still haven't grasped the difference between type and type alias

no line number given when EOF is reached with unbalanced parens

In this example

main = (

The following error message is produced:

-- SYNTAX PROBLEM ------------------------------------------------------------- 

I ran into something unexpected when parsing your code!


I am looking for one of the following things:

    whitespace

A more helpful message would point to the opening ( on line 1, or at least state that it reached the end of file while looking for whitespace.

type mismatches within if statements do not localize the error

For this example:

type alias Model = { i:Int, s:String, x:Int }

foo : String -> Float -> Float -> Model -> Model
foo s f1 f2 m =
    if | m.s == s ->
            { m
            | i <- 0
            , x <- round <| m.i * (f1-f2)
            }
       | otherwise -> m

The following error is not helpful enough:

-- TYPE MISMATCH -------------------------------------------------------------- 

This expression is triggering a type mismatch.

 4| 
 5|     if | m.s == s ->
 6|             { m
 7|             | i <- 0
 8|             , x <- round <| m.i * (f1-f2)
 9|             }
10|        | otherwise -> m
11| 

To be more specific, as I infer all the types, I am seeing a conflict between
this type:

    Int

and this type:

    Float

A better message would highlight the fact that the problem is with the expression m.i * (f1-f2) on line 8.

Get the typechecker to consider "not really rigid" type variables as not rigid

Namely this code:

f : a -> a
f x = 
  let 
      y : a
      y = x

  in y

triggers this error:

-- TYPE MISMATCH -------------------------------------------------------------- 

This expression is triggering a type mismatch.

Could not unify rigid type variable 'a'. The problem probably
relates to the type variable being shared between two type annotations.
Try commenting out some type annotations and see what happens.

2| 
3|   let 
4|       y : a
5|       y = x
6|       
7|   in y
8| 

To be more specific, as I infer all the types, I am seeing a conflict between
this type:

    a

and this type:

    a

I can hazard a guess why the typechecker considers this a type error (it considers the inner a to be a different a because of the different scope). But, if a beginner sees this, he/she will go: "??!!??? What do you mean a is not a??!!?? (insert favorite expletives)"

My intuition tells me that this would require a non-trivial modification to the type checker but it would be worth it. Especially for large functions that consist of multiple inner closures, trampolines, nested let-in expressions, etc... where you'd want to add the type annotations at that level too (not just at the outer level).

Warning for unused variables and types

i'm not sure if i'm in the right place because this issue suggests warning, not error ..

It would be nice if the compiler can warn for unused variables and unused types

Long records in error messages difficult to manually diff

Consider this code:

type alias Person =
  {
    firstName : String,
    lastName : String,

    hairColor : String,
    eyeColor : String,

    address : String,
    phoenNumber : String,
    email : String,

    pets : Int
  }

getFullName : Person -> String
getFullName person =
  person.firstName ++ " " ++ person.lastName

fullName =
  getFullName
    {
      firstName = "Sam",
      lastName = "Sample",

      hairColor = "Brown",
      eyeColor = "Brown",

      address = "1337 Elite st",
      phoneNumber = "867-5309",
      email = "[email protected]",

      pets = 2
    }

If you try to compile it, you get this type mismatch:

The 1st argument to function `getFullName` has an unexpected type.

21|   getFullName
22|>    {
23|>      firstName = "Sam",
24|>      lastName = "Sample",
25|>      
26|>      hairColor = "Brown",
27|>      eyeColor = "Brown",
28|>      
29|>      address = "1337 Elite st",
30|>      phoneNumber = "867-5309",
31|>      email = "[email protected]",
32|>      
33|>      pets = 2
34|>    }

As I infer the type of values flowing through your program, I see a conflict
between these two types:

    Person

    { address : String
    , email : String
    , eyeColor : String
    , firstName : String
    , hairColor : String
    , lastName : String
    , pets : Int
    , phoneNumber : String
    }

The underlying problem is a small typo: the definition of Person has the field listed as phoenNumber rather than phoneNumber. However, that is very difficult to deduce from this error message!

It would be really great if, when there's a type mismatch between two records, the compiler could diff the two records' fields and tell you what's different about them. In that case, this one could have been:

As I infer the type of values flowing through your program, I see a conflict
between these two types:

    Person

    { address : String
    , email : String
    , eyeColor : String
    , firstName : String
    , hairColor : String
    , lastName : String
    , pets : Int
    , phoneNumber : String
    }

Comparing the former to the latter...

  The following fields were missing:

    phoenNumber : String

  The following fields were added:

    phoneNumber : String

Instead of spending awhile hunting down the difference, this would have instantly directed me to the source of the problem.

This one would be a major time-saver for me, as I frequently work with records that have 10+ fields, and these errors don't seem to get significantly faster to debug with experience.

Inaccurate error: "qualifier not in scope" when it meant "Cannot find type"

when I accidentally declared a type as Attr.Attribute instead of Html.Attribute, I got this message:

-- NAMING ERROR ---------------------------------------------- src/RepoInput.elm
Cannot find type `Attr.Attribute`.
15| styles : Attr.Attribute
             ^^^^^^^^^^^^^^
The qualifier `Attr` is not in scope.

... which is inaccurate. Attr is in scope: import Html.Attributes as Attr and works elsewhere. Really, the Attribute type doesn't exist in that module.

Removing the Attr. qualifier gives the correct error message:

Cannot find type `Attribute`
15| styles : Attribute
             ^^^^^^^^^
Maybe you want one of the following?
    Html.Attribute

That should happen with the qualifier in place, as well.

Full code is here: https://github.com/jessitron/elm-sydron/blob/7722c0f3d29de4e5944d1019858877892529bff5/src/RepoInput.elm#L15