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

Publish for Dotty #210

Closed
travisbrown opened this issue Mar 9, 2020 · 19 comments
Closed

Publish for Dotty #210

travisbrown opened this issue Mar 9, 2020 · 19 comments

Comments

@travisbrown
Copy link

I've started working on this, primarily in order to unblock Dotty cross-building for http4s. I've got most of the combinators ported, including a simplified version of ~>, and will push a WIP branch soon (probably later this week).

I'm not aware of any other attempts to set up Dotty cross-building, and am opening this issue to track progress and help avoid duplicated work.

@sirthias
Copy link
Owner

sirthias commented Mar 9, 2020

Thank you, Travis!
Without having looked at things more closely I could imagine that porting pb2 to Dotty entails quite a bit of work, which I wasn't sure is worth the effort, since it's hard for me to gauge the current user base.

So, my initial approach was to simply wait until someone opens the first "please port to Dotty" ticket.

What is http4s using parboiled2 for? HTTP header parsing?
Would it make maybe sense to simply rewrite the parsing parts to a hand-rolled parser instead of pulling pb2 along?

The reason I'm a bit caution wrt putting in a lot more work into parboiled2 is that, from my current perspective, I'd regard the basic approach as only half successful. While parsing performance is generally good and error reporting not bad I would, today, go for a different, more flexible and more composable design for modeling parsing rules.

@travisbrown
Copy link
Author

@sirthias http4s has dozens of Parboiled parsers (~190 rules) for different header types, IP addresses, etc., and currently uses a parboiled2 fork (not exposed in any public APIs) to avoid Shapeless conflicts for users. The fork generally stays pretty close to upstream (right now it's a month and a half behind).

We could rewrite these parsers, but my feeling right now is that it'd be less work to get the subset of parboiled2 that's needed to support them working on Dotty. I think I'm about an half-day of work away from that after getting started last weekend—it's close enough to complete that I can work through the non-Parboiled-related compilation errors on Dotty, which was my primary goal at the moment.

My plan has been to finish this minimal port in the http4s parboiled2 fork, outline what's missing, and see if there's interest in completing the migration upstream. I definitely understand if there's not, or if that's not a priority for anyone in the immediate future!

@sirthias
Copy link
Owner

Ok, thank you for this update!
I'd say we keep this ticket open and use it a discussion channel for your progress. If things really go as smoothly as you expect than it sounds like cross-building for Dotty might actually be worth the effort.
In any case it'd certainly be valuable to make the work in your fork available to us here in the upstream repo, maybe simply as a partial PR serving as a seed for the full port to Dotty, which could be completed at some later point in the future.

@rossabaker
Copy link
Contributor

@travisbrown Did your parboiled branch ever get published? I'm beginning some core model cleanups in http4s, which includes the parsers, and am wondering whether we still think Parboiled2 on Dotty is plausible or if it's time to move on. I agree with @sirthias's comments on composability, but it's nice how the parboiled parsers resemble the RFCs, and the project has treated us well for many years.

@travisbrown
Copy link
Author

@rossabaker I don't think I've pushed the branch yet, but I'll try to dust it off tomorrow.

@phdoerfler
Copy link

phdoerfler commented May 20, 2020

The reason I'm a bit caution wrt putting in a lot more work into parboiled2 is that, from my current perspective, I'd regard the basic approach as only half successful. While parsing performance is generally good and error reporting not bad I would, today, go for a different, more flexible and more composable design for modeling parsing rules.

@sirthias Don't let anyone stop you from making an even better parboiled3 using, e.g., scala.meta ;)
Seriously though, I would love being able to use parboiled2 or something even better with Dotty / Scala 3. But I am not a significant user base, of course. I only use parboiled for hobby and for small open source projects. And obviously such a nice library does not write itself over night, so I don't expect this to be happening any time soon.
One can dream though!

@rossabaker
Copy link
Contributor

@travisbrown Do you still have that branch anywhere? I'm getting ready to sort out what still needs to be done for http4s so we can plan our Dotty release roadmap, and this is the scariest dragon we've thought of.

@SethTisue
Copy link

SethTisue commented Mar 21, 2021

alternatives that are already available for Scala 3 include https://github.com/typelevel/cats-parse (the up-and-comer) and https://github.com/scala/scala-parser-combinators (the old standby; not industrial-strength, but works fine if you don't care about performance)

(fastparse has been a popular choice for Scala 2, but Scala 3 support hasn't landed, as per com-lihaoyi/fastparse#246)

@yanns
Copy link
Contributor

yanns commented May 28, 2021

We are extensively using parboiled2, for internal applications, and for sangria

If there is any WIP branch, I'd be willing to spend some time continuing the work.

@yanns
Copy link
Contributor

yanns commented May 31, 2021

Travis was very kind and pushed his last changes here: travisbrown@03483e3

I'm taking a look at those.

@yanns
Copy link
Contributor

yanns commented May 31, 2021

It seems that we must choose between scala native & scala 3 for now: scala-native/scala-native#2317

@lolgab
Copy link

lolgab commented May 31, 2021

It seems that we must choose between scala native & scala 3 for now: scala-native/scala-native#2317

You don't have to choose, you can exclude Scala Native/Scala 3 from the matrix, while keeping Scala Native/ Scala 2

@yanns
Copy link
Contributor

yanns commented May 31, 2021

It seems that we must choose between scala native & scala 3 for now: scala-native/scala-native#2317

You don't have to choose, you can exclude Scala Native/Scala 3 from the matrix, while keeping Scala Native/ Scala 2

👍
I figured that myself:

lazy val commonNativeSettings = Seq(
  // Currently scala-native does not support Dotty
  crossScalaVersions := crossScalaVersions.value.filterNot(Scala3 == _)
)

@yanns
Copy link
Contributor

yanns commented May 31, 2021

The dependency on shapeless is an issue right now. As shapeless is using macros, I cannot use .cross(CrossVersion.for3Use2_13).
milessabin/shapeless#1043

I'm trying to remove this dependency temporary by copying hlist into parboiled2. It's not a long term solution.

@rossabaker
Copy link
Contributor

rossabaker commented May 31, 2021 via email

@jrudolph
Copy link
Collaborator

jrudolph commented Jul 5, 2021

http4s' fork of parboiled2 existed to remove the shapeless dependency. That might give you a head start.

Same for akka-http's fork which includes only the essential parts from shapeless for building parboiled2 (which is hlists).

@yanns
Copy link
Contributor

yanns commented Aug 9, 2021

If some people want to help, I've started a new branch trying to keep a clean history that can be used as base: #274

It's only the basic structure for now, nothing is working.
If you want to help, you can try hacking on the macros, or moving one test from scala-2 to scala and fix the compilation issues.

@yanns
Copy link
Contributor

yanns commented Aug 30, 2021

New base branch: #280

@sirthias
Copy link
Owner

After the awesome work in #280 this is finally done.
Version 2.4.0 is cross-build against Scala 3, has been published to sonatype and should appear on Maven Central soon.

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

8 participants