Ive actually considered something 'similar' to this a few times, as its not that hard to implement.
(depending on exactly what you want, as the topic is very 'general')
but I will point out the number of users interested in it, is probably very low ....
(for a similar reason I think the chances of getting documentation in this area is low priority, this is more likely 'roll your sleeves up' open source development 
)
there are a few (compatible) approaches.
i) write a compatible binary
assumes you don't want to use axo objects, because the DSL already has a code base (e.g oscillators, filters),
this is relatively simple , just look at what is generated by patch.java, to create xpatch.cpp
(examples, I've been considering are gen~/heavy (pd)/ faust)
ii) use an interfacing axo object
actually pretty much the same as (i) , but rather than generate an xpatch.cpp to compile, create an interfacing object. same usage as (i) . advantage is more resilient to changes in axoloti, and few disadvantages.
(this approach could also be done at the object level, e.g. to generate object that could be combined in the patcher. something id been considering for gen~)
iii) generate a patch (axp)
as @rvense said, you could generate a patch easy enough, is just a bunch of object instances and connections really. ok, it also allows embedded objects and patches now, so that complicates things a little, but not much.
would be reasonable compatible with future updates, as long as the patch format doesn't change.
real advantage is you can use all the objects that currently exist as axo objects, and of course its compatible with the axoloti UI for editing/debugging.
the disadvantage is really its just a wrapper around the axoloti patching, so your still following the same rules as the patcher (e.g. execution order) , but for a DSL wrapper thats probably no big thing... and if you need this, then i & ii are likely to be more suitable anyway.
none of its really hard, but probably only useful to a few users, and I suspect something we should not distract @johannes with, the Axoloti UI is excellent, and the concept of a graphical patching environment is a corner stone of Axoloti ... and what has attracted many users.
(this is my opinion only!)
one thing, I will probably do is make patches compile from the command line (and uploads), we already have a mode which kind of does this for testing purposes . just needs to be make it a bit more generic.
(its in Axoloti.java/Mainframe.java if your interested)
starting points, Id suggest:
- look at structure of AXP files
- look at/understand xpatch.cpp
- check patch.java, it generates xpatch.cpp
there are some other 'side' issues, related to how you might integrate things like parameters, but these are 'advanced' topics, which we can go into if you have the basics doing something interesting. (and are probably subject to change)
anyway, as I said, this is roll your sleeves up development, if someone gets part of it working, then I might have (limited) time to help out on issues encountered - but Ive not alot of time, as I'm busy on other things at the moment.
(though I admit, i loathe python... so your on your own if its in python )
