use of enums when parsing

[mor1]

it would be nice if, given an enum of the form

cenum foo {
  bar1 = v1;
  bar2 = v2
} as enumtype

...rather than foo option the parser return something like foo orError where orError would be defined something like

type 'a orError = 
  | Ok of 'a
  | Err of enumtype

the use case is when parsing data -- it's nice to lift to a proper type as early as possible but retain the ability to output some sensible debug info when there's a parse error.

[avsm]

Agreed...option returns on error should basically be considered harmful. Also Or_error.t in Core is a good example of what we should aim for.

On 15 Sep 2013, at 15:12, Richard Mortier notifications@github.com wrote:

it would be nice if, given an enum of the form

cenum foo { bar1 = v1; bar2 = v2 } as enumtype ...rather than foo option the parser return something like foo orError where orError would be defined something like

type 'a orError = | Ok of 'a | Err of enumtype the use case is when parsing data -- it's nice to lift to a proper type as early as possible but retain the ability to output some sensible debug info when there's a parse error.

— Reply to this email directly or view it on GitHub.

[avsm]

I guess it's ok to break compatibility here, since we're still < 1.0.0.

[avsm]

I took a look at this, but it's not clear to me what enumType is here. Are you saying that you want to gather all the possible enumerations that have been defined, and to say which one raised an error? That should happen in the parser.

[mor1]

no, i'm saying that (following the example above) if you define an enum foo of type enumtype (uint8_t or whatever), then when the int_to_foo function would more usefully return foo orError rather than foo option where 'a orError is defined as above. ie., when the autogenerated function that converts from the raw input to the typed value is presented with a value outside the range of the enumeration, it's useful to know what that value is, not just that it was outside the range.

(and not force the error to be handled at that point but permit it to bubble up.)

[mor1]

ps. i can try to have a go at this this afternoon perhaps. i'm bored of proposalising at the moment. and it'll be an excuse to fail to understand camlp4 too.

[avsm]

Not going to do this for 1.0 since we have existing users. We can create a 1.2.x with interface-breaking changes.