Let’s not turn another thread into a monad discussion please. I’ve mentioned that I’ll be making a dedicated thread for it.
BuckleScript 8.1: new syntax option
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
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 =)
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!
I love the new syntax overall, there are a couple of points that surprise me still:
-
[1,2,3]
being an array and not a list, I’ll put it first because Iddo not come from javascript, I come from ocaml and python. Is random access that common in JS? - Objects : are they different from records? Do they have a fixed type? The fact they look like ocaml records but they have the " around they keys is a bit confusing to me, again because of my background
- deletion of pattern matching on
fun
, what’s the rationale? - Not entirely convinced of the benefit of the @ and % attributes syntax change. What about @@ and @@@ attributes also? Same change?
Apart from that I think it feels really great and some of those changes I could back for ocaml itself
I missed the No custom infix operator for now (including mod).
Oh, I missed it as well. It’s a bummer Is this temporarily or those will be supported at some point?
- Yeah random access is basically 100% of JS. There’s a broader conversation around array and list that I’ll shelve for the future.
- That was a bit more of a communication toward existing Js.t object users. No,
{"foo": bar}
is actuallyJs.t(ocamlObject)
. Subtyping and all. We don’t expose the entire ocaml object system because the semantics compile poorly to JS and because it’s huge. Thus the parametrization to restrict usages to a known subset. Anyway, after a while ofJs.t(ocamlObjectHere)
we gave it a dedicated quoted syntax. This is just a cleaning up of that. - Will be talked about in a different thread as mentioned.
- That’s a good point we glanced over for the post. But the new syntax makes it so that both
@@foo
and@foo
are@foo
now thanks to various syntactical designs.@@@foo
is now@@foo
. Likewise for%
.
Feel free to snatch whatever back to ocaml. We owe the ocaml folks a lot after all.
@alexfedoseev see my earlier reply. We’ll be first-classing a subset of tasteful infix operators you can override.
What about reason native? I guess this is just OCaml syntax or is it specific to Bucklescript? If it’s somehow tied to Bucklescript, what do you recommend reason native projects to adopt, use OCaml syntax?
It’d be too noisy to discuss each change, it might be good to have subthreads for each group of changes to give some specific feedback but I have a great concern here, it’s how different it looks compared to Ocaml. A lot of libs are written in Ocaml (and of course in the existing reason syntax), it’ll be a pretty big pain to understand syntaxes that are so different. Plus by making lists second class citizens in this new syntax, it definitely discourages its use both for JS (which can be understandable to some extent) and for native (will Reason Native still be a thing actually?).
My only concern is that I’ve been extensively using lists for their fast prepend during recursion, which I’ll lose with arrays. I look forward to reading about the array vs list consideration you’d mentioned.
Removing parentheses is a big win - it’ll significantly reduce the number of keystrokes to program in Reason, and the final code looks less noisier than ES6. All these changes could help a new wave of adoption for the language. The original bet that syntax is important for language adoption has paid off thru the last two syntax overhauls, and I think it’ll continue this time as well.
I’m only afraid that I can’t think of anything major to dislike about the language or the direction in which the core team is evolving it. Either I’ve bought in too much, or the changes are really and consistently in good taste. I of course like to think that it is the latter. I appreciate the new syntax very much and it’ll make it easier to evangelize the language. Thanks for all the work.
@Jfrolich it’s specific to BuckleScript right now and I recommend sticking to your current plans for native.
@tsnobip same as above. This is a delta change vs current Reason syntax and where comprehensive surface changes fit in a few bullets point, so I wouldn’t call it super different. Though if you’re talking in terms of usage count of e.g. list then yeah. Note that many of the changes were planned for Reason already.
@jasim > I’m only afraid that I can’t think of anything major to dislike about the language
thanks?
And yes, due to Reason “blindly” porting over the entirely of OCaml, there’s been a few problems that didn’t exist in OCaml. The extra amount of parentheses is one. This new one fixes it.
Does right now mean that native support is coming eventually but it’s shipping on Bucklescript first? Just want to make this clear because a lot of people think the syntax is specifically for Bucklescript.
I don’t wanna make any promise regarding this, but right now this syntax is indeed specifically for BuckleScript. There’s a big amount of future work banking on potentially tighter integration. For example, the current editor integration is still in a sorry state and to fix it we need all the tight integration we’ll need (sounds like a cop-out but it isn’t).
For the sake of not causing expectation mismatch to folks in the future, I’d disrecommend it if your goal is to use this particular syntax for native. Sorry about that… but the least I can do is to avoid you future disappointments.
It worries me that the syntax is defined with just the Bucklescript use case in mind because it makes some choices probably misguided when it’s taken to native as the second step requiring another change later.
If it’s not coming to native we now have three syntaxes to learn. So then it’s probably better to write native projects in OCaml. However that makes language extensions like GraphQL-ppx less accessible for contribution by the community.
You mentioned that .re
syntax will not break anytime soon, but should we expect .res
syntax to have breaking changes?
So my question is: Should we treat .res
as a preview / alpha release and not depend on the new syntax changes too much?
By the way I am quite excited about the new syntax, as refmt was indeed quite buggy. Love most aspects of it! Quite crazy that this has been done in secret without anyone noticing. I was already looking into the napkin PR and didn’t understand it .
@Jfrolich you’re not wrong; I do think some choices can end up misguided when naively copy pasted to native. But honestly 1. judgement has always been needed for these matters, though a little bit more now and 2. this is already happening. E.g. we have folks doing the opposite of this too, e.g. porting completely unviable array semantics back to native just for sharing a few bits of API. If anything, the old syntax should have discouraged that! But it did not.
There’s been misguided attempts all around in the past (as with any community), and I hope the renewed messaging effort can help alleviate this. More so than syntactical choices, which honestly didn’t prevent that many misguided attempts.
Editor support: we’re gonna try to concentrate on reason-language-server for now.
@Ewert strictly speaking, yes. This is part of why we have the conversion script ready but refrained from releasing it now. But nothing huge will change. I’d say you won’t have a bad time tweaking the few bits of .res
code in the future, if ever.