Arguments received at the command line are always strings which usually need to be parsed into the appropriate types for use in the command line script. At the moment, every script would need to do this parsing (for instance, parsing a value as a number or as a date) independently, in an ad hoc way.
We could define a schema layer where, for instance, numeric flags needn't specify an implementation for the flag function, and instead use a (schema number) subform in place of the body, which would set the flag parameter to the value received from the command line cast as a number.
Similarly, other schemas to handle boilerplate parsing could be isodate (for dates provided in ISO format), currency (for e.g. dollar amounts that should use precision to 2 decimal places), vector, and other Racket types.
It should also be possible to specify a transformer for positional arguments, and ideally it should be possible to use schemas here as well. E.g. (program ([n "Number of entries" string->number]) ...) or (program ([n "number of entries" (schema number)]) ...)
It would also be good to support user-defined schemas for custom types.
Arguments received at the command line are always strings which usually need to be parsed into the appropriate types for use in the command line script. At the moment, every script would need to do this parsing (for instance, parsing a value as a number or as a date) independently, in an ad hoc way.
We could define a schema layer where, for instance, numeric flags needn't specify an implementation for the flag function, and instead use a
(schema number)subform in place of the body, which would set the flag parameter to the value received from the command line cast as a number.Similarly, other schemas to handle boilerplate parsing could be
isodate(for dates provided in ISO format),currency(for e.g. dollar amounts that should use precision to 2 decimal places),vector, and other Racket types.It should also be possible to specify a transformer for positional arguments, and ideally it should be possible to use schemas here as well. E.g.
(program ([n "Number of entries" string->number]) ...)or(program ([n "number of entries" (schema number)]) ...)It would also be good to support user-defined schemas for custom types.