I aimed to create a parser getting the point (x,y) from the input string " (1.25, 2.50) "
The parsing result looks correct: Ok { x = 1.25, y = 2.5 }
However, this is not the record { x = 1.25, y = 2.5 } of alias type Point, I wanted.
Thus, I can’t get the co-ordinates x, y simply from the point record with parsedResult.x and parsedResult.y.
Further, I don’t understand, why the parsing result is of type Result (List Parser.DeadEnd) Point .
Why not just type Point ? What does actually Parser.DeadEnd mean? Is there something missing in my code?
Before I tried parser, I planned to use some usual string handling to get the the geo-location co-ordinates latitude and longitude for the given string “lat degree, lat minute, lon degree lon minute”.
So I made a rough code for that. It’s not ready for any real use. It should make more sense as a separate module.
Then I imagined, it should be better to do with a Parser library with error handling etc.
Point is a type alias. As far as the compiler is concerned, any record with that shape is interchangeable and anonymous. You’ve correctly used the Point constructor in your parser, but it doesn’t carry the name with it, just creates a record of that form. You could make a stronger type, but it won’t be just point.x to access fields.
The Result type is so you can report errors, for the base parser you can use Parser.deadEndsToString for debugging, but it’s not great for user visible errors. Like any Result, you can either case off of Ok/Err or use something like Result.withDefault (Point 0 0) once you’ve handled errors.
Your Ellie has a certain beauty to it already, and passing in an invalid string to your parser might show you why.
A parser returns a result because it can fail. Combine this with your “Expected” and you can produce beautiful error messages explaining why the parsing failed and maybe even ways to fix the input.
Thanks for helping! I agree, testing with different invalid strings gives good hints for necessary error handling. I see my latest version has it very little yet.
After reading this, I looked a little deeper into why it returns a List of DeadEnd instead of a single DeadEnd. I skimmed the implementation of oneOf, and I believe it’s a list because it’s possible to use oneOf along with the backtracking enabling functionality to allow the parsing to reach multiple dead ends.