Why does the parser fail to output the error message?

Learn
1

This is probably a trivial issue for an experienced code writer but very frustrating to me as trying to solve it couple of days already.
.

  1. The basic simple example
    It works as expected and outputs error messages if the range limits of integer vales are exceeded.

  2. The case extended with elm browser.sandbox model
    The string to be parsed, is input by the user.
    This will too react to the exceeding of the ranges. However, it will output the zero location (lat 0, lon 0) as the Result.withDefault given by the parser instead of error message. It seems to skip using the function rangeProblem where the range limits are used.

2

Your rangeProblem functions are not being skipped - using Result.withDefault is throwing away your error messages. The reason it is working in the first example is because you are using Debug.toString to unwrap the result (you can see this happening when it says either “Ok” or “Err” after the “=>” in the output).

For Parser.run geoLocation v1 (Parser.run docs), the return type is of Result (List DeadEnd) GeoLocation. When you apply the result of this to Result.withDefault zero you are basically saying if the DeadEnd list has any errors, throw them away and replace the result with the zero geolocation.

You need to keep the results from the parser wrapped in the Result so that you can then access either the Geolocation or the errors with pattern matching like below.

getLocation inputS =
  case parseLocation inputS of
      Ok geolocation -> 
          "Latitude " ++ String.fromFloat (Tuple.first geolocation)
              ++ " Longitude " ++ String.fromFloat (Tuple.second geolocation)
      Err deadEnds ->
         Debug.toString  deadEnds

I’d recommend trying to write your first example without using Debug.toString. It should hopefully make what I’ve written above a little clearer.

Just watch out for using Parser.deadEndsToString because it is not implemented. You’ll need to map over the DeadEnds yourself.

1 Like
3

Did some Googling and instead of using Parser.deadEndsToString, you could copy the deadEndToString and problemToString functions from the (5 year old) pull request that implements them.

4

Thank you for your thorough explanation. I believe, this will help me a lot, how to go ahead. Yes, it’s a good idea, working at first with the simple example 1 and ofcourse, I must get rid of all Debug.toStringreferences in the final version.

I had read earlier the parser package docs but still missed the info, what to do with deadEnds.

5

Ok, I shall at this alternative as well.

6

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.