New approach to Decl

I came to Decl from the wrong direction, last time.

My original thought was to build wxWidgets stuff in a way that didn't kill the beauty in my soul, and it kinda worked - but there was a lot of work involved, so I got distracted by some other shiny stuff like PDFs and Word documents and went off doing it.  What I ended up with was a clunky interpreter instead of a semantic description language.

What I should have done instead was, well, a semantic description language.  I've been giving some thought to that lately, because spring means it's time to start new things, or bring old ones back to new life.

What occurs to me is:

• The basic parser into a data structure is a good thing.  Let's keep that.  Tags, good.  Parameters, good (maybe drop the distinction between options and parameters because I couldn't keep them straight anyway).  But the basic idea is good: a set of nested tags describing arbitrary structure that can then be mapped onto programming constructs, the tags representing nouns instead of the verbs we see in non-declarative programming.
• The semantics of tags need to be represented more explicitly.  I did a lot of dancing around trying to map tags onto concepts behind the scenes, and it was unmanageable.  Instead, I should explicitly state a mapping - as an appendix or footnote.
• Yeah, you heard me.  We've developed an entire structure of documentation over centuries that is used to address semantic complexities by using out-of-band channels to clarify ambiguity or add information that could be distracting to the flow of presentation.  Why should everything be linear in source code?  Because it's easier for the compiler to understand?  Balderdash.  This is really close to where Knuth is going with literate programming - but Knuth worked with compiled languages, and I don't.  I don't want to respect identifier uniqueness; my compiler should get from context what I mean.  Knuth worked at too low a level.  It's time to kick it up a notch.
• I should be able to use citations, too, to include semantic presentation that bears on a given solution topic.  Citations here are just ("just") libraries - or macros.  Boilerplate and templates.  APIs to external functionality.  CPAN modules.  Anything that has already been worked out to address a solution space, can be a cited reference.
• Decl, although written in Perl, should not be Perl-bound.  Ideally I should be able to use Decl to define a program in any language, or to define it in several languages at once.  I should be able to use the same framework to use NLTK or data science stuff in Python, describe machine learning algorithms in Octave or R, define modules for CPAN, spin out a Web app in JavaScript, or write low-level things in C or assembler. Decl should be an approach, not a chain.  The first time around, it was an interpreted language written in Perl.  That was wrong.  Decl should actually be a compiler - maybe a compiler on the fly, but still a compiler.

How's that for an Easter resolution?