Wouldn’t that make them less typesafe? (Especially when using library code, you basically have to coerce the errors to the right type with is error prone?).
it will be type safe, the conversion is done mandatory
Of course, but you the conversion is error prone (because the error isn’t typed anymore). We had a lot of these cases in graphql-ppx where you had to coerce a generic type (Js.Json.t) to an explicit type, and it was the source of a lot of bugs.
I can imagine that when you get a promise from the Apollo GraphQL client it is very nice to have type-safety of the error response because it’s a very explicit shape. If people have to cast it explicitly in this shape it’s both error prone and harder to use.
2 Likes
Yeah, I think this might be a useful discussion. Like what are the promise-related usecases and patterns, and when something Result-compatible like aantron/promise or reason-future makes more sense. Even if ReScript doesn’t adopt this approach, it might be useful for the community 
Maybe time to split this out into a new thread for ReScript Promise Redesign or something like that.
5 Likes
It seems that all examples on the new docs site are in ReScript. Does it mean there will be no vanilla OCaml sample code any more?
We’ll provide a command line to convert between Rescript syntax and OCaml syntax and vice versa.
About the documentation site cc @ryyppy
The old vanilla ocaml syntax now sits alongside the old reason syntax, in the doc version 8.0.0: https://forum.rescript-lang.org/t/the-documentation-is-now-versioned-old-syntaxes-added-reasonreact-docs-redirected
2 Likes
Hi, I have a few minor questions.
1. Any chance switch will be renamed to match?
This might be quite a silly question, but my reason for asking is that the switch-keyword kinda reminds me of the handicapped switch in Javascript and what I currently really miss.
2. Some of the API’s seem to use snakecase, will these be changed to camelcase?
My reason for asking is that it feels a bit inconsistent, in my amateur opinion.
3. Are the terms Belt/Bucklescript/BS going to stick around, or will these be renamed in the future to something more rescript-like?
4. The @-operator was usable for concatenating lists, I can’t seem to use it anymore. Is this on purpose?
5. Will it be possible to spread syntax on arrays in the future?
6. Are there any plans to target WASM with rescript?
Thank you for your time.
Hi @doctorgoat!
1. Any chance switch will be renamed to match?
No. switch is the final syntax for pattern matching expressions
2. Some of the API’s seem to use snakecase, will these be changed to camelcase?
There are some functions that are still using snake_case due to the origins of some compiler builtins. Most of them come from the Pervasives module, or can also be found in the List and Array modules. The convention is to use camelCase for all new APIs (like in the Belt.Array or Js.List etc).
3. Are the terms Belt/Bucklescript/BS going to stick around, or will these be renamed in the future to something more rescript-like?
BuckleScript was the original name before it was rebranded to ReScript and is therefore obsolete. All occurrences of BS / BuckleScript etc. will slowly be replaced with the new ReScript naming equivalents in the future.
Belt (as a name) is probably going to stay, since it’s still an okayish name for a stdlib module, and we can’t really deprecate it for backwards compatibility reasons.
4. The @-operator was usable for concatenating lists, I can’t seem to use it anymore. Is this on purpose?
The @ operator is an infix operator, which is currently not supported by the ReScript syntax. There are discussions on how far those will be actually supported, since we believe that infix operators encourage too many different library driven DSLs that cause problems in readability etc.
5. Will it be possible to spread syntax on arrays in the future?
No discussions on this yet.
6. Are there any plans to target WASM with rescript?
There are no plans for WASM support. Our goal is to compile to readable, performant and easy to integrate JS code.
Hope this helps!
5 Likes
Currently the old https://bucklescript.github.io/bucklescript/api/Js.String.html docs get re-directed to https://rescript-lang.org/docs/manual/latest/api/js/string-2 which leads to a few questions:
-
Why is the old default
Stringnow number two? -
How did there come to be two strings? I don’t know of any language that contains two strings
-
The description has:
Provide bindings to JS string. Optimized for pipe-first.
What is pipe-first? Searching for pipe-first in the documentation brings up only the two String module descriptions. Doing an internet search for ‘pipe-first’ brings up rescript pipe docs. But that no-longer describes what pipe-first vs pipe-last is
-
Should the ‘pipe-first’ description of
String2contain a link to the ‘Pipe’ documentation?
It’s the same string. In ReScript you can use the pipe-first -> to pipe the first argument. For instance "foo"->bar is the same as bar("foo"). The Js.String module’s functions are t-last (the main type is always the last parameter), so that is less convenient. They introduced String2 as the new preferred module without a breaking change. I can imagine that at some point in the future String will be deprecated and be replaced by String2.
I agree the naming is a bit confusing, and hope the 2 modules will be the default soon.
1 Like
I’m sad to see the “triangle” pipe-last operator has been deprecated. Personally, I don’t see why we can’t embrace both of them at the same time.
I understand the arguments, and perhaps the only vaguely compelling case for preferring pipe-first is the difference in error messages. But in my experience, this assumption about what we expect from error messages is often wrong. I often prefer the pipe-last error messages. But even if that were not the case, it’s still not that compelling to me.
inference in data first approach is a huge win IMO.
2 Likes
Technically, pipe-last hasn’t been deprecated. Not in the sense of adding a @deprecated attribute to it. And if the ReScript team wants to do that, they would need to maintain a fork of the Stdlib/Pervasives modules going forward … not a very attractive proposition.
I understand though that it is not recommended for ReScript users.
1 Like
In the official ReScript docs for the pipe operator, it shows a lot of examples using the pipe-first operator, and then at the bottom it says pipe-last is “deprecated”. They use that word specifically:
But it would make me very happy if that wasn’t the actual intent.
I was used to use pipe-last, but now I have been writing my bindings in ReScript using pipe-first. I personally don’t have a preference, but I’m still a bit confused if we should see the pipe-first as a good practice to be adopted by the community or pipe-last as indeed deprecated.
What bothers me a bit is have to mix both styles because of external dependencies, but I think it’s just a matter of time for people to adapt.
About the pipe-last operator, I think it is more accurate to say it is not recommended. There is no plan to remove it in the near future.
8 Likes