I discovered today that's actually an established practice: http://lambda-the-ultimate.org/node/2711. I haven't read any of the papers yet, but looking at the abstract of "Language Oriented Programming" by M. P. Ward, there does seem to be a difference between his idea and your approach with Arc and your other projects.
In the abstract, Ward defines Language Oriented Programming as defining a formal description of the language to develop the type of application in question, and then write the application in that language, and implement the compiler using existing tools.
The problem I see with this approach is that it's rare to know ahead of time what the ideal language for an application should look like. I don't think you're really going to know until you try to develop it. That's how the Arc approach differs. Particularly when you're already working in a language with rich meta-programming/code generation capabilities, I don't think there's any reason to have a strict separation of the phases. Even if you're not using a language with innate code generation, it's still possible to iterate back and forth between writing the application and changing the language/compiler
Keep in mind I haven't read the whole paper yet, or any of the related work, so the methodology might not be as strict as I've presented.
The common practice in Smalltalk is to just extend Smalltalk so that it becomes a powerful domain specific language for your application. Most everything in Smalltalk is just an ordinary message send (procedure call) so any good programming where you Don't Repeat Yourself ends up being a domain specific language.
