robrix / Madness

Recursive Descent Into Madness
MIT License
291 stars 17 forks source link

Remove the tree-only --> overload #80

Closed neilpa closed 9 years ago

neilpa commented 9 years ago

I was experimenting with Madness and found the overload of --> makes it a bit cumbersome when the mapping doesn't require the original input.

enum Value {
   case Null
   // ...
}

// None of these work do to "Ambiguous use of operator '-->'"
// let null = %"null" --> { Value.Null }
// let null = %"null" --> { _ in Value.Null }
// let null = %"null" --> { _ -> Value in Value.Null }

// Have to  specifying params
let null = %"null" --> { (_: String) in Value.Null }

Is there a better approach for this sort of thing when parsing keywords, etc.?

robrix commented 9 years ago

I’ve run into this, too—and IIRC this impedes the use of const(Value.Null) which would otherwise be what you mean.

Thus far my workaround has been { _, _, _ in … } — i.e. disambiguate to the 3-parameter version. { _ in … } doesn’t work because a single _ matches both the overload that does not receive the input and the overload that does (binding it as a 3-tuple). When I use the single parameter I will instead write { blah($0.0) }, for which the single-argument-as-3-tuple overload wins.

I can think of a couple of potential resolutions:

  1. Distinct operators for when you need the original input and when you don’t.
  2. Remove the no-input overload. Then you can use const(Value.Null) or { _ in Value.Null } without a problem.

What do you think?

neilpa commented 9 years ago

I would lean toward 2. It enables const and { _ in … } while single param usage still works with $0.0 as you said (or a less tersely { str, _, _ in … }).

I would also be hesitant to add more custom operators over the existing set. Instead I would favor a few extra named operator functions for common parsing patterns. Although those deserve a separate issue.

neilpa commented 9 years ago

Instead I would favor a few extra named operator functions for common parsing patterns. Although those deserve a separate issue.

I perused the open issues and you've already noted the pain points I've hit so far.

robrix commented 9 years ago

Yeah, I’m leaning that way myself. Going to change the title of this issue to capture that.