Grammar ambiguity in http-related rules

[SupraSummus]

I've noticed ambiguity in rule host. For input 1.1.1.1 it can parse it as IPv4address or as reg-name. I see two options how to disambiguate this:

• [more structural] make reg-name more strict
• [easier] get rid of IPv4address

[ocharles]

I don't see how we can get rid of IPv4, that would imply Dhall could only load things with DNS entries - no?

On Sun, 28 Oct 2018, 1:06 pm Jan Rydzewski, notifications@github.com wrote:

I've noticed ambiguity in rule host. For input 1.1.1.1 it can parse it as IPv4address or as reg-name. I see two options how to disambiguate this:

• [more structural] make reg-name more strict
• [easier] get rid of IPv4address

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dhall-lang/dhall-lang/issues/259, or mute the thread https://github.com/notifications/unsubscribe-auth/AABRjq9PJ6InumFAlTrHljDl_7bkJZQqks5upavagaJpZM4X99DF .

[SupraSummus]

I meant to get rid only of IPv4address grammar rule. In this case IP addresses can still be referenced, but grammar will parse them as reg-name and IP addresses has to be recognized on later stage (during AST postprocessing or evaluation - but this is an implementation detail).

[Gabriella439]

@SupraSummus: My preference is to keep the rule since those rules are lifted almost verbatim from the corresponding RFC . Instead, I think we should document in the grammar that the original RFC is ambiguous and specify that implementations should prefer parsing as IPv4Address over reg-name

[SupraSummus]

After reading grammar intro commentary carefully I noticed:

; Third, if there are multiple valid parses then prefer the first parse
; according to the ordering of alternatives. That is, the order of evaluation
; of the alternatives is left-to-right.

So the precedence is already specified.

I'm a little bit disappointed, because this means I can't take dhall.abnf as it is and make a GLR parser out of it.