[jk0ne]

Thanks.

It can. The cli can handle json5 (https://json5.org/) so trailing commas and comments are a-ok.

And yes, re: jayk. Almost certainly. :)

It has been an ambition of mine to turn this into a c lib to parse/process the syntax into an AST so it can be used in multiple languages... but I haven't been able to set the time aside for that particular batch of work, yet.

[jk0ne]

* it already does parse to an AST and caches the AST generated from an expression, so for a given expression the parsing is only done once, but that's just within Javascript. I would like to extract that out and have DTL libraries in multiple languages... but that whole 'day job' thing makes that a ways off, I expect. :D

[mst]

I've been thinking about problems like this quite a bit the past few years.

Notable that SQL::Abstract v2 goes from the DWIM syntax to an AQT (abstract query tree) that's pretty much always representable as JSON and then renders from there to SQL, with the intent to enable the front end and back end of such efforts to happen in completely different environments. (have a quick look at https://metacpan.org/pod/SQL::Abstract::Plugin::ExtraClauses for the stupid shit I've been able to pull off with that architecture)

Now sri has written mojo.js he's periodically trying to nerd snipe me to do a JS/TS implementation of that stack and honestly I'm getting increasingly tempted.

Meanwhile I'm working on a DSL host designed for config languages and also hopefully REPL-controlling-a-daemon type stuff which seems like it has a bunch of aesthetic similarities to your goals (like 'syntax only means one thing' which I was really pleased to see).

What I'm currently expecting to do for the DSL host thing is to have two primary production implementations (I'm currently focusing on a reference implementation that won't be either of them, as ever I tend to pick exceedingly hairy yaks) - one in golang for the "pure go is everything" people, and one in nim since that will hopefully get me reasonably performant C and javascript backends.

Whether any of this is actually a good idea is, of course, to be determined, but it's not like that's ever stopped me before.

[jk0ne]

The SQL::Abstract stuff is interesting. DTL has it's origins in needing to do a very similar thing - to be able to create a set of transformations and go back and forth between the real expression and a UI / object representing the action to be taken... and to make programmatic adjustments to them. Well, that and a stubborn refusal on my part to resort to `eval()` ;)

There were many times when I wasn't sure if DTL was a good idea, tbh. Thankfully, nearly every time I came close to abandoning it, something else came up that DTL made easy (Or, it forced me to fix something in DTL that prevented it from being easy.) I'm fairly confident it was a good idea at this point. Or if not good, at least useful. ;)