BuckleScript 8.1: new syntax option


Yeah, I’ll stop posting new issues here. But it makes sense to continue existing discussions on topic :thinking:

Oh I very much appreciate that this is a new direction and my codebase will work for the foreseeable future. It’s the long term future I’m concerned about.

This is something my team will be discussing, probably after the syntax is declared stable enough that a migration script is made available. Some of them are already pondering whether we give up our nice infix functions to get the benefits of bucklescript syntax, which surprises me.

Has the first-class list been posted anywhere yet? I was thinking of creating a post listing the ones from my codebase and how they’re used, for discussion and context around my concerns. Maybe I’ll make it a github ticket instead.


There’s already a thread, I think it’d be better to first discuss the specific changes here before filing an issue (maybe once consensus has been more or less reached):


sorry, by “first-class list” I meant the list of first-class infix operators, not the first-class list syntax… but you’re right, a post is probably more appropriate to start with.


Haha sorry, I misunderstood indeed, yes I think having a dedicated thread on discourse is better anyway


Here’s whats new:

The new syntax comes directly with your BuckleScript 8.1 installation. You won’t have to install anything else. It does not depend on the old refmt.

There are a few differences in syntax, documented here.

This is BuckleScript-only currently.

Our editor support is currently limited; we’d like to take this occasion to clean it up. In the meantime, if you upgrade your VSCode or Sublime Text plugin, you should get the proper highlighting.

We’ve made a refmt-to-new-syntax converter that we’ll release later. We’d like you to test it on small bits of code for now; a wholesale conversion at this stage would be a bit too rushed.

To avoid conflict, we’ve employed the new file extensions .res and .resi, for implementation and interface respectively.

This means the syntax sits alongside the existing Reason and ml syntax. We’d like to avoid eagerly deprecating the other syntaxes, but if this new one works well, we’d like to move onto more ambitious territories. Either way: your existing code will keep working!