3 ms·

> 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.

• 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.
    • sklogic 11y ago
      > Because I care about soundness. And what's the problem with soundness? I can even derive formal proofs for simple DSLs when I have too. I never had any issues with mixing semantic properties of DSLs on any level of abstraction - and the higher the abstraction level, the easier it is to mix without caring at all about the underlying semantics. For example - I've got a generic PEG frontend language. I can mix it into nearly any combination of execution semantics, because it's high level enough, and it has an intermediate representation which can be trivially mapped into pretty much anything at a very little cost (because of simplicity of requirements). Why should I care about soundness of the whole mix while I can easily prove correctness of this very last step of translation, and this is enough to ensure the rest. > There are a ridiculous number of ways to combine these things in ways that totally kill type soundness, confluence, etc. Then do not combine these things in the unsound ways. As simple as that. For example, this is how I'm using Prolog embedded in an eager somewhat-functional host: the host DSL is used to define transforms over ASTs, including simple flattening transforms that derive sequences of equations (i.e., Prolog terms). Then the Prolog code is used to ask questions about these systems of equations. This way many typical internal compiler tasks are dead simple but yet reasonably efficient (and for some of the most important things I can even use Datalog instead, with all its cool optimisations). The only point where the Prolog world is interacting with the rest of the system is via these lists of equations, so I do not have to care how to reason about WAM interaction with a memory-managed eager functional semantics, all is well compartmentalised. > None of these three assumptions are true for most of the eDSLs engineers might want to write down in general. How is it so? Everything is still boiling down to one of the "fundamental" execution models. Higher level semantics are added as sequences of well-understood, provable, trivial transforms all the way down to such fundamental blocks, for which, as you said, we have at least 30-60 years worth of understanding. The very high level semantics are added independently of any fundamental blocks, with a transform to a specific execution model being added at the very last moment and it is always trivial enough. > a framework that lets you get unsound bullcrap from two perfectly sound things If the source language is sound, each of the target languages are sound, and all the transforms in between are sound, then the result is sound and robust. > isn't a solution to the (e)DSL problem In my practice it is a solution indeed. Every eDSL I design is dead simple in implementation and very rarely I have to add something new to my current toolbox. With problem domains ranging from 3D CAD applications to hardware design.