Remix clone Hacker News

You don't have to add HTML validation to your processing func, but you brought up invalid syntax up as an issue with string templating.

> The whole thing is wrongheaded; exactly the kind of stove-pipe people end up inventing when they don't have metaprogramming.

Python has many metaprogramming features. I don't think you understand this feature much less its motivation.

How else would you go about adding language support for e.g. HTML and SQL within Python?

▲ kazinator 8 days ago | parent [-]

On the contrary, I implemented a substantial facsimile of it in a Lisp dialect yesterday; see my comment history.

  1> (load "template")
  nil
  2> (let ((field "name") (table "customers"))
       (te `SELECT @field FROM @table`))
  #S(template merge #<interpreted fun: lambda (#:self-0073)> strings #("SELECT " " FROM ")
              vals #("name" "customers"))
  3> *2.(merge)
  "SELECT name FROM customers"
  4> [*2.vals 0]
  "name"
  5> (set [*2.vals 0] "id")
  "id"
  6> *2.(merge)
  "SELECT id FROM customers"
  7> (upd *2.vals (map upcase-str))
  #("ID" "CUSTOMERS")
  8> *2.(merge)
  "SELECT ID FROM CUSTOMERS"

Unlike template strings, it was done in the language. There already are quasi-strings in the form of `...` syntax. We can quote that syntax (e.g. implicitly as a macro argument) and then pull apart its pieces to construct an object. It should work even in a years-out-of-date installation of the language. No new tooling is required; no changes to syntax highlighting in the editor, nothing.

It's a parlor trick that doesn't have any uses. The structured log messages use case is the most promising, because it has a consumer which actually wants the interpolated pieces that it would otherwise have to hackily parse out.

I predict that Python will eventually get dedicated HTML syntax: perhaps something that uses indentation to indicate element nesting. Let's "vibe pseudocode" a sketch:

   html:
     div (class='main' id='1'):
       p:
         "paragraph text"

or whatever.

▲ pphysch 8 days ago | parent [-]

> Unlike template strings, it was done in the language.

This is a disingenuous way to compare a LISP with a language that values syntactic convention and strives to be readable and maintainable by more than one person.

> I predict that Python will eventually get dedicated HTML syntax:

How do you assign this result to a variable? How is this any better than

    content: HTML = t"<p>Hello {name}</p>"

	▲	kazinator 8 days ago \| parent [-]
		It's a true statement; I made a usable construct that causes template strings to be turned into objects, rather than to perform the string substitution. I did it without changing any syntax, or have to ship a new version of the language. Python has to ship a new version for this; there is no way for existing installations to use the code. I don't have to change anything in my editor setup. So who is it that values syntactic convention? t"abc" is a syntax errror in vast numbers of existing Python installations; how can we call it convention? > How do you assign this result to a variable? That's to be worked out. The "html:" fantasy construct could have a way to do that. When you think of assigning to a variable, the first thing that comes to mind is "a = b" syntax. But, look, the define construct in Python also assigns to a variable: `define fun(arg): ...` The imagined html construct could have arguments like to assign an object to a variable, or just spin out textual HTML into a specified stream. I don't want to get into it, but there are obvious ways it could be done such that it hits all sorts of requirements. > How is it any better It renders all of the following problems unrepresentable: mismatched angle brackets, mismatched or unclosed tags, bad attribute syntax, injection.