4 ms·

Exhibit B is still a DSL - just expressed in a syntactic manner that is compatible with C-style programming languages. In your example, each function like cat,

Exhibit B is still a DSL - just expressed in a syntactic manner that is compatible with C-style programming languages. In your example, each function like cat, or, and range would create an AST node, and you wold pass the result of the expression to an interpreter that executed the regex according to RE semantics. In this sense, the function call mechanism of the host language isn't being used in it's usual sense - that is for actually doing something. Rather, it's a way of declaring an AST similar to S-expressions (though slightly clumsier as you have to define each of these node-creating functions separately).

kerkeslager 9y ago
> Exhibit B is still a DSL - just expressed in a syntactic manner that is compatible with C-style programming languages. True, I suppose. But I think I can agree that you could also call the functions in Exhibit B a library. The difference, in my mind, is that Exhibit B gets you most of the benefits of Exhibit A without most of the implementation difficulty, because it avoids the trap of getting too caught up in syntax over semantics. There is a point where DSLs are used enough that implementing the syntax becomes worth it: there's a reason people implemented SQL and Regex. > In this sense, the function call mechanism of the host language isn't being used in it's usual sense - that is for actually doing something. Eh, I don't know about that. If you recognize that functions can be used in this way, it can quickly become a very powerful tool, even moreso if you're working in a language where those functions can return closures. Lots of code is written in this style. Of course nobody writes these specific functions because most languages support regexes. :)
- ohyes 9y ago
  A recursive descent parser to convert between A and B is trivial. But there are implementation details of functions vs code writing macros that are important. This is not about syntax at all.
  - kerkeslager 9y ago
    If recursive descent parsers are so trivial, why do we have so many DSLs to generate parsers? :P Also, a recursive descent parser isn't going to spit out an AST that matches the needed NFA/DFA, so there's going to be a transformation step needed.

kerkeslager 9y ago

> Exhibit B is still a DSL - just expressed in a syntactic manner that is compatible with C-style programming languages. True, I suppose. But I think I can agree that you could also call the functions in Exhibit B a library. The difference, in my mind, is that Exhibit B gets you most of the benefits of Exhibit A without most of the implementation difficulty, because it avoids the trap of getting too caught up in syntax over semantics. There is a point where DSLs are used enough that implementing the syntax becomes worth it: there's a reason people implemented SQL and Regex. > In this sense, the function call mechanism of the host language isn't being used in it's usual sense - that is for actually doing something. Eh, I don't know about that. If you recognize that functions can be used in this way, it can quickly become a very powerful tool, even moreso if you're working in a language where those functions can return closures. Lots of code is written in this style. Of course nobody writes these specific functions because most languages support regexes. :)

ohyes 9y ago
A recursive descent parser to convert between A and B is trivial. But there are implementation details of functions vs code writing macros that are important. This is not about syntax at all.
- kerkeslager 9y ago
  If recursive descent parsers are so trivial, why do we have so many DSLs to generate parsers? :P Also, a recursive descent parser isn't going to spit out an AST that matches the needed NFA/DFA, so there's going to be a transformation step needed.