BuckleScript 8.1: new syntax option

#41

The array and list syntax switch is staying (see above discussion), but list’s particular syntax is new, so we didn’t want to overpromise in case there’s a deal breaking use-case. We’ll try to be diligent and not touch it though.

#42

Does the new multiline string literal support indentation?

like

let example = () => {
  let str = `bla bla
  bla bla
  `
}

Does the second line get all the indentation as the intended code, or does it line up with the last backtick.

#43

All the indentation, but we can discuss about that.

#44

Awesome. Would be great to have proper multiline string literal support (in whichever syntax), especially when working with React.

I think the only difference would be that we need to require the last backtick to always be on a newline for the multiline string literal.

#45

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?
I’ll speak to the native side a bit:

On the native side, we’ve began implementing the v4 features already, many of which are present in the new BuckleScript syntax option, so the difference would be less than what you currently see.
This BuckleScript specific parser doesn’t change anything for the direction of native, but having this BS parser out there does provide a nice way for us to listen to feedback about some of the more aggressive changes and maybe even take some of the design decisions into consideration for .re. We’re also happy to provide feedback to the BS parser with the goal of making them as close as possible, though I imagine the BS one would always put the JS development experience first, so there’s probably only so much you can do.

I’ll note that I am not working on this BS-specific syntax, and I am not involved in its design, but I’m open to providing feedback and rolling some of the learnings into the Reason syntax.
One thing to note is that it is already the case today that you cannot just use a Reason file in BuckleScript and in OCaml compatible ecosystems. There may be certain Reason syntax features that only work with BuckleScript, already. So one potential positive benefit of something like this new BS syntax is that it just manages expectations of the user such that they match reality.
The other positive benefit such a divergence could have, is that it allows us to double down on the form of Reason that maintains compatibility with the OCaml ecosystem. In the past there have been bugs in the Reason parser which we actually couldn’t practically fix because BS vendors the Reason parser, and BS libraries were relying on the old behavior before the fix, with no way for individual libraries to express their dependency requirements on certain versions of Reason.
Thoughts?

#46

Is there anything more you can share about the plan for editor support. It looked like at one point that the ocaml labs might help unify things but probably less likely now…?

#47

We’d like fewer editor plugins, but I’m also not sure the ocaml one is enough yet, though I might be wrong.
I think a better direction is to have a single dedicated plugin for part of the ecosystem, then a single dedicated plugin for the other part. Maybe the split is native/BS. We’ll have to see. Definitely not 3 though.

#48

presumably going for 2 different plugins would mean needing two different file extensions, should different parts of a project ever touch both compilation targets?
(bit confused by jordan’s comment about porting the new parser to .re files… will .re and .res continue to exist going forward with .re for native and .res for js.?

#49

I don’t recall saying that anything would be ported to anything else.
(Although I’m not opposed to pulling stuff in or sharing infra where possible).

#50

yunti if that’s the case (if!), your editor would be able to choose which plugin to use, so that won’t be a problem.

#51

Sorry perhaps I misunderstood, I was referring to ."…maybe even take some of the design decisions into consideration for .re". From the 8.1 post I was assuming that .re files may die away (after a suitable period) and .res files replace them, but your comment suggests differently. I may be inferring too much here.

#52

I don’t know what BuckleScript will do with .re support in the longer term, but the roadmap for the Reason Parser is to implement V4 features. The .res parser that BuckleScript includes is a different thing, with a different, simpler implementation, and slightly different feature set, but since they’re so similar, I would willing to coordinate to make Reason Parser .re more similar where it makes sense. Does that clarify?

#53

I would suggest putting the effort into ocaml-lsp/ vscode-ocaml-platform, as that is better maintained at the moment and it includes support for merlin which gives a faster better user experience (there are some quirks though). Reason language server has been unmaintained for a while.

#54

Yup that makes sense thanks.

#55

So basically ReasonML native and Bucklescript would have a similar relationship to Haskell and purescript, meaning two separate languages with deliberately high similarity?

#56

I think that’s one of the key questions, how do you succintly explain what Reason is to an outsider?
I’ve always thought as bucklescript as ocamlscript, (like clojurescript) and reason as a js like syntax for either. (now with some syntax differences where it makes sense for the compilation target). Though that probably isn’t how I would promote it.

#57

I’m not familiar enough with PureScript. Do PureScript and Haskell share the exact same type system?

#58

More like Haskell and Eta.

#59

I always viewed them as reasonably distinct with Purescript inspired by Haskell rather than Haskell targeted to the JVM so not like JSOO for Ocaml. It’s also not lazy like haskell. This is probably a reasonable summary. https://github.com/purescript/documentation/blob/master/language/Differences-from-Haskell.md#evaluation-strategy

#60

My .02¢. There is a lot more stuff out there, and better documented, in ocaml land. Having access to older ocaml stuff acts as a kind of built in crutch for our newer ecosystem where we don’t have years of material out there to reference. When we think about how our syntax has been changing as the work gets done to improve it, most of the reasonml resources get outdated fairly quickly.

So one perspective here is that we may end up rendering most of the prior art out there useless as .res and .resi files start showing up.

The impression I have always had is that this is ocaml with a different syntax and we get all of ocaml in a way js devs understand it. It feels like that is no longer the direction of the project. That maybe the reason docs should feel less like bucklescript and reasonml are inseparable and reflect more that they are in the same ecosystem, more same Genus than Species in biological classification.

Feels like Bucklescript wants to go head to head with Typescript almost and that the energy that goes into this ecosystem is going to get split.

Is .res development going to cost .re development? What will gentype do? Will it follow .res or .re?

Hey folk, I am just thinking out lout here. I don’t have any specific technical arguments. I don’t mind the syntax at all. You guys are awesome with the way you get it done. Thank you! I’m just thinking about the sales pitch with all the churn. Half feel guilty writing this and half hoodwinked at the same time.

Peace/Love/Reason