Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove the tree-only --> overload #80

Closed
neilpa opened this issue Apr 5, 2015 · 4 comments
Closed

Remove the tree-only --> overload #80

neilpa opened this issue Apr 5, 2015 · 4 comments

Comments

@neilpa
Copy link
Contributor

neilpa commented Apr 5, 2015

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 robrix added the question label Apr 5, 2015
@robrix
Copy link
Owner

robrix commented Apr 5, 2015

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
Copy link
Contributor Author

neilpa commented Apr 5, 2015

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
Copy link
Contributor Author

neilpa commented Apr 5, 2015

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
Copy link
Owner

robrix commented Apr 5, 2015

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

@robrix robrix changed the title Mapping operator ambiguity Remove the tree-only --> overload Apr 5, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants