Does ReScript support ppx / macros? If so, where is this documented ? If not, is this one area where ReScript diverges from OCaml ?
You will find a lot of interesting posts if you search for posts mentioning ppx
on this forum. There have been many, many, throughout the years, and you will even find posts from Hongbo (here is one example) and other team members discussing this question.
Just to make it clearâŚI think this is an interesting question. But the answer about the status of ppx, and whether it is encouraged, I think isnât too straightforward.
Iâm currently working through the manual: Pipe | ReScript Language Manual
It would be really helpful if someone with authority could add an official statement on ppx / macros to the reference manual.
Although digging through the forums is more efficient than digging through the source code, itâs really efficient if every new comer to ReScript has to dig through the forums to answer a basic question.
Iâm not disagreeing with you; there probably should be a stronger statement in the manual. There is this statement in the manual at least. And as for people with authority chiming in, again, they have in the forums. As to why some of it hasnât made it to the docs, I cannot say. But it may be worth opening an issue on the docs, if you think a stronger clarifying statement is needed than the one here provides.
Edit: it is currently the case that many âadvancedâ features arenât exactly covered in-depth the manual, but are discussed in the forums. So I think it is an explicit choice of those who have written the manual.
I mis-interpreted your original post as RTF-FP (read the âfriendlyâ forum posts), which was a bit annoying given I was working exhaustively through the manual.
However, upon further research, it does seem your advice is âoptimalâ in that ppx seems to be in this weird âpurgatoryâ of:
(1) it appears to be, at least in some form, supported in ReScript
(2) there appears to be no examples in the manual
(3) devs appear to strongly discourage its use (possibly due to reserving the right for future breaking changes?)
I will concede that in this case there is really no option besides reading the forum posts as it seems the issue is still being debated.
My apologies for not being clearer in my original post; it wasnât my intent to be dismissive of your question.
Not your fault, my fault. I incorrectly assumed (1) there was a simple answer and (2) you were telling me to RTFM, when in reality, (1) there was no simple answer and (2) the most âofficialâ statement was the link you provided. LOL.
In my experience a more âencouragedâ approach has been codegen. Itâs a bit more annoying to set up, but it doesnât depend on any compiler internals, so the team doesnât discourage it like they do PPX.
I personally havenât used it yet, but atdgen is probably the most successful pure codegen example in ReScript: GitHub - TheSpyder/bs-atdgen-generator: Pre-compiled versions of atdgen binaries to be consumed from ReScript projects
It generates JSON codecs from schema files.
There has also been discussion of SQL codegen, I havenât seen anything concrete for ReScript yet but sqlgg does exist in the OCaml world so we know itâs possible.
There is also GitHub - cca-io/rescript-react-intl-extractor: Extracts messages for localization from ReScript source files. by @cknitt.
This was a good starting point for a gql-schema generator we are working on at my company which is unfortunately closed source atm.
One day weâre hoping we can package up and provide a lot of the utilities and so on weâve built for the editor tooling. Would make for a pretty powerful base for building various codegen things when you need to tap into the syntax/AST or the actual type information produced by the compiler.
I started a code gen for sql. It works somehow, but I decided to start another approach, because I didnât like it.
For simplicity I just combined functions which produces string representations of rescript types. If I run the code e.g. ânode db_codege.bs.jsâ it prints the results to the console. Then I piped the output to a âdb.resâ.
If youâre interested⌠GitHub - dkirchhof/rescript-sql-typegen
To elaborate a bit:
We started our experiments to generate a gql-schema based on rescript types with writing a ppx, but we hit a couple of limits for our goal.
A completely separate generator, which parses the codebase has (for us) the most important benefit, that the generator is able to âknowâ about and optimize over the whole codebase. - instead of just the location where the extension was found.
Furthermore, we donât need the generator to run at every build. We can use watch with rescriptâs high performance and only run the generator when needed (or in ci).
It would be nice, if we (the community) could find some best practices on how to write generators for rescript.
I liked the idea, which @cknitt uses in his extractor to use extensions / âppx-notationsâ in the codebase but not registering any ppx for it in bsconfig. Therefore the compiler ignores these extensions during build. The generator (which parses the codebase) recognizes these extensions and acts on them.
Iâd love to discuss this more in depth (codegen in ReScript) because this is something Iâve spent a lot of time thinking about, and I have a lot of ideas. I also think itâd be valuable if we could come up with a good set of best practices, like you say @woeps, including the tooling/infra needed to do good codegen.
But, I feel this is starting to get slightly off topic @woeps maybe you could start a new thread detailing your thoughts (and your use case, it sounds interesting), and we can do a general discussion about codegen in ReScript and what we can do to make that a great experience?
@zth Iâll be happy to start a new thread, but it will take me some time to come up with a meaningful summary
Note: I havenât been following this since marking the problem as solved.
If it matters, as the OP, you have my permission to hijack this thread.