2

a try to add non-backtracking ~> and <~ to my parser based on RegexParsers.

RegexParsers implement implicit def literal(s: String): Parser[String] witch transphorm implicitly a String to a Parser[String]

now i add :

`object implicits{

       implicit class helper[T](parser  : Parser[T])  { 
           def ~>! [U](q: => Parser[U]): Parser[U] = parser ~! q ^^ {case a ~ b => b} named ("~>!") 
           def <~! [U](q: => Parser[U]): Parser[T] = parser ~! q ^^ {case a ~ b => a} named ("<~!") 
       }  
}

Witch is my implicit class.

But i seen a strange thing

def groupe : Parser[Group] =  "group(" ~>! identifier <~!  ")"

identifier is a Parser

Here i got an error when the string is pass in class parameter "group(" ~>! identifier because the implicit is not made and the compiler look for ~>! inside String.

but when it's passed in the method parameter identifier <~! ")" the String->Parser[String] implicit work.

Is it a Scala bug or i just miss something?

crak
  • 1,635
  • 2
  • 17
  • 33

1 Answers1

1

It isn't a bug. The problem is that to resolve ~>! on String the compiler would have to chain two implicit conversions: from String to Parser and from Parser to helper, which isn't allowed. So you need to add a direct conversion from String to helper:

implicit def stringToHelper(s: String): helper[String] = new helper(literal(s))

and also from Regex to helper if necessary.

Alexey Romanov
  • 167,066
  • 35
  • 309
  • 487
  • Ok thanks, and for the method parameter it's just one conversion. Why it's not allowed ? I feel that like a frustration. Add direct conversion work in this case but in the case where we don't know how many conversion there is it's will become a true problem. Thank for your answer znd sorry for my english – crak Apr 30 '14 at 13:32
  • See also: http://stackoverflow.com/questions/5332801/how-can-i-chain-implicits-in-scala – Peter Schmitz Apr 30 '14 at 16:36
  • Because if it was allowed 1) the compiler would take more times searching for implicits before stopping search and saying the method is really not available (and the build times are bad enough already); 2) you would often get ambiguous implicits more often. – Alexey Romanov May 01 '14 at 09:56