4 ms·

Ok. Replace an optimising static BNF compiler macro with "classes" and "methods".

by sklogic 11y ago

lmm 11y ago
A lot of things that seem like they would need compiler support actually don't. Look at Spire.
- sklogic 11y ago
  With macros you've got a compiler support for anything you can imagine. And with macros you implement your DSLs as compilers, not interpreters, which is a huge advantage: you've got static verification, you've got any performance you like, and compilers are so much, much easier to implement than interpreters. So what's the point in doing the wrong, slow and error-prone thing instead of fast, easy and robust one? If you're talking about this spire ( https://github.com/non/spire https://github.com/non/spire ) than it's using generics (i.e., poor man macros) and some real macros too, apparently.
  - lmm 11y ago
    > With macros you've got a compiler support for anything you can imagine. Most of what you can imagine isn't useful or maintainable. Good tools should have more structure to guide you. > And with macros you implement your DSLs as compilers, not interpreters I'm not suggesting interpreters. If anything I'd say that macros - running arbitrary code at compile time - are more interpreterlike than what I'm describing. > it's using generics (i.e., poor man macros) Well if you're going to define every useful language feature as "macros" then of course you need macros to implement anything! But most of us consider generics to be different from macros.
    - sklogic 11y ago
      > Good tools should have more structure to guide you. It's not possible to have more solid and strict structure than with macro-based DSLs. > I'm not suggesting interpreters. You do. Either macros or interpreters. There is no other way. > are more interpreterlike than what I'm describing. You did not describe your approach to a problem yet. How would you implement an optimising BNF-based eDSL without macros? Spir and similar things are a totally different topic. > But most of us consider generics to be different from macros. Most people have absolutely no idea what metaprogramming is and how to implement DSLs properly. I would not refer to an opinion of a crowd.
      - lmm 11y ago
        > You did not describe your approach to a problem yet. How would you implement an optimising BNF-based eDSL without macros? Let's get more concrete. What does the business requirement look like? Do you mean "a language that happens to be expressed in BNF", or are you asking for a DSL for expressing languages which itself looks like BNF?
        sklogic 11y ago
        Let's imagine you want to embed parsers into your language. Choose any parsing algorithm you like, but parsers must be defined in a BNF-like syntax. You can go slow an buggy way (Parsec and alike), or you can compile your embedded BNF into a nice, verified, optimised implementation.
        lmm 11y ago
        > Let's imagine you want to embed parsers into your language. Choose any parsing algorithm you like, but parsers must be defined in a BNF-like syntax. Doesn't sound hard to do in (macroless) scala. Just create objects and methods with appropriate names - and for the optimization part just ensure everything is lazy and preserves the structure so you have the AST available in the language and can do your optimizations at that level (which doesn't have to mean interpreting - we can use the type system to perform these computations at compile time[1]). The syntax will probably end up being slightly differently punctuated from actual BNF, which is a tradeoff for having syntax that follows the ordinary rules of the language and is accessible to e.g. an IDE. I can agree that languages need to be able to perform complex transformations at compile time. But this doesn't have to be exactly the same kind as the compiler does itself, and as long as the language provides a sufficiently lightweight way of constructing an AST "in" the language, I think it's worthwhile making an explicit distinction between such ASTs and the AST of the language itself. [1] I can imagine you objecting that this is just a macro system by another name, but it isn't (except in the trivial sense of turing equivalence). It has a different grain: it's more natural to create companion trees that mirror the structure of the AST exactly, and less natural to transform the AST by moving nodes around. And any such companions are explicitly distinct from the "original" tree, and the structure naturally lets you see both.

Ok. Replace an optimising static BNF compiler macro with "classes" and "methods".

by sklogic 11y ago

Ok. Replace an optimising static BNF compiler macro with "classes" and "methods".

lmm 11y ago

A lot of things that seem like they would need compiler support actually don't. Look at Spire.

sklogic 11y ago
With macros you've got a compiler support for anything you can imagine. And with macros you implement your DSLs as compilers, not interpreters, which is a huge advantage: you've got static verification, you've got any performance you like, and compilers are so much, much easier to implement than interpreters. So what's the point in doing the wrong, slow and error-prone thing instead of fast, easy and robust one? If you're talking about this spire ( https://github.com/non/spire https://github.com/non/spire ) than it's using generics (i.e., poor man macros) and some real macros too, apparently.
- lmm 11y ago
  > With macros you've got a compiler support for anything you can imagine. Most of what you can imagine isn't useful or maintainable. Good tools should have more structure to guide you. > And with macros you implement your DSLs as compilers, not interpreters I'm not suggesting interpreters. If anything I'd say that macros - running arbitrary code at compile time - are more interpreterlike than what I'm describing. > it's using generics (i.e., poor man macros) Well if you're going to define every useful language feature as "macros" then of course you need macros to implement anything! But most of us consider generics to be different from macros.
  - sklogic 11y ago
    > Good tools should have more structure to guide you. It's not possible to have more solid and strict structure than with macro-based DSLs. > I'm not suggesting interpreters. You do. Either macros or interpreters. There is no other way. > are more interpreterlike than what I'm describing. You did not describe your approach to a problem yet. How would you implement an optimising BNF-based eDSL without macros? Spir and similar things are a totally different topic. > But most of us consider generics to be different from macros. Most people have absolutely no idea what metaprogramming is and how to implement DSLs properly. I would not refer to an opinion of a crowd.
    - lmm 11y ago
      > You did not describe your approach to a problem yet. How would you implement an optimising BNF-based eDSL without macros? Let's get more concrete. What does the business requirement look like? Do you mean "a language that happens to be expressed in BNF", or are you asking for a DSL for expressing languages which itself looks like BNF?
      - sklogic 11y ago
        Let's imagine you want to embed parsers into your language. Choose any parsing algorithm you like, but parsers must be defined in a BNF-like syntax. You can go slow an buggy way (Parsec and alike), or you can compile your embedded BNF into a nice, verified, optimised implementation.
        lmm 11y ago
        > Let's imagine you want to embed parsers into your language. Choose any parsing algorithm you like, but parsers must be defined in a BNF-like syntax. Doesn't sound hard to do in (macroless) scala. Just create objects and methods with appropriate names - and for the optimization part just ensure everything is lazy and preserves the structure so you have the AST available in the language and can do your optimizations at that level (which doesn't have to mean interpreting - we can use the type system to perform these computations at compile time[1]). The syntax will probably end up being slightly differently punctuated from actual BNF, which is a tradeoff for having syntax that follows the ordinary rules of the language and is accessible to e.g. an IDE. I can agree that languages need to be able to perform complex transformations at compile time. But this doesn't have to be exactly the same kind as the compiler does itself, and as long as the language provides a sufficiently lightweight way of constructing an AST "in" the language, I think it's worthwhile making an explicit distinction between such ASTs and the AST of the language itself. [1] I can imagine you objecting that this is just a macro system by another name, but it isn't (except in the trivial sense of turing equivalence). It has a different grain: it's more natural to create companion trees that mirror the structure of the AST exactly, and less natural to transform the AST by moving nodes around. And any such companions are explicitly distinct from the "original" tree, and the structure naturally lets you see both.