Surely syntax highlighting requires building an editor.

I'm not sure if you're talking about a dialect-specific editor or an editor specific to Blade. Still, I'll assume you're not talking about a Blade-specific editor, 'cause Blade isn't very specific. :-p There can be Blade-specific tools, but the point is for the specification format to be completely flexible.

If you mean that every new dialect would surely need a new editor to accomplish its syntax highlighting, I doubt that. We already have plenty of editors which can be configured for syntax highlighting. I expect a few of them can be scripted so that a single command saves the project, builds it, updates the configuration files based on the result, then finally reloads them and refreshes the highlighting. I haven't looked into it, though.

In any case, I do expect some dialects to be crazy enough that they really do require all-new editors. I guess GUI widget libraries are the main culprit here. But for the most part, I expect dialects to be built based on whatever's easiest to edit (and process) to begin with. For a content type like vector graphics where a non-text editor is pretty much necessary, I expect existing editors like Inkscape to be used, even if that means railroading the dialect into being a specialization of SVG or whatever the editors don't complain about.

---

I guess this is as good a time as any to say that I'm kinda in a rut with Blade. I was making Turbine, an Arc-like sublanguage meant to be a good foundational Blade language, and I got bogged down implementing Turbine completely in continuation-passing style. (My initial "Who cares how much pain the core of the language is when there's so much syntactic potential!" chutzpah only took me so far. :-p ) When I get working on Blade again, I expect the first thing I'm going to do is to port it to Arc, and the second thing will be to write some much-missed macros.

That, and hopefully I'll work out a kink in Turbine's design. Rather than having s-expressions as syntax, Turbine is going to have its macros receive complete information about where their forms are located in the project, so that they can go parse their bodies themselves.

At about the same time I started my Blade hiatus (coincidence?), I realized that with this approach, you couldn't simply have one macro form expand into another macro form. For instance, if [unless x ...] expanded into [when [no x] ...], then the 'when form wouldn't actually be in the project!