5 ms·

I've never liked macros... What attracts you to that feature, I'm curious?

rcxdude 3y ago
in most compiled languages you need something like them to get fully featured metaprogramming. It's not necessarily a case of liking them so much as they often become the best option. (note that C macros are a terrible implementation of macros, and yet despite that and the C++ committee hating them with a passion they are still often the only way to do certain things in C++, because the C++ committee has not sought to make better macros but attempt to extend other language features to accommodate some of their use cases.).
- preseinger 3y ago
  metaprogramming is not a virtue programming languages do not themselves need to be programmable
  - pjmlp 3y ago
    That is why stuff like m4 gets born.
  - rcxdude 3y ago
    My experience suggests otherwise. If the appropriate facilities don't exist in a language, users will resort to code generation.
    - preseinger 3y ago
      usually, code generation is preferable to metaprogramming, mostly because it is easier to understand and maintain
      - kazinator 3y ago
        Code generation is just external macros; it's the same thing in a worse form. To maintain the code, you have to understand the input language to the code generator and its metaprogramming constructs. You're no better off in that regard. The grandparent comment is saying that if you don't give people metaprogramming built-in, they will resort to outboard metaprogramming. I.e. you can't stop people from metaprogramming.
        preseinger 3y ago
        code generators are programs written in an existing programming language, which produce target language source code as output macros are programs written in a separate, unique, often turing-complete meta-language, which is implemented entirely in the compile phase of the language which supports them they're in no way equivalent
amno 3y ago
I guess you have never programmed in Lisp?
patterns 3y ago
If done right, a macro system allows you to make your language modular and experiment with new language features without having to change the core language and the compiler. With the macro approach, languages become libraries. The Racket people took this concept very far. The kernel of the language is very small and well defined. All Racket programs (or more precisely, expressions) are eventually reduced to a handful of syntactic core forms (see [1]). For example, thanks to forms such as (#%variable-reference id) you can specify rules for variable access, for example, w.r.t. life-time. With tools such as the Macro Stepper you can fully step through the transformations of any expression in your program, from the highest to the lowest level. This has numerous benefits. Extensions or modifications of the language can be rolled out (and used!) as libraries. This makes collaboration and testing far easier. Also, if a language feature turns out to be a bad idea, you deprecate the library. You do not have to change the compiler. This allows you to shrink your language and explore different directions without the burden of an ever growing language spec and implementation. Is it a perfect solution? No. Changing a widely used language always has big impact, but the impact can be compartmentalized and users of the language are given a graceful migration path by updating their libraries, at their choice and pace. Is Racket perfect? No, not by a long shot. But, frankly, language authors should at least take a look at the possibilities and consider the technological options for controlling the evolution of a language. https://docs.racket-lang.org/reference/syntax-model.html#%28part._fully-expanded%29 https://docs.racket-lang.org/reference/syntax-model.html#%28...
082349872349872 3y ago
cf https://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg02031.html https://people.csail.mit.edu/gregs/ll1-discuss-archive-html/... (this is PG's take, but IIRC the thread as a whole had some interesting ideas. Unfortunately Guy Steele's replies seem to have been under a different Subject: and haven't been threaded by the archive) Edit: HN to the rescue: https://news.ycombinator.com/item?id=9695323 https://news.ycombinator.com/item?id=9695323
zzo38computer 3y ago
Macros are very helpful for making many things. There are some problems with how macros are working in C, but it is also beneficial sometimes. One thing that C does not have something like METAFONT's "vardef"; if you have "scoped macros" that can be declared as global or local variables and as members of structures, it would cause less interference than the current system and can even sometimes provide other benefits too. Others include e.g. possibility for macros to define other macros (probably several other programming languages have such a thing), for appending to existing definitions (like {append} in Free Hero Mesh), for altering existing macros with a value calculated immediately instead of each time the macro is called (like {edit} in Free Hero Mesh), etc.

in most compiled languages you need something like them to get fully featured metaprogramming. It's not necessarily a case of liking them so much as they often become the best option. (note that C macros are a terrible implementation of macros, and yet despite that and the C++ committee hating them with a passion they are still often the only way to do certain things in C++, because the C++ committee has not sought to make better macros but attempt to extend other language features to accommodate some of their use cases.).

preseinger 3y ago
metaprogramming is not a virtue programming languages do not themselves need to be programmable
- pjmlp 3y ago
  That is why stuff like m4 gets born.
- rcxdude 3y ago
  My experience suggests otherwise. If the appropriate facilities don't exist in a language, users will resort to code generation.
  - preseinger 3y ago
    usually, code generation is preferable to metaprogramming, mostly because it is easier to understand and maintain
    - kazinator 3y ago
      Code generation is just external macros; it's the same thing in a worse form. To maintain the code, you have to understand the input language to the code generator and its metaprogramming constructs. You're no better off in that regard. The grandparent comment is saying that if you don't give people metaprogramming built-in, they will resort to outboard metaprogramming. I.e. you can't stop people from metaprogramming.
      - preseinger 3y ago
        code generators are programs written in an existing programming language, which produce target language source code as output macros are programs written in a separate, unique, often turing-complete meta-language, which is implemented entirely in the compile phase of the language which supports them they're in no way equivalent

amno 3y ago

I guess you have never programmed in Lisp?

patterns 3y ago

If done right, a macro system allows you to make your language modular and experiment with new language features without having to change the core language and the compiler. With the macro approach, languages become libraries. The Racket people took this concept very far. The kernel of the language is very small and well defined. All Racket programs (or more precisely, expressions) are eventually reduced to a handful of syntactic core forms (see [1]). For example, thanks to forms such as (#%variable-reference id) you can specify rules for variable access, for example, w.r.t. life-time. With tools such as the Macro Stepper you can fully step through the transformations of any expression in your program, from the highest to the lowest level. This has numerous benefits. Extensions or modifications of the language can be rolled out (and used!) as libraries. This makes collaboration and testing far easier. Also, if a language feature turns out to be a bad idea, you deprecate the library. You do not have to change the compiler. This allows you to shrink your language and explore different directions without the burden of an ever growing language spec and implementation. Is it a perfect solution? No. Changing a widely used language always has big impact, but the impact can be compartmentalized and users of the language are given a graceful migration path by updating their libraries, at their choice and pace. Is Racket perfect? No, not by a long shot. But, frankly, language authors should at least take a look at the possibilities and consider the technological options for controlling the evolution of a language. https://docs.racket-lang.org/reference/syntax-model.html#%28part._fully-expanded%29 https://docs.racket-lang.org/reference/syntax-model.html#%28...

082349872349872 3y ago

cf https://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg02031.html https://people.csail.mit.edu/gregs/ll1-discuss-archive-html/... (this is PG's take, but IIRC the thread as a whole had some interesting ideas. Unfortunately Guy Steele's replies seem to have been under a different Subject: and haven't been threaded by the archive) Edit: HN to the rescue: https://news.ycombinator.com/item?id=9695323 https://news.ycombinator.com/item?id=9695323

zzo38computer 3y ago

Macros are very helpful for making many things. There are some problems with how macros are working in C, but it is also beneficial sometimes. One thing that C does not have something like METAFONT's "vardef"; if you have "scoped macros" that can be declared as global or local variables and as members of structures, it would cause less interference than the current system and can even sometimes provide other benefits too. Others include e.g. possibility for macros to define other macros (probably several other programming languages have such a thing), for appending to existing definitions (like {append} in Free Hero Mesh), for altering existing macros with a value calculated immediately instead of each time the macro is called (like {edit} in Free Hero Mesh), etc.