3 ms·

To avoid this issue DSLs must be highly modular, which is easily achivable if you're implementing them as eDSLs on top of a meta-language (i.e., mixing DSLs is

by sklogic 11y ago

To avoid this issue DSLs must be highly modular, which is easily achivable if you're implementing them as eDSLs on top of a meta-language (i.e., mixing DSLs is trivial and interop is not a problem).

bbrazil 11y ago
I'm not following you. I'm thinking of things like https://github.com/prometheus/prometheus/issues/482 https://github.com/prometheus/prometheus/issues/482 where core elements of a language don't behave in a predictable manner (in this case == has two distinct modes). That's a simple example, more structural issues can be compound by workarounds and lead to a lot of complexity growing over time.
- sklogic 11y ago
  In order for DSLs not to evolve into a mess they must be made of high quality semantic components, which you simply mix together and alter syntax a bit in order to get a new DSL. When you develop your DSLs this way the problems you're talking about are nearly impossible to run into. Essentially, if you build DSLs on top of an elaborate hierarchy of DSLs, every single DSL adds only a tiny bit of functionality which makes it maintainable and protects from evolving into a pile of messy layers. If you have any questions about technical details of this approach - feel free to ask.
  - nmrm2 11y ago
    > they must be made of high quality semantic components, which you simply mix together > the problems you're talking about are nearly impossible to run into. If you mean this in any non-fluffy sense, such a property would depend upon the set of semantic components having some incredibly strong properties. It's not clear to me that those properties don't immediately conflict with the entire point of creating DSLs -- that the host language's semantic model isn't the one you want. You can probably get trivial properties about the static semantics without a ton of machinery, and more dynamic properties might be possible to read off from very constrained examples. But it's entirely unclear to me why semantic models should easily combine without creating unintended behavior. Could you share some concrete examples?
    - sklogic 11y ago
      > such a property would depend upon the set of semantic components having some incredibly strong properties. Why? You can have as many semantic building blocks as you like. My current tool belt contains, among the others, a generic high performance imperative backend, generic functional backend, generic typing engine (which easily include various Hindley-Milner implementations as well as simple type propagation forms), generic lazy functional, generic Prolog and Datalog - these are the low level semantic building blocks which can be mixed together in any proportion. On top of them there is a large hierarchy of high level building blocks, which include, for example, generic optimisation components (e.g., IR-agnostic SSA-based optimisations), generic parsing frontends, data representation and transformation languages, and many more. > But it's entirely unclear to me why semantic models should easily combine without creating unintended behavior. Why would they? As long as the interop rules are clear, there is no problem in mixing different things together. > Could you share some concrete examples? Take a look at my github repo (linked in some other comments, do not want to keep spamming it).
      - nmrm2 11y ago
        > Why? Because I care about soundness. And especially soundness for combinations of under-specified semantic models, because eDSLs are useful exactly when the semantic models at hand aren't 30-60 years old with mature implementations. > imperative backend, generic functional backend, generic typing engine (which easily include various Hindley-Milner implementations as well as simple type propagation forms), generic lazy functional... which can be mixed together in any proportion. That's just so totally not true. There are a ridiculous number of ways to combine these things in ways that totally kill type soundness, confluence, etc. The reason you didn't have a hard time combining them is because they are 1) really truly extraordinarily well-understood and well-defined languages; 2) we've known exactly how to combine these things for a really long time; and 3) you knew a priori the reasonable interaction points. None of these three assumptions are true for most of the eDSLs engineers might want to write down in general. In general, a framework that lets you get unsound bullcrap from two perfectly sound things isn't a solution to the (e)DSL problem.

by sklogic 11y ago

To avoid this issue DSLs must be highly modular, which is easily achivable if you're implementing them as eDSLs on top of a meta-language (i.e., mixing DSLs is trivial and interop is not a problem).

bbrazil 11y ago

I'm not following you. I'm thinking of things like https://github.com/prometheus/prometheus/issues/482 https://github.com/prometheus/prometheus/issues/482 where core elements of a language don't behave in a predictable manner (in this case == has two distinct modes). That's a simple example, more structural issues can be compound by workarounds and lead to a lot of complexity growing over time.

sklogic 11y ago
In order for DSLs not to evolve into a mess they must be made of high quality semantic components, which you simply mix together and alter syntax a bit in order to get a new DSL. When you develop your DSLs this way the problems you're talking about are nearly impossible to run into. Essentially, if you build DSLs on top of an elaborate hierarchy of DSLs, every single DSL adds only a tiny bit of functionality which makes it maintainable and protects from evolving into a pile of messy layers. If you have any questions about technical details of this approach - feel free to ask.
- nmrm2 11y ago
  > they must be made of high quality semantic components, which you simply mix together > the problems you're talking about are nearly impossible to run into. If you mean this in any non-fluffy sense, such a property would depend upon the set of semantic components having some incredibly strong properties. It's not clear to me that those properties don't immediately conflict with the entire point of creating DSLs -- that the host language's semantic model isn't the one you want. You can probably get trivial properties about the static semantics without a ton of machinery, and more dynamic properties might be possible to read off from very constrained examples. But it's entirely unclear to me why semantic models should easily combine without creating unintended behavior. Could you share some concrete examples?
  - sklogic 11y ago
    > such a property would depend upon the set of semantic components having some incredibly strong properties. Why? You can have as many semantic building blocks as you like. My current tool belt contains, among the others, a generic high performance imperative backend, generic functional backend, generic typing engine (which easily include various Hindley-Milner implementations as well as simple type propagation forms), generic lazy functional, generic Prolog and Datalog - these are the low level semantic building blocks which can be mixed together in any proportion. On top of them there is a large hierarchy of high level building blocks, which include, for example, generic optimisation components (e.g., IR-agnostic SSA-based optimisations), generic parsing frontends, data representation and transformation languages, and many more. > But it's entirely unclear to me why semantic models should easily combine without creating unintended behavior. Why would they? As long as the interop rules are clear, there is no problem in mixing different things together. > Could you share some concrete examples? Take a look at my github repo (linked in some other comments, do not want to keep spamming it).
    - nmrm2 11y ago
      > Why? Because I care about soundness. And especially soundness for combinations of under-specified semantic models, because eDSLs are useful exactly when the semantic models at hand aren't 30-60 years old with mature implementations. > imperative backend, generic functional backend, generic typing engine (which easily include various Hindley-Milner implementations as well as simple type propagation forms), generic lazy functional... which can be mixed together in any proportion. That's just so totally not true. There are a ridiculous number of ways to combine these things in ways that totally kill type soundness, confluence, etc. The reason you didn't have a hard time combining them is because they are 1) really truly extraordinarily well-understood and well-defined languages; 2) we've known exactly how to combine these things for a really long time; and 3) you knew a priori the reasonable interaction points. None of these three assumptions are true for most of the eDSLs engineers might want to write down in general. In general, a framework that lets you get unsound bullcrap from two perfectly sound things isn't a solution to the (e)DSL problem.