TBH I don’t know. I guess it would require changes throughout multiple layers of the compiler. It’s more than parsing some syntax. (Could be totally wrong here)
How do you handle j and js tagged templates? It could be similar, right?
I’m still getting up to speed on ReScript internals so the following is based on my current and very incomplete understanding of how things work.
Caveat aside, modifying the parser shouldn’t be too difficult since ReScript already accepts the following:
let foo = gql`query {bar: ${bar}}`
It just ignores the gql
part since it isn’t j
.
The more difficult parts will be figuring out how to express tagged templates within the parse tree in such a way that they’ll be able to be type checked by the OCaml type checker. I think something where gql
is defined as template_string -> string list -> a'
or something like that.
This will also require that codegen to know gql
in the generate JavaScript should be called as gql(template_string, ...list)
.
It’s indeed as Kevinbarabash is saying.
The current sql`select * from users;`
syntax parses as the Pexp_constant
parse tree variant. So you would need:
- A new concept in the ast to express js tagged template literals.
- Make sure it doesn’t conflict with existing syntax like
j`string`
. - Have the type checker operate correctly on that new construct/encoding.
- Make sure error messages are good for the new construct/encoding.
- Modify codegen to emit the correct javascript code.
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?
today
let foo = bar => baz`hello ${bar}!`
generates
function foo(bar) {
return "hello " + bar + "!";
}
How is this generated?
Basically in JS, tagged template
tag`blabla ${foo} bla`
calls:
tag(templateStrings, ...substitutions)
where substitutions.length == templateStrings.length - 1
.
So in rescript you could make it call:
tag(templateStrings, substitutions)
where
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.
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;
exports.id = id;
exports.query = query;
exports.jsStr = jsStr;
exports.jStr = jStr;
/* query Not a pure module */
Interestingly, I only had to make changes to src/res_core.ml 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.
Here’s a link to the PR: https://github.com/rescript-lang/syntax/pull/471. It’s still a work-in-progress.
Waiting so hard for this one
I juste love Styled-components
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.
I’ve replaced my original PR with a new one: https://github.com/kevinbarabash/rescript-compiler/pull/2. 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;
exports.id = 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 ).
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
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.