> And? DSLs can have any syntax you like. And any type system you want.
While you're technically correct, as a practical matter you won't implement a type system/type checker for all the DSLs you create. (Nor do I believe you'll even do it for anything approaching a majority.). Obviously, I'm using the impersonal "you" here.
Implementing real type systems is hard and mostly rather tedious work.
I have a nice DSL which makes building complex type systems (including dependent) trivial and fun. So I do not mind adding typing to pretty much any kind of DSLs, including the smallest of them.
I still think you should have some links bookmarked to drop in conversations like this. Bookmarked so you can just type a name rather than waste time looking. Many in these discussions might think you're speculating or have some toy project rather than the interesting one I found digging through your old posts that backs up your claims.
Maybe even have a series of examples that illustrate solutions you keep mentioning so others can learn and apply them. Just a thought. :)
Actually I do have a such a framework [1], but this is not my point here. My point was that it's relatively trivial to implement such a collection of DSLs on top of pretty much any sufficiently powerful (i.e., CL-like macros) meta-language.
If you don't have a ready to use language construction framework targeting your meta-language, just build one. Easy.
As for typing specifically, the approach is rather fun and simple. Firstly, you'd need something like Prolog. It's really not that much, you can quickly build a passable implementation in just a couple of dozens of lines of code in pretty much any language. See miniKanren [2] for example. Then, any kind of typing is done easily: write a simple pass over your AST (may require some preparation passes, like resolving the lexical scope - but this is useful for all other things too), that will spit out Prolog equations for each expression node that needs typing. Then execute your Prolog code and get your types back. An implementation won't look any more complicated than a formal specification of a type system in a paper, using the type equations (as in [3]).
At this point "what is a language?" (or perhaps "what should a language be?") becomes a more than academic question. In a language with arbitrary macros one could potentially implement any language on top of that language. If we're using the term by analogy to human language, to my mind the key factor is the ability of implementations with no previous interaction to communicate (that is, how much can one express in a way that another will understand (and how deeply)). Arbitrary macros allow anything to be expressed, but it is very difficult for tools to understand the meaning of arbitrary code.
Of course. But, as I said, you don't have to restrict your macros, you only have to add a bit of a protocol on top of them in order to make them play nicely with all the tools.
And then you'll get the most powerful programming environment possible - building arbitrarily complex hierarchies of languages, with a cost of adding a new language being close to zero, and with a free support from all your tools, for no extra cost.
Actually, while building such a hierarchy I naturally came to a number of "restrictions", although they're not enforced. I prefer to build compilers using chains of very trivial transforms, each implemented with at most a total language (or a simple term rewriting for most of the cases). It also helps to maintain a nice interaction with the tools.
While you're technically correct, as a practical matter you won't implement a type system/type checker for all the DSLs you create. (Nor do I believe you'll even do it for anything approaching a majority.). Obviously, I'm using the impersonal "you" here.
Implementing real type systems is hard and mostly rather tedious work.
syntax-parse only gets you so far[1].
[1] https://docs.racket-lang.org/syntax/Parsing_Syntax.html