Status of scala.util.parsing.json

[Alan Burlison]

According to https://issues.scala-lang.org/browse/SI-6571
scala.util.parsing.json is deprecated and is going to be removed, yet
https://issues.scala-lang.org/browse/SI-8863 says (quote) "The
deprecation warning on the standard library JSON parser is still
present, even though the JSON parser has been migrated out of the
standard library.", and indeed
https://github.com/scala/scala-parser-combinators/commit/ff68f4b322bdd8a0358666316a6494c8c93f62f4
removed the deprecation warnings. Colour me confused - what is the
actual status of these classes, because as of 2.11.4 I'm still getting
deprecation warnings.

Thanks,

--
Alan Burlison
--

[Simon Ochsenreither]

I have no idea why the deprecation warnings have been removed. The JSON example code _still_ doesn't belong in the library, imho.
Splitting scala.util.parsing from the standard library hasn't changed that.

[Jon Pretty]

Hi Simon,

I think Alan's saying the deprecation warnings have NOT been removed (despite that ticket indicating that I've "fixed" them). When you say "in the library", you mean the Parser Combinators library? I think that given that it's been moved out of the standard library, it needs to be *somewhere*. There's an argument for putting it into a separate end-of-life project, because continuing to use it isn't recommended, but is there enough distinction between the status of the JSON parser and the status of Parser Combinators to warrant the overhead of managing them as two separate projects? I don't see a lot of activity on the parser combinators library.

Of course, you'd be completely reasonable to disagree with my original premise that the JSON Parser has to go *somewhere*... ;)

My tenuous interest is that Rapture JSON[1] offers the Scala standard library JSON parser as one of about eight possible JSON backends, and there are builds for Scala 2.10 and 2.11 (the latter of which has a dependency on Parser Combinators, of course). Six months ago, I only supported this JSON parser and one other, but now I've got backends for Argonaut, Jackson, Play, Jawn, Lift, Spray and JSON4s, so there's no shortage of alternatives, and frankly you've got no good reason to use scala.util.parsing.JSON and every reason not to.

So, with that in mind, it seems reasonable that from now on I stop releasing it under Scala 2.11, and I deprecate it under the 2.10 builds. Any objections? No? Good. ;)

Cheers,

Jon

[1] https://github.com/propensive/rapture-json

On 30 November 2014 at 21:28, Simon Ochsenreither <simon.och...@gmail.com> wrote:

I have no idea why the deprecation warnings have been removed. The JSON example code _still_ doesn't belong in the library, imho.
Splitting scala.util.parsing from the standard library hasn't changed that.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Jon Pretty | @propensive

[Alan Burlison]

On 30/11/14 22:04, Jon Pretty wrote:

> I think Alan's saying the deprecation warnings have NOT been removed
> (despite that ticket indicating that I've "fixed" them).

They've been removed from the repo but are still present in current
2.10.x and 2.11.x releases.

> When you say "in
> the library", you mean the Parser Combinators library? I think that given
> that it's been moved out of the standard library, it needs to be
> *somewhere*. There's an argument for putting it into a separate end-of-life
> project, because continuing to use it isn't recommended, but is there
> enough distinction between the status of the JSON parser and the status of
> Parser Combinators to warrant the overhead of managing them as two separate
> projects? I don't see a lot of activity on the parser combinators library.

What? Are you saying that the parser combinators library is deprecated
as well and is going to be dropped? I know it's been split out into a
separate library but there are no deprecation warnings in it at the moment.

Why on earth would parser combinators be dropped altogether?

> Of course, you'd be completely reasonable to disagree with my original
> premise that the JSON Parser has to go *somewhere*... ;)
>
> My tenuous interest is that Rapture JSON[1] offers the Scala standard
> library JSON parser as one of about eight possible JSON backends, and there
> are builds for Scala 2.10 and 2.11 (the latter of which has a dependency on
> Parser Combinators, of course). Six months ago, I only supported this JSON
> parser and one other, but now I've got backends for Argonaut, Jackson,
> Play, Jawn, Lift, Spray and JSON4s, so there's no shortage of alternatives,
> and frankly you've got no good reason to use scala.util.parsing.JSON and
> every reason not to.

Why is there a reason not to use it? Personally I don't understand why
it was deprecated in the first place. It works and it's part of the
standard distro and for purposes such as mine (one-off parsing of JSON
config files on startup) it's perfectly adequate. Why am I being forced
to pull in yet another library?

> So, with that in mind, it seems reasonable that from now on I stop
> releasing it under Scala 2.11, and I deprecate it under the 2.10 builds.
> Any objections? No? Good. ;)

Releasing *what*? Your yet-another-Scala-JSON-thing or the JSON support
in the standard parser combinators library?

Is it just me that doesn't understand the rationale behind why and when
Scala features are being dropped?

--
Alan Burlison
--

[Simon Ochsenreither]

Why is there a reason not to use it? Personally I don't understand why
it was deprecated in the first place. It works and it's part of the
standard distro and for purposes such as mine (one-off parsing of JSON
config files on startup) it's perfectly adequate. Why am I being forced
to pull in yet another library?

Performance is pretty much disastrous. Parser combinators are not thread-safe. Error reporting/logging/debugging is not very good.
Using parser-combinators for one-off parsing will probably work without any issues, but you have to keep in mind that there are tons of people out there who see that it's in the official scala namespace and assume that is production-ready. A bit later, we all have to listen to rants about how Scala sucks because JSON parsing is several hundred times slower than other libraries.

Imho, it's better to not ship something in scala.* than to ship something with so many issues.

[Jon Pretty]

Hi Alan,

On 30 November 2014 at 22:21, Alan Burlison <alan.b...@gmail.com> wrote:

They've been removed from the repo but are still present in current 2.10.x and 2.11.x releases.

​So I guess my PR was merged, but no releases have been made since then...​

 

 

What? Are you saying that the parser combinators library is deprecated as well and is going to be dropped? I know it's been split out into a separate library but there are no deprecation warnings in it at the moment.

​No, it's not deprecated. It's in a separate library. But it may be "de-facto deprecated" if nobody maintains it.
 

Why on earth would parser combinators be dropped altogether?

​If nobody maintains them (because, for example, people prefer to use Parboiled). AIUI there's no commitment from Typesafe to support Parser Combinators, and even if it were, it's very unlikely to be a high priority.​ One motivation of moving it out of the main Scala project was so that it could develop and evolve independently, without being constrained by the release cycle of Scala.

 

Why is there a reason not to use it? Personally I don't understand why it was deprecated in the first place. It works and it's part of the standard distro and for purposes such as mine (one-off parsing of JSON config files on startup) it's perfectly adequate. Why am I being forced to pull in yet another library?

The main reason is that it's slow. I've not done any testing beyond noticing that code runs noticeably slower with scala.util.parsing.JSON, though 100x slower wouldn't surprise me, or the slowdown could be a function of the complexity of input (in which case it can be as slow as you like, as long as you give it sufficiently complex input)...

So, with that in mind, it seems reasonable that from now on I stop
releasing it under Scala 2.11, and I deprecate it under the 2.10 builds.
Any objections? No? Good. ;)

Releasing *what*? Your yet-another-Scala-JSON-thing or the JSON support in the standard parser combinators library?

​Sorry, I wasn't clear -- I was talking about releasing Rapture JSON, which was the only reason for getting involved here...​

 

Is it just me that doesn't understand the rationale behind why and when Scala features are being dropped?

​I'm not sure. There are many varied reasons for features being dropped. Often it's for good reasons like bad design, and other times it's because there just aren't enough people to work on it. In the case of Scala JSON, it's bad design.

Cheers,
Jon

--

Jon Pretty | @propensive

[Rex Kerr]

On Sun, Nov 30, 2014 at 2:21 PM, Alan Burlison <alan.b...@gmail.com> wrote:

Is it just me that doesn't understand the rationale behind why and when Scala features are being dropped?

Features that

  (1) Are not central to all use-cases for Scala

  (2) Require non-negligible domain-specific knowledge

  (3) Are inferior to existing libraries (incl. Java libraries, if the Scala version is really incomplete or poorly maintained)

are prime targets for being moved out of the main library and possibly dropped altogether.

In some cases a replacement will be added, if available; in others, the presumption is that you know how to pull in libraries with a minimum of effort.  (I agree that being library-happy can cause your project to have additional points of failure, and that it is desirable to have fewer rather than more, but it's also a very good idea to have the Scala team focus on the most central or not-otherwise-covered parts of Scala.)

  --Rex

 

[Alan Burlison]

On 30/11/14 22:38, Simon Ochsenreither wrote:

> Performance is pretty much disastrous. Parser combinators are not
> thread-safe. Error reporting/logging/debugging is not very good.
> Using parser-combinators for one-off parsing will probably work without any
> issues, but you have to keep in mind that there are tons of people out
> there who see that it's in the official scala namespace and assume that is
> production-ready. A bit later, we all have to listen to rants about how
> Scala sucks because JSON parsing is several hundred times slower than other
> libraries.

Those are all good reasons but I searched pretty hard to try to find why
the JSON code was being dropped before asking the question in the first
place and I came up blank.

And does that mean that Parser Combinators as a whole are going to be
dropped? The 12.11.1 release notes say that they are still going to be
maintained.

If things *are* going to be dropped then I suggest that needs to be
stated in the release notes as well as the scaladocs, the reasons need
to be explained and suitable alternatives need to be identified.
Expecting people to figure it out from JIRA & GitHub isn't reasonable.

> Imho, it's better to not ship something in scala.* than to ship something
> with so many issues.

IMHO it's better never to release such features at all, but if they have
been released then fixing them rather than dropping them would seem to
be a better course of action. In the case of parser combinators, at
least 3 of my Scala books have entire chapters on them, including
ProgInScala which is still the primary Scala textbook.

The Scala maintainers simply walking away from features that are
inconvenient to support and/or fix is going to do far more damage than
could ever be done by keeping them but documenting the issues.

If Scala is to be taken seriously then people need to be confident that
features that they use in good faith (e.g. because Scala textbooks tell
them to) don't totally suck (which is what you seem to be saying above)
and are going to be supported for a reasonable period, and if they *are*
dropped then there will be notification and explanation. In this case,
not one of those things seems to have happened.

Thanks for the answer and explanation, but I'm afraid it has just
increased my concerns about the "Enterprise Readiness" of Scala.

--
Alan Burlison
--

[Alan Burlison]

On 30/11/14 22:39, Jon Pretty wrote:

> ​If nobody maintains them (because, for example, people prefer to use
> Parboiled). AIUI there's no commitment from Typesafe to support Parser
> Combinators, and even if it were, it's very unlikely to be a high
> priority.​ One motivation of moving it out of the main Scala project was so
> that it could develop and evolve independently, without being constrained
> by the release cycle of Scala.

OK, so what's next for the chop then? As I said in my previous mail,
that sort of attitude to support is going to be a big issue for people
wanting to bet the farm on Scala.

> ​I'm not sure. There are many varied reasons for features being dropped.
> Often it's for good reasons like bad design, and other times it's because
> there just aren't enough people to work on it. In the case of Scala JSON,
> it's bad design.

As far as I can tell, Scala JSON is just a thin layer over the Parser
Combinators library. If that's correct then it means the Parser
Combinators library is a pile as well, correct?

--
Alan Burlison
--

[Alan Burlison]

On 30/11/14 22:52, Rex Kerr wrote:

> Features that
> (1) Are not central to all use-cases for Scala
> (2) Require non-negligible domain-specific knowledge
> (3) Are inferior to existing libraries (incl. Java libraries, if the
> Scala version is really incomplete or poorly maintained)
> are prime targets for being moved out of the main library and possibly
> dropped altogether.

Parser Combinators are commonly used by Scala textbooks as a "Look, see
how much clearer/simpler/better/cooler this is in Scala" example. Are
you saying those books are all wrong?

> In some cases a replacement will be added, if available; in others, the
> presumption is that you know how to pull in libraries with a minimum of
> effort. (I agree that being library-happy can cause your project to have
> additional points of failure, and that it is desirable to have fewer rather
> than more, but it's also a very good idea to have the Scala team focus on
> the most central or not-otherwise-covered parts of Scala.)

I haven't seen any recommendations for replacements for the Scala JSON
code, let alone Parser Combinators which it now seems I'm being told
should not be used either, even though they are not deprecated.

--
Alan Burlison
--

[Jason Zaugg]

Hi Alan,

scala-parser-combinators is not quite on its death bed! Factoring them out to a separate module has made it easier for a new maintainer to take over (thanks, Antoine Gourlay!). Incidentally, the same has happened for scala-swing.

We are very mindful of needlessly disrupting peoples investment in APIs that we have released. parser-combinators is only 1.7kloc, so even if we don't actively extend them, there isn't a strong argument for us to stop publishing them.

There are definitely caveats with regards to performance and thread safety, and perhaps we can do a better job at advertising these to people evaluating the library.

-jason

[Rex Kerr]

On Sun, Nov 30, 2014 at 4:54 PM, Alan Burlison <alan.b...@gmail.com> wrote:

On 30/11/14 22:52, Rex Kerr wrote:

Features that
   (1) Are not central to all use-cases for Scala
   (2) Require non-negligible domain-specific knowledge
   (3) Are inferior to existing libraries (incl. Java libraries, if the
Scala version is really incomplete or poorly maintained)
are prime targets for being moved out of the main library and possibly
dropped altogether.

Parser Combinators are commonly used by Scala textbooks as a "Look, see how much clearer/simpler/better/cooler this is in Scala" example. Are you saying those books are all wrong?

I didn't say anything about how clear, simple, better, or cool parser combinators are or are not.  I only implied that there are other libraries that are even better, at least at most things.  But parser combinators are not being dropped; they've just moved out of the main library jar.  (They're not problematic enough to warrant being dropped altogether, at least while there is no in-library replacement.)

 

In some cases a replacement will be added, if available; in others, the
presumption is that you know how to pull in libraries with a minimum of
effort.  (I agree that being library-happy can cause your project to have
additional points of failure, and that it is desirable to have fewer rather
than more, but it's also a very good idea to have the Scala team focus on
the most central or not-otherwise-covered parts of Scala.)

I haven't seen any recommendations for replacements for the Scala JSON code, let alone Parser Combinators which it now seems I'm being told should not be used either, even though they are not deprecated.

Jon Pretty listed seven alternatives in this very thread?

As for general parser combinator alternatives, the leading contender is parboiled and/or parboiled2.

See example at https://github.com/sirthias/parboiled/wiki/Simple-Scala-Example

  --Rex

 

[Jon Pretty]

Hi Alan,

I think there are two sides to the enterprise-readiness coin. It's primarily the fact that Typesafe's commitment to Scala in the enterprise that Parser Combinators have been moved out of the standard library.

Here's the problem: enterprise-readiness demands a high level of stability. So Typesafe go to a huge effort to maintain binary compatibility between minor-version releases of Scala, with major versions on a roughly 18-month cycle, and two major versions supported concurrently. This means that you can carry on developing against a stable API for up to about 3 years, before you're forced to upgrade. If an API is to be removed, then there's also a promise to mark it as deprecated (meaning you get a warning during compilation) for a whole release cycle prior to its removal. This guarantees that if your code compiles without warnings in Scala 2.x, then it will compile (possibly with warnings) in Scala 2.(x + 1). This is designed to smooth the development process along as much as possible. It ensures there's always an 18-month window in which you can upgrade Scala whilst always working with a supported version. This is all entirely motivated by "enterprise readiness", and it's enabled, for example, (and this is from my own experience of the market) most banks operating out of London to adopt Scala. At least one of those banks has a team of over 200 people working full time in Scala.

Meanwhile, people are finding bugs and adding features to libraries like Parser Combinators all the time. If these libraries are part of the Scala standard distribution, then progress becomes constrained by Scala's release cycle, so this was the motivation to move them out of the standard library and into separate projects, so that they could evolve more quickly. However, support and maintenance has to be prioritized, and the economics of the situation means that the Scala development team (which is capable, but small) has to choose which issues to devote time to, and which have to wait.

But this is all open source development, so moving Parser Combinators out of the standard library makes it much easier for people who care to contribute. My speculation about the likely destiny of Parser Combinators, and the JSON library, is based on there being better libraries available now, which most people would probably prefer to use over Parser Combinators when starting a new project. But I might be wrong: As Jason says, there's no commitment to abandon them, and there's no great overhead in maintaining them as they are, so they will continue to exist for as long as there's sufficient effort put in to counterbalance the bitrot, and likewise they will gain features and bugs will get fixed if people see the value in putting that time in. If they are ultimately abandoned, it will be because the world will be satisfied with the alternative.

As for documentation as a solution to issues, there was some brief discussion about that here:

   https://twitter.com/extempore2/status/523871835616579584

;)

Anyway, apologies for the long response...

Cheers,
Jon

--

Jon Pretty | @propensive

[Alan Burlison]

On 01/12/2014 01:09, Jason Zaugg wrote:

> There are definitely caveats with regards to performance and thread safety,
> and perhaps we can do a better job at advertising these to people
> evaluating the library.

I think that's vital. I was considering replacing a small hand-crafted
parser that runs inside a servlet container with Parser Combinations,
the lack of thread-safety would have caused me grief and as far as I can
tell is completely undocumented.

--
Alan Burlison
--

[Alan Burlison]

On 01/12/2014 01:44, Rex Kerr wrote:

> I didn't say anything about how clear, simple, better, or cool parser
> combinators are or are not. I only implied that there are other libraries
> that are even better, at least at most things. But parser combinators are
> not being dropped; they've just moved out of the main library jar.
> (They're not problematic enough to warrant being dropped altogether, at
> least while there is no in-library replacement.)

Not being thread-safe seems pretty problematic to me.

>> I haven't seen any recommendations for replacements for the Scala JSON
>> code, let alone Parser Combinators which it now seems I'm being told should
>> not be used either, even though they are not deprecated.
>

> Jon Pretty listed *seven* alternatives in this very thread?

Which is exactly my point - having every potential user of Parser
Combinators (or any other Scala feature) asking on scala-user before
they use them doesn't scale, and many of them will (like me) assume that
if something is part of the standard Scala distribution it is supported
and fit for purpose.

> As for general parser combinator alternatives, the leading contender is
> parboiled and/or parboiled2.
>
> See example at
> https://github.com/sirthias/parboiled/wiki/Simple-Scala-Example

Yes, and that plus the other information in this thread needs to be in
the docs somewhere.

--
Alan Burlison
--

[Alan Burlison]

On 01/12/2014 01:57, Jon Pretty wrote:

> I think there are two sides to the enterprise-readiness coin. It's
> primarily the fact that Typesafe's commitment to Scala in the enterprise
> that Parser Combinators have been moved out of the standard library.

I know that things were split up - primarily because the documentation
which previously was all cross-linked is now a far less useful
archipelago, but I haven't seen any specifics of why the splits were
made - the 2.11.1 release notes have one vague paragraph on the subject.

> Here's the problem: enterprise-readiness demands a high level of stability.
> So Typesafe go to a huge effort to maintain binary compatibility between
> minor-version releases of Scala, with major versions on a roughly 18-month
> cycle, and two major versions supported concurrently. This means that you
> can carry on developing against a stable API for up to about 3 years,
> before you're forced to upgrade. If an API is to be removed, then there's
> also a promise to mark it as deprecated (meaning you get a warning during
> compilation) for a whole release cycle prior to its removal. This
> guarantees that if your code compiles without warnings in Scala 2.x, then
> it will compile (possibly with warnings) in Scala 2.(x + 1). This is
> designed to smooth the development process along as much as possible. It
> ensures there's always an 18-month window in which you can upgrade Scala
> whilst always working with a supported version. This is all entirely
> motivated by "enterprise readiness", and it's enabled, for example, (and
> this is from my own experience of the market) most banks operating out of
> London to adopt Scala. At least one of those banks has a team of over 200
> people working full time in Scala.

Except in the case of Parser Combinators the deprecation was added and
then removed, which is what started this thread in the first place.

> Meanwhile, people are finding bugs and adding features to libraries like
> Parser Combinators all the time. If these libraries are part of the Scala
> standard distribution, then progress becomes constrained by Scala's release
> cycle, so this was the motivation to move them out of the standard library
> and into separate projects, so that they could evolve more quickly.
> However, support and maintenance has to be prioritized, and the economics
> of the situation means that the Scala development team (which is capable,
> but small) has to choose which issues to devote time to, and which have to
> wait.

I understand the general principles and they seem reasonable, but they
need to be clearly communicated and I couldn't find anywhere where they
were. And there needs to be more than just general principles, the plans
for specific components need to be published somewhere.

This issue isn't just restricted to Parser Combinators. The various
SynchronizedXXX traits have been deprecated in 2.11.x yet the Scala
documentation still recommends their use and says nothing about the fact
that they are unreliable:

http://docs.scala-lang.org/overviews/collections/maps.html#synchronized-sets-and-maps

> But this is all open source development, so moving Parser Combinators out
> of the standard library makes it much easier for people who care to
> contribute. My speculation about the likely destiny of Parser Combinators,
> and the JSON library, is based on there being better libraries available
> now, which most people would probably prefer to use over Parser Combinators
> when starting a new project. But I might be wrong: As Jason says, there's
> no commitment to abandon them, and there's no great overhead in maintaining
> them as they are, so they will continue to exist for as long as there's
> sufficient effort put in to counterbalance the bitrot, and likewise they
> will gain features and bugs will get fixed if people see the value in
> putting that time in. If they are ultimately abandoned, it will be because
> the world will be satisfied with the alternative.

Are there any plans to fix them? The poor performance is one thing, but
the lack of thread-safety just seems like a bug.

> Anyway, apologies for the long response...

No, thank you for taking the time to write it,

--
Alan Burlison
--

[Simon Ochsenreither]

I haven't seen any recommendations for replacements for the Scala JSON
code, let alone Parser Combinators which it now seems I'm being told
should not be used either, even though they are not deprecated.

The deprecation is more or less pending on figuring out whether we want/need to point to/provide a replacement.
Parboiled2 was already mentioned a lot in this thread, but there is a significant difference between parser combinators and parser generators, so parboiled2 wouldn't be a drop-in replacement at the architectural level.

See earlier discussion here: https://groups.google.com/d/msg/scala-internals/4N-uK5YOtKI/teWdFXR290oJ

[Alan Burlison]

> The deprecation is more or less pending on figuring out whether we want/need
> to point to/provide a replacement.
> Parboiled2 was already mentioned a lot in this thread, but there is a
> significant difference between parser combinators and parser generators, so
> parboiled2 wouldn't be a drop-in replacement at the architectural level.

It doesn't seem to be "pending" to me, if I use the JSON parser I get
a compile time warning saying it's deprecated. And the reasons why it
was deprecated seem to be primarily due to flaws in the underlying
Parser Combinators library rather than the JSON parser built on top of
it, so it appears that the deprecation annotations were put in the
wrong place to begin with.

> See earlier discussion here:
> https://groups.google.com/d/msg/scala-internals/4N-uK5YOtKI/teWdFXR290oJ

Interesting, insofar as it makes it pretty evident that parboiled2 is
even more problematic than the current Scala Parser Combinators code.

Seems to me that although the issues with Parser Combinators are
well-known, the response has not been to come up with a get well plan,
rather it has been to resort to wishful thinking - that someone else
will magically solve the problem. IMHO, that's unlikely.

I fully understand there's a problem here but vague hand-waving and
mutterings about the intrinsic goodness of Open Source simply don't
address the issue sufficiently - and as I've said, it's not an issue
that's just restricted to Parser Combinators.

--
Alan Burlison
--

[Alan Burlison]

One other question: are the problems with parser Combinators (e.g.
performance, not thread-safe) also present in the Packrat support in
the same library?

--
Alan Burlison
--

[Grzegorz Kossakowski]

On 1 December 2014 at 15:20, Alan Burlison <alan.b...@gmail.com> wrote:

Seems to me that although the issues with Parser Combinators are
well-known, the response has not been to come up with a get well plan,
rather it has been to resort to wishful thinking - that someone else
will magically solve the problem. IMHO, that's unlikely.

Alan,

Thanks for pressing hard on this issue. I agree we should be more explicit about decisions we make and better document shortcomings of APIs we deprecate.

Alan, would like to lead the effort that documents better issues with performance and thread safety of parser combinators? That would be the first step towards fixing thready safety issue. I'm happy to give you pointers to older discussions to get you started.

--

Grzegorz Kossakowski

Scalac hacker at Typesafe

twitter: @gkossakowski

github: @gkossakowski

[Alan Burlison]

> Alan, would like to lead the effort that documents better issues with
> performance and thread safety of parser combinators? That would be the first
> step towards fixing thready safety issue. I'm happy to give you pointers to
> older discussions to get you started.

If you mean crafting some wordage to go into the appropriate scaladoc
then I'm happy to do that, but I'm not qualified to make the decision
about what the future of the Parser Combinator code should be. I
believe that plan needs to be made and agreed by the appropriate core
Scala people first.

--
Alan Burlison
--

[Simon Ochsenreither]

It doesn't seem to be "pending" to me, if I use the JSON parser I get
a compile time warning saying it's deprecated. And the reasons why it
was deprecated seem to be primarily due to flaws in the underlying
Parser Combinators library rather than the JSON parser built on top of
it, so it appears that the deprecation annotations were put in the
wrong place to begin with.

I'd say that the JSON part is deprecated because there are tons of better alternatives, while the replacement for parser-combinators is not there yet.

Interesting, insofar as it makes it pretty evident that parboiled2 is
even more problematic than the current Scala Parser Combinators code.

I wouldn't say that. There has probably been more activity in parboiled2 since that discussion than in the last few years in parser-combinators.
Some of the issues were already addressed, as seen in https://groups.google.com/d/topic/scala-internals/q-pJ4aMNgmo/discussion and https://groups.google.com/forum/#!forum/parboiled-user.

Seems to me that although the issues with Parser Combinators are
well-known, the response has not been to come up with a get well plan,
rather it has been to resort to wishful thinking - that someone else
will magically solve the problem. IMHO, that's unlikely.

???
I think the larger plan is to start recommending parboiled2 as soon as some of the remaining concerns are addressed, instead of dragging a library along which hasn't seen much work or even maintenance in the last few years.

[Grzegorz Kossakowski]

Thanks for offering help! Let's start with pointers to discussions around known issues:

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

https://issues.scala-lang.org/browse/SI-9010

When it comes to planning, I think I agree with you that thread-safety issue is the most important one that needs to be addressed. Tickets I linked to provide plenty of background info on that one. 

I think once thread safety issue is fixed and specific guidelines around performance are provided for our users then parser combinators could be kept around. However, it must be made clear that parser combinators are applicable only when performance is not a concern. For example, sbt uses parser combinators for parsing commands people enter in its console. In such scenario performance is not a concern at all.

The core Scala team is not planning to work on those issues but we are happy to help anybody who is willing to take a stab at it.