Feature request: period parsing

[jackfirth]

Frequently I wish to pass a time period as an argument to programs, either through command line flags or environment variables. While gregor has facilities for parsing times and dates, there's nothing to parse "12d" into (days 12). A parse-period function would suit my needs perfectly. It's easy enough to write myself, but this seems like something that gregor should set a standard for.

[97jaz]

Are you thinking ISO 8601 duration syntax?

[jackfirth]

I wasn't aware that existed but it seems to fit the bill perfectly.

[97jaz]

Hm, unfortunately, ISO 8601 durations have two undesirable qualities:

• Fractional values in the least significant component in any given period, including craziness like P2Y1.5M (well, the standard says, "If necessary for a particular application, the lowest order components may have a decimal fraction.").
• Sub-second precision only supported by the aforementioned fractional values, so that you wouldn't be able to choose your own units.

I'm inclined either:

• to support a variation on ISO 8601, where all component values are required to be integers, and the format is extended to allow milli-, mirco-, and nanoseconds; or
• to make up something new.

[97jaz]

Could also do what java.time does: allow fractions only in seconds and, I guess, treat fractional seconds as nanoseconds.

[97jaz]

Hey @jackfirth, Gregor raises an exception on parse failure (for dates, times, and the like). Period parsing should be consistent, of course, but in the new library, do you think it would be better to return #f on parse failure instead?

[jackfirth]

I think there's two solid approaches here:

1. Raise an exception on parse failure by default, but do what hash-ref does and allow passing an optional value-or-thunk that determines what to do on parse failure (see the failure-result/c contract)
2. Provide actual parser combinators using something like megaparsack instead of providing plain functions

I lean towards 1 but there are significant advantages to 2, such as making it easy to parse stuff that's embedded in more complex text that also requires parsing. You can always add parser combinators later though.

[97jaz]

hash-ref (and its like) is a kind of special case, though. Any value you choose as the default failure value could also be a successful result. A date or time parser, however, would never return #f on success, so I've been thinking of it more like string->number than hash-ref.

Eh... on the other hand, it is convenient to be able to provide your own failure value, even if there's no risk of ambiguity.

Yay for combinators, and higher-level parsing functions could be built on top of them.

[jackfirth]

That's a good point; I'm not really sure how to handle that. Raising a parse error with no option to change that behavior seems fine to me then. Combinators and first-class parsers would probably be the most appropriate way to let people control how parse failures are handled.