←back to thread

620 points tambourine_man | 1 comments | | HN request time: 0.341s | source
Show context
franga2000 ◴[] No.43750305[source]
I wish they added the same thing JS has, where this "string literal prefix thingy" can be user-defined.

html`<p>${value}</p>` will actually run the function html(template). This means you can use this to "mark" a function in a way that can be detected by static analysis. Many editors will, for example, syntax highlight and lint any HTML marked this way, same with SQL, GraphQL and probably some others too.

replies(2): >>43750403 #>>43751094 #
conartist6 ◴[] No.43750403[source]
For the record the JS thing desugars to the exact same as the Python thing, so it is no more or less safe to do the syntax highlighting in Python as it is in JS.
replies(2): >>43750893 #>>43751383 #
Timon3 ◴[] No.43750893[source]
It desugars similarly, but the Python version doesn't have a name. Any t-string is a t-string, there's no HTML t-string or SQL t-string or anything like that. It's just a t-string you can pass to a function:

    html_string = t"<something />"
    sql_string  = t"SELECT * FROM something"
In JS, the string has a prefix that can differ between languages, e.g.:

    const htmlString = html`<something />`
    const sqlString  = sql`SELECT * FROM something`
and so on. See the difference?
replies(1): >>43751396 #
masklinn ◴[] No.43751396[source]
Except your labels are incorrect because neither `html_string` nor `sql_string` are strings, they're both Template objects, and the sink function is the one which processes it. No processing has happened to them by the end of the snippet, beyond creating the template object itself.
replies(1): >>43751708 #
Timon3 ◴[] No.43751708[source]
Sure, choose different variable names, who cares. The essential difference is that the language is referenced at the declaration site, not the usage site, which makes the syntax highlighting far easier.

Please engage with my point instead of criticizing trivialities.

replies(2): >>43752287 #>>43752530 #
masklinn ◴[] No.43752287[source]
> Please engage with my point instead of criticizing trivialities.

Your complete misunderstanding of what's happening is not a triviality.

> The essential difference is that the language is referenced at the declaration site, not the usage site, which makes the syntax highlighting far easier.

Javascript has no built-in template tags beyond `String.raw`. If tooling has the capabilities to infer embedded language from arbitrary third party libraries, I would hope they have the ability to do utterly trivial flow analysis and realise that

    html(t"<something />")
means the template string is pretty likely to be HTML content.
replies(3): >>43752483 #>>43752566 #>>43752846 #
1. conartist6 ◴[] No.43752566[source]
Yes. It's a weak heuristic, but it's EXACTLY the same weak heuristic that JS is applying!

IN other words, since custom template tags in JS *are literally just function calls* when a JS environment syntax highlights the code as HTML it's doing so based on an extremely weak heuristic (the identifier for the interpolation function is named "html"). Both Python and JS have the same problem.