BuckleScript 8.1: new syntax option

#5

Also looks like we might need some escaping here to show what characters you’re using:

image
image.png1170x90 8.46 KB

#6

We apologize for having kept this under wrap; syntax discussions have always been churny, so we didn’t want to prematurity announce something before it’s ready. After testing this extensively; we now deem it solid enough for your consumption.

TBH I didn’t like some of the changes but I do understand why they are necessary. As quoted, the only bummer for me was that they arrived in surprise drop and it was not talked with the community before hand that they would happen as this will make a lot of articles and blog posts out there obsolete. Also a lot of us are using ReasonML + BS in production for years already but I’m glad that we’ll have a refmt converter.

Besides that, thanks you all for all your effort!

#7

Are there any plans to support async/await syntax?

#8

@splodingsocks thanks, a bit of issues from the difference in markdown parsers. Parsers…

@gabrielrabreu thanks. Actually, I’d like to take this occasion to start being a bit more open about some of our efforts. One day I’ll be able to explain why things has been set up the way it is; right now it’d be a lot of noise talking about it.

As stated in the blog post (and hopefully as shown with our past actions), whatever code you have right now will still work. Heck, that’s half of the reasons for picking the new .res extension; your old code won’t be obsolete.

#9

Can you refmt the new .res files already? Or is that the mentioned refmt-to-new-syntax?

#10

@yawaramin doesn’t. The let sugar is causing lots of problems right now, which I’ll get into in a different thread later, now that we’re using Discourse more seriously. I do want some async syntax for some async concept though.

Tablecloth & Standard merge, new API naming (Poll)
#11

It all looks great!

I so hope %foo(if) won’t be turned into if%foo anymore :crossed_fingers::crossed_fingers::crossed_fingers:

Also,

Interpolated string

Is it type safe now or it’s syntax only change?

fun pattern matching syntax removed

Will there be a replacement?

#12

I mentioned this on the Discord, but while I do quite enjoy this syntax, it strikes me that this introduces more ambiguity on what ReasonML is at its core. Is it a syntax? Is it a language? Is it a single toolchain? Is it multiple toolchains?

I understand that the dependency on OCaml may turn some people off from the language (and that may be why ReasonML is embracing the JS side of itself more and more). It is already difficult to explain the relationship between OCaml, ReasonML, and Bucklescipt to a developer new to the language(not to mention Esy, Dune, Opam etc), now we’ve got to explain that there’s a SPECIFIC syntax for JS that doesn’t work for native?

What does this mean for the future of Native ReasonML? Is that dying or being de-emphasized? Or is there something on the way that will implement some or all of this syntax for the native toolchain?

#13

Thanks! and moving to Discourse(and keeping it alive) is great!
My question is, even though i understand some discussions are plain noise, and i’m happy with the people actually doing the work making the (final) decisions.
Maybe there’s room to consider at least some middle ground?
Or rather, when will we actually talk about what this community is? how features are actually considered? what’s the roadmap?

#14

@jsiebern yes. That’s for later; we’d like some prudence regarding conversion, so right now, please do test on new code (or manually tweak a few of your existing files and take the occasion to compare each change). As always, we’ll be releasing a proper script once nobody reports back that the new syntax blew up their project or something =)

@alexfedoseev the interpolated string is still not type-safe. Just a syntax change for now. The fun pattern matching won’t have a replacement aside from the ordinary function declaration followed by a switch. The rationale behind many of these warrant their own thread, but the short version is that this encourages reckless currying and other unexpected syntax-driven semantic problems. Sorry about that, but considering that the syntax change should not be only additive (that’d be unbearable), this particular one had to go.

@bbenne10 stay tuned on this. At least this is one piece of the puzzle done I believe.

#15

@BlueHotDog I’ll be making a thread to clarify this too. And yes there’s a middle-ground, but the middle-ground has been much harder to find than folks believed, especially when it comes to the sanity of the maintainers. We’re… paving new ground on this though.

#16

@chenglou Thanks for the answers!

And one more question: what needs to be done to make it happen on Atom?

#17

Are there any plans to „merge“ this into ReasonML or will this forever be a standalone syntax for Bucklescript?

No need for parentheses around if, switch and try.

Does this mean you can’t have parentheses around these or are they optional?

#18

Awesome! looking forward on communications regarding this :slight_smile: (maybe ask the community how it can help relieve some of the stress?

#19

@alexfedoseev the new highlighter is here. If you’d like, just take that and put it in the Atom plugin. They use the same grammar mostly. That’s a bit too much info for the thread maybe, so feel free to bring this to PM.

@Ewert this syntax has been made by a community member. My personal feeling is that this is hopefully enough for some ambitious moves in the future. But each such change is a lot of churn, so I wanna test the water first. One thing worth repeating: your existing code won’t randomly break (for a long time).

For the parentheses: optional, but you can still write them for the same reason you can still wrap any other expression in parentheses.

#20

Does this mean that an async/await syntax separate from OCaml’s applciative/monadic let syntax is being considered? In my opinion this would be an enormous mistake.

#21

Let’s not turn another thread into a monad discussion please. I’ve mentioned that I’ll be making a dedicated thread for it.

#22

Just playing with the identifiers a bit.
This was possible before:

let (&) = (v1, v2) => v1 + v2;
let isGt = (v1, v2) => (v1 & v2)  > 0;
let isGt = (v1, v2) => (&)(v1, v2) > 0;

Trying to re-create that gives me:

let \"&" = (v1, v2) => v1 + v2;
let isGt = (v1, v2) => (v1 \"&" v2)  > 0; // Doesn't work
let isGt = (v1, v2) => \"&"(v1, v2) > 0; // Works

So the \"" will be required when using the identifier later then? I know, edge cases and all, just wondering :smiley:

#23

We disallow arbitrary infix in this syntax, so yes, it’ll have to be prefix. There’s a middle ground of supporting a first-class set of good looking infix operators folks can override, with the benefit that 1. they look good and don’t have to use the first character to abide by some precedence rules and 2. it’ll be agreed-upon and well understood, so doesn’t make a codebase cryptic because someone created their DSL within the language.

The arbitrary identifier is made for a few reasons, mainly interop with JS names (e.g. record fields). It’s not meant to be used as such. That’s a creative try there though =)

#24

So sorry, I missed the No custom infix operator for now (including mod). in the blog post. I was in a rush to try things out.

I like it a lot so far btw, that is awesome work!