-
Notifications
You must be signed in to change notification settings - Fork 98
dev meeting 19 09 2023
- State of OMP deprecation.
- New compiler parsetree changes:
- Open PRs on ppxlib.
- (Is it viable to try to stay in sync with OCaml trunk?)
- (If there’s a lot of time left and nobody is in a hurry, we might also chat about ppxlib in general and meta-programming approaches in other languages.)
- Sonja / @pitag-ha
- Paul-Elliot / @panglesd
- Florian / @Octachron
Florian came to the meeting, which was a great opportunity to discuss things related to the compiler in more detail 🎉
We've discussed three recent compiler parsetree changes: The parsing: Attach a location to the RHS of Ptyp_alias change, the Add parameter location information to parsetree/typedtree change and the change for syntactic function arity.
The parsing: Attach a location to the RHS of Ptyp_alias change isn't a problem from a Ppxlib perspective. It just adds a location to a node that didn't hava a location before. We don't have migrations for it yet, though.
Action-point Paul-Elliot: Ask Jules, the author of the compiler PR, if he can write the migrations.
The Add parameter location information to parsetree/typedtree change is good news for us: It makes it a lot easier to get the locations right in the migrations for the parsetree change adding syntactic function arity.
For the syntactic function arity change, we already have a PR with migrations , but haven't merged it into the trunk-support branch yet, because it's lacking tests. That branch is meant to be used on own risk, so we'll merge the migrations without tests.
Action-point: Merge PR adding migrations for syntactic arity parsetree change.
Sonja was also wondering if that change might break the semantics of PPXs without breaking them syntactically. Both Florian and Paul-Elliot have confirmed that that's nothing we need to worry about, since the change clearly modifies the fun node in a way that should be captured on any pattern matching. However, we do need to pay special attention in the 5.2 AST bump, since we're expecting this change to break a lot of PPXs (syntactically).
The topic whether or not to bump the Ppxlib AST to 5.1 has come up again. However, the take-away is still the same: OCaml 5.1 didn't introduce any new syntax features that are reflected in the parsetree. Florian confirmed this, pointing out that the 5.1 syntax features are only reflected in the parser, e.g. by adding support for some new sugar syntax. The point of bumping the AST is to support new syntax features reflected in the parsetree. So bumping the AST to 5.1 wouldn't have any value. Instead, we'll wait for 5.2 and bump it then.
We're expecting the 5.2 bump to break quite a few PPXs because of the syntactic function arity change. Florian has mentioned that it might also contain syntax support for effects! That would be great for us, since it's a lot better to bundle two big changes in one bump than having two consecutive bumps in which we break the same PPXs again.
Given that we still haven't upstreamed Astlib to the compiler, compiler parsetree changes are PRs on the compiler and the corresponding parsetree migrations are PRs on Ppxlib. From a Ppxlib maintainer perspective, it would be a good rule that the compiler maintainers wait merging the compiler PR until we've written the migrations. That way, we make sure any merged parsetree change admits migrations.
Florian agrees with this in general. However, he's also pointed out that every rule has an exception and for very big PRs, it can make sense to merge the change and to potentially fix it in a later PR. That's what happened for the arity change and hasn't been any problem 👍
We've felt ready to deprecate OMP ever since with ppx_import, one of the last opam packges depending on OMP was ported to Ppxlib. However, for one reason or another, we've never gotten the deprecation through. Now, it seems like the whole community is behind it, and we'll most likely deprecate it instead of adding OCaml 5.1 support.
We've written a discuss post with a lot of context about the deprecation and asking for potential feedback from the community. Nobody has objected or commented in another way.
We've also discussed why OMP is getting packaged on some distributions. We don't know, but it seems historical. OMP won't be compatible with new compilers anymore, so if OMP doesn't get removed from the distribution, it will block bumping the OCaml system version to a newer version. We'll reach out giving a heads-up about the upcoming deprecation and incompatibility.
Action-points Sonja: Reach out to Debian, Fedora and Arch package managers. Give a last heads-up on discuss. Depcretate OMP.
There are no new PRs since the last meeting, so there's nothing new to discuss 😎