I was thinking about that but then again, SQL really is about as domain specific as it gets, then you'd have to put every other DSL in there as well... tricky choice.
The languages above are all 'stand alone', not application specific, in other words you could conceivably program anything in them, that's a little hard to do in SQL.
Using stored procedures it is turing complete, but I still doubt anybody ever wrote an application completely in SQL.
I have some horror stories I could share with you... I've rewritten more than one application where the entirety of the application was originally written in SQL (HTML presentation included) and then just emitted when the SQL was called.
I'd also argue that SQL isn't as much a DSL as I think you suggest, it's the de facto choice when programming on the data layer for any RDBMS (sure, the implementations may vary slightly, but if you're writing SQL that's often your only choice for a language at the DB level).
Ugh. That's as bad as some of the programs I've re-written to leverage SQL. Way too many resultset/for loop combos that took hours to run in Java or C# that turned into seconds with a little set-based thinking.
The languages above are all 'stand alone', not application specific, in other words you could conceivably program anything in them, that's a little hard to do in SQL.
Using stored procedures it is turing complete, but I still doubt anybody ever wrote an application completely in SQL.