dang templating(?)

[abstract geode]

hrmmm yeah no builtins for that at the moment, for now my inclination is to keep writing the helper tool, and see if there's a viable pattern for writing escape hatches in other languages

[static plover]

1. Agreed

2. I may not need the generated helper in the end

[abstract geode]

@static plover I'm experimenting with something: https://github.com/vito/dang/pull/58

tl;dr Markdown-style fenced blocks which support ${interpolation}

the really nifty thing is you can also tag the code block with what syntax is, so you'll get embedded editor highlighting if your editor supports tree-sitter injections

what would be really cool is if this is good enough UX/DX for real source code templates w/ interpolation, but it's obviously more limited than e.g. text/template (it's JUST interpolation)

[static plover]

I would definitely use that... But would need support for also doing it from an external file (eg. for SDK init templates, I think I would still keep them in separate files, but I'm on the market for a standard interpolation syntax that I can just adopt.. Right now I have a go/template rendering helper and need to expose it as a module for all SDKs to use. If the core API had a builtin interpolation thing, I would adopt that instead)

I'm sure I would also use inline strings in many cases, when it's just not worth moving into a separate file

[abstract geode]

sounds good - I'll treat that as a separate issue for now then and try to get this form of string templates in for next release 👍

I'll be curious if the separate file is really needed, even just something dumb like a file that just defines one big fenced string value seems naively good enough for me (assuming you can use Dang itself as the 'templating' language), but we'll see how it plays out

[static plover]

It's just weird to edit a python file - or a go file, etc as a string inside a dang file.

[abstract geode]

sure but if it's being templated anyway it's not going to be any more valid than a string in a dang file, which will still have syntax highlighting, because of the language tag

[static plover]

Mmm, that's actually an argument for sticking to simple search-replace. With search-replace I can make the files valid

I think even if the files weren't fully valid go/js/python (but I agree it would be better if they were), I would still prefer them to be separate files, unless there is only one very small file in isolation. As soon as you start having a directory with more than one file, then IMO it gets exponentially ickier to have it embedded as a string

I just realized we already have search-replace on files in the core API 🙂 Maybe I just need search-replace in a directory as a convenience then I could use that in my sdk init templates? 🤔

(sorry kind of off-topic)

[abstract geode]

I guess i've just run into the opposite experience, where maintaining a bunch of separate files for individual templates can be more frustrating to edit and coordinate. but this is all so dependent on the specific situation that i won't pretend that experience overrides yours 😛

e.g. in Doug it was really nice to just embed system prompts etc. directly in the file

[static plover]

yeah it's a good sample of best practices out there. Both patterns co-exist and it makes sense for us to support both

[static plover]

Yeah that's a great example where I agree 100% embedded is better

[abstract geode]

tried out template strings for this and realized using Dang's template vars makes the embedded syntax highlighting break anyway. ended up using Dang's .replace for the same reason

I guess templating syntax highlighted code is just too much to ask even with Tree-sitter's fanciness. interestingly Go's parser doesn't choke as hard on {{foo}} vs. ${foo} but that's likely incidental and would just break in other languages anyway