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

type inference failures for rhs of ~> #123

Closed
kiritsuku opened this issue Dec 28, 2014 · 1 comment
Closed

type inference failures for rhs of ~> #123

kiritsuku opened this issue Dec 28, 2014 · 1 comment

Comments

@kiritsuku
Copy link

The following code compiles fine:

  def a: Rule1[Int] = ???
  def b: Rule1[Int] = ???
  def f = rule { a ~ b ~> { (a, b) => (a, b) match {
    case (a, b) => a+b
  }}}

But the following does not:

  def g = rule { a ~ b ~> {
    case (a, b) => a+b
  }}

The error is:

missing parameter type for expanded function
The argument types of an anonymous function must be fully known. (SLS 8.5) Expected type was: ?

I'm not sure if this is a bug in parboiled2 or in scalac but it is at least weird behavior.

It can become even worse:

  def f: Rule1[Int] = rule { a ~ b ~> { (a, b) => (a, b) match {
    case (a, b) => a+b
  }}}

By explicitly typing the type of f one gets the errors:

missing parameter type
missing parameter type

  def f: Rule1[Int] = rule { a ~ b ~> { (a, b) => (a, b) match {
                                         ^  ^
@sirthias
Copy link
Owner

sirthias commented Jan 2, 2015

I'm not sure if this is a bug in parboiled2 or in scalac but it is at least weird behavior.

What you are seeing is a limitation of the compiler's type inference logic.
The compiler cannot fully infer the type of the function if you use the case (a, b) => ... notation.
This has nothing to do with pb2.

By explicitly typing the type of f one gets the errors ...

Yes, this is a very weird compiler bug that we've also been seeing ourselves.
Sometimes adding a type annotation (the correct one!) triggers a compiler error.
There doesn't appear to be anything we can do from our side to fix this.
I guess #106 would be the only option.

As a general guideline we only attach explicit type annotations to rules where they are required due to recursion or where we really want to see them for documentation reasons.

@sirthias sirthias closed this as completed Jan 2, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants