Binding to Tagged template function

That would be a great solution for styled-ppx as well, but I’m entirely sure that neither graphqlppx neither styled-ppx wants to operate into template literals at run-time.

Maybe the comment made by @Hongbo about creating a new macro system can be influenced by this design?

1 Like


let foo = bar => baz`hello ${bar}!`


function foo(bar) {
  return "hello " + bar + "!";

How is this generated?

Basically in JS, tagged template

tag`blabla ${foo} bla`


tag(templateStrings, ...substitutions)

where substitutions.length == templateStrings.length - 1.

So in rescript you could make it call:

tag(templateStrings, substitutions)


let tag: (array<string>, array<'a>) => 'b

I totally get that it would require quite some changes to have correct error messages etc but it would erase the barrier with a whole set of JS tools. Bindings would be incredibly easy then since it would just need to write externals like:

@module("sql") @variadic external sql: (array<string>, array<sqlFragment>) => sqlQuery = "default"

this would allow easy interop with tools for GraphQL, styling, SQL and quite a lot of DSL.


Would the external declaration need to use @variadic for things to work correctly?

you’re right, I’ve edited the bindings.

1 Like

I made some progress on this today and was able to get the following code:

type sqlQuery
type sqlFragment = string
@module("sql") @variadic external sql: (array<string>, array<sqlFragment>) => sqlQuery = "default"

let table = "users"
let id = "5"

let query = sql`SELECT * FROM ${table} WHERE id = ${id}`
let jsStr = `SELECT * FROM ${table} WHERE id = ${id}`
let jStr = j`SELECT * FROM $table WHERE id = $id`

to compile to:

// Generated by ReScript, PLEASE EDIT WITH CARE
'use strict';

var Sql = require("sql").default;

var table = "users";

var id = "5";

var query = Sql([
      "SELECT * FROM ",
      " WHERE id = ",
    ], table, id);

var jsStr = "SELECT * FROM " + table + " WHERE id = " + id + "";

var jStr = "SELECT * FROM " + table + " WHERE id = " + id;

exports.table = table; = id;
exports.query = query;
exports.jsStr = jsStr;
exports.jStr = jStr;
/* query Not a pure module */

Interestingly, I only had to make changes to src/ in the syntax submodule.

There’s still some work to do (ensuring parse tree nodes have the proper locations, adding tests, etc.). I’ll post a link to the PR here once it’s ready.


I ran the tests in the syntax repo for the first time with these changes I ran into an issue with the printer tests. I have to update the printer to know how to convert the generate function calls back into tagged template strings. This should be possible by setting the res.template attribute on apply nodes generated from tagged template strings and then teaching the printer how to handle them.

1 Like

This is exciting @kevinbarabash , nice work!

Here’s a link to the PR: It’s still a work-in-progress.


Waiting so hard for this one :sweat_smile:

I juste love Styled-components :smiley:

Great work !!

I made some more progress today. There’s one failing test in the “roundtrip” tests that needs to be addressed but it shouldn’t be too much longer before the PR is done.

That being said, I would like to update the codegen in the compiler repo to produce tagged template literals in the JS output. As it stands right now and function call will be output. In order to simplify changes across the two repos, it would be best if we merged the syntax repo into the rescript-compiler repo. I’ll be investigating that next.

All of the tests are passing now including the “roundtrip” tests. :slightly_smiling_face:


I’ve replaced my original PR with a new one: This one includes changes to the frontend so that the JS we output uses a tagged template literal instead of a function call. The output now looks like:

// Generated by ReScript, PLEASE EDIT WITH CARE
'use strict';

var Sql = require("sql").default;

var table = "users";

var id = "5";

var query = Sql`SELECT * FROM ${table} WHERE id = ${id}`;

exports.table = table; = id;
exports.query = query;
/* query Not a pure module */

@kevinbarabash Hello, do you have any news about this PR ? I would really like to use tag template literals for producing my CSS (it’s way better than using ReactDomStyle :sweat_smile:).
And do you know, if this PR is merged in a repo, how can I use the repo containing this PR instead of the current one ?

Best regards, and thx for your hard work :wink:

I ended up closing the PR. Maybe someone else can pick up where I left off. The change required changes to the syntax so merging the syntax repo into rescript-compiler would make these kinds of changes easier.


Can we revive this if we make an RFC for the tagged template syntax? I believe merging the syntax repo into the compiler isn’t palatable to the core team.


I personally think supporting this would be very valuable. An RFC and some thorough discussion will probably be a great foundation for any contributor who might be interested in implementing the actual feature. Would you be up for formulating an RFC?


I’m willing to put one together. Thinking a few things at minimum are required to have a decent RFC ready for a healthy discussion.

  1. Enumerate a handful of use cases and examples to catch any edge cases
  2. Catch up on the exploration Kevin and members here have done and discussed. Eg: Binding to Tagged template function - #12 by Maxim. Identify path forward.
  3. Explore any alternative solutions and identify blockers, technical and otherwise
  4. ???
  5. Profit

Besides my list written in the rather early morning, is there a good RFC template? Looked at a few others RFCs shared in the forums. I’ll start the work in a GitHub issue, and reshare here. Like that many of the rfcs aren’t super formal.

I’ve never done any compiler work, so my mind begins at what the syntactical inputs are and what the generated code should be, and how the rescript AST can support differentiation between a tagged template literal and a normal template literal.

1 Like

Is this variadic design to account for typechecking somehow? Is it simpler and possible to compile it directly to JavaScript’s native tag template syntax?

I think you capture the important points. First we need to focus on what pain/problem we’re solving, how that problem looks in the wild, if there are current acceptable workarounds, etc. No need to discuss a solution just yet imo.

1 Like