This is a great first implementation, but I'm not sure that desugaring in parser is the best choice here :/
We talked about it at a meeting when #722 was created, but I don't remember what we agreed on.

Personally, I'd much rather see templates up until the transformation to core so that we can:

• have reasonable error messages in typer
• later on resolve typeclasses or something for the splices
• possibly have a more performant impl (?)

Personally, I'd much rather see templates up until the transformation to core so that we can:

• have reasonable error messages in typer
• later on resolve typeclasses or something for the splices
• possibly have a more performant impl (?)

You raise some very good concerns and I completely agree. I will try to go the 'non-lazy route' and I actually completely thread through templates to core.

Don't get me wrong, having a version is still super helpful; I truly have no idea how difficult it really is to do the thing I outlined above. But I hope it's worth it, especially wrt technical debt. :)

I am not completely against desugaring in parser, but maybe we could actually desugar

"foo ${exp1} bar ${exp2} baz"

to something like:

splice(["foo ", " bar ", "baz"], [exp1, exp2])

this way, as a user I can still overload splice for types other than exp1 exp2: String :) Not that don't have enough overloaded functions already...

I just pushed a prototype that threads through string templates all the way until code generation.

This has the added benefit that we remain somewhat flexible for later changes, as Jiří mentioned. Furthermore, we can re-use the string interpolation capabilities of each respective backend, e.g. currently the JS string templates are generated as template literals. As a trade-off, we need to add a TemplateStr AST node to Core, CPS and to each backend. As I have already heard, not everybody is a proponent of further expanding Core ;)

Note: I currently only fully implemented it for JS. If we come to an agreement that this is the right way to proceed, I will implement for the remaining backends.

(I already started working on this before Jonathan's remark and I'd rather discuss this implementation briefly before scrapping it right away :) )

I am not completely against desugaring in parser, but maybe we could actually desugar

"foo ${exp1} bar ${exp2} baz"

to something like:

splice(["foo ", " bar ", "baz"], [exp1, exp2])

this way, as a user I can still overload splice for types other than exp1 exp2: String :) Not that don't have enough overloaded functions already...

This relates to some strategy we'll need to come up with in order to represent custom string interpolators (which is very outside of the scope of this PR, I believe...)

Then I'd expect some desugaring like, for example:

val name = "Joe"
val age = 42

////

val s: SQL::Stmt = 
  sql"SELECT * FROM Person p WHERE p.last_name = ${name} AND p.age = ${age}"

// ~>

val s: SQL::Stmt = sql { // sql: { prog: () => Unit / { Splice[String], Splice[Int] } }: SQL::Stmt
  do literal("SELECT * FROM Person p WHERE p.last_name = ")
  do splice(name)
  do literal(" AND p.age = ")
  do splice(age)
}