Can you verify you have signed and submitted the contributor agreement at http://www.scala-lang.org/sites/default/files/contributor_agreement.pdf ?

jenkins job pr-scala-testsuite-linux-opt: Success - https://scala-webapps.epfl.ch/jenkins/job/pr-scala-testsuite-linux-opt/13/

Hi, I have submitted my contributor agreement.

Sorry about the turnaround speed. You're in!

I'm sorry for barging in this late (the ticket did not have a component, so it escaped my filters), but was any benchmarking done? It seems to me that this would make Parsers much slower, and it isn't exactly a paragon of speed to begin with.

It seems to me that, in the course of a normal parsing, for each option considered and rejected, the following trade off happens:

Previously: var compared against null.

Now: lazy val have its DynamicVariable obtained, and a new closure is instantiated to map the resulting Option, which is then getOrElse extracted against true.

Now, if benchmarks show the resulting performance is about the same, I'm all for this patch. Otherwise, why not just mark Parsers as not thread-safe, and turn JSON object into a class?

At the very least, we could drop the lazy. Why make something lazy when all but the most trivial parser will use it?

See comment at https://issues.scala-lang.org/browse/SI-4929 .

I think Parsers is thread-safe since Scala 2.10. Right? It's hard to know it in SI-4929 since it was not closed explicitly.

We encountered the memory leak issue mentioned in SI-4929, and plan to change our Parsers to object (apache/spark#8357). Just want to make sure it's thread-safe in Scala 2.10 and Scala 2.11.

Please open an issue at https://github.com/scala/scala-parser-combinators; the code no longer exists in this repo. Also, you have a better chance of getting expert help there.