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.
The basic simple example
It works as expected and outputs error messages if the range limits of integer vales are exceeded.
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.
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).
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
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 ->
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.
Did some Googling and instead of using Parser.deadEndsToString, you could copy the
problemToString functions from the (5 year old) pull request that implements them.
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
Ok, I shall at this alternative as well.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.