5 ms·
> 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 syst
by lomnakkus 11y ago
> 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.
syntax-parse only gets you so far[1].
[1] https://docs.racket-lang.org/syntax/Parsing_Syntax.html https://docs.racket-lang.org/syntax/Parsing_Syntax.html
- sklogic 11y agoI 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.
- nickpsecurity 11y agoI 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. :)
- sklogic 11y agoI am already slow-banned here (or whatever it is called). If I start spamming the links, they will suspend this account.
- deleted 11y ago[deleted]
- lomnakkus 11y agoJust trying to understand here: Are you saying that you have a meta-framework[1] for developing DSLs? If so, then I suppose I misunderstood you original claim, but I won't apologize because your claim was very opaque to anyone who doesn't know you. [1] An example of what I mean would be xtext.
- sklogic 11y agoActually 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]). [1] https://github.com/combinatorylogic/mbase https://github.com/combinatorylogic/mbase [2] http://minikanren.org/ http://minikanren.org/ [3] http://stackoverflow.com/questions/12532552/what-part-of-milner-hindley-do-you-not-understand http://stackoverflow.com/questions/12532552/what-part-of-mil...
- lmm 11y agoAt 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.