Float literals will never be parsed

[Tientuine]

@Marist-CMPT331-TOPL/students

Integer and float literals can look similar. In fact, integer literals are effectively a subset of float literals.

For example, should the parser interpret 5 as an integer literal or a float literal? It makes sense that the parser should choose integer literal. What about 5.2? Is this a float literal or an integer literal following by the . operator? Clearly, the parser should treat this as a float literal.

However, the current implementation of the atom parser tries to parse integer literals first. Since it will succeed in parsing an integer 5 when it encounters the token 5.2, it will not parse it as a float. This is the wrong behavior. The atom parser should parse float literals first, only parsing integer literals if it didn't first parse a float.

IMPORTANT: It might seem like the solution is just a simple reordering of lines here, but there is one potential pitfall... When the re-ordered atom parser encounters 5, it will try to parse it as a float literal, and it will only fail when it sees that there is no decimal point after the digit. But by that point, the parser has already consumed the digit 5, so if we try to parse an integer literal we'll have nothing left of the token. The solution here is to try to parse the float literal - using the try function will effectively turn a parser into a look-ahead parser, meaning that if it fails then it will roll back and act like it didn't consume any characters of the token. To use the try function, just give it a regular, non-look-ahead parser - in other words, if p is a parser, then try p is a look-ahead version of that parser. (Note that here p may be a function or other expression that represents a parser.)

[Stubeans]

I'm curious why this doesn't work? Would I implement the try function here, or somewhere else? And then lets say I were to implement it here, how would I fix the precedence error between <|> and <$>? Do I convert to a <|> FloatLiteralExp >> float?

[Stubeans]

this is the only reference I see to p outside of the Parser, however I'm not entirely sure it refers to the parser. I tried putting a choice map here, as well as try methods but it doesn't seem to belong.