4 ms·
I agree. As this comment said: https://news.ycombinator.com/item?id=36858774 https://news.ycombinator.com/item?id=36858774 and I glossed over in "two different
by noelwelsh 3y ago
I agree.
As this comment said: https://news.ycombinator.com/item?id=36858774 https://news.ycombinator.com/item?id=36858774 and I glossed over in "two different ways that have different tradeoffs", the data vs codata approach gives you orthogonal extensibility. (Note the original article didn't talk about extensibility at all.)
In a DSL context you usually want new transformations (debuggers, pretty printers, etc.) on a fixed language. For this the FP / data approach is ideal.
In some cases you want fixed transformations on an extensible language. An example is a visualization DSL. There are limitless visualizations but the operation you want to use on them is always the same: draw it. For this the OOP / codata approach is ideal.
So choose the implementation technique that best suits your problem domain (and your implementation language.)
- js8 3y ago> An example is a visualization DSL. Interesting. I would say, this is not a DSL, but rather co-DSL. I can't really provide a formal definition right now, but I feel like primitives of DSL compose in the input of the evaluation function, while the primitives of co-DSL compose in the output of the evaluation function. In both cases, the evaluation function is fixed by the DSL's implementation. That's why DSL has a syntax tree (on input), but co-DSL has a tree of output widgets.
- noelwelsh 3y agoThis feels like an interesting idea but I can't quite fully see it. If a DSL is: AST -eval-> Result where AST is fixed and Result varies (depending on the choice of eval). Then a coDSL is AST -eval-> Result where AST varies and Result is fixed ? This feels like a restatement of the difference in modularity / extensibility.