3 ms·
I've been thinking a lot about source code transformations as a possible key for maintenance in the "future" of programming. Its interesting to see that the pre
by aconz2 11y ago
I've been thinking a lot about source code transformations as a possible key for maintenance in the "future" of programming. Its interesting to see that the preprocessor, which is a source code transformation itself, makes other source code transformations much more difficult, if not intractable. I'm wondering if this inherent to any macro system since they are not bijective.
Two possible directions I see away from macros which would play nicely with source code transformations are un-macros and layers of languages.
Un-macros would take source and display it in the condensed form only for human reading -- this takes away from human writing power of course, which may have to get pushed into the editor. This could also allow for automated pattern discovery.
Layers of languages would look similar to Racket's #lang concept and current macro systems, but without the ability to escape back into the parent language. This creates a new language on top of -- not mixed into -- the parent language.
- lmm 11y agoI wonder if the right option is to push the macro-like functionality down into the language itself. Something like http://okmij.org/ftp/Computation/free-monad.html http://okmij.org/ftp/Computation/free-monad.html starts to offer very macro-like functionality, but deferred to runtime, so you can still look at the original value and even imbue its effects with a different set of semantics.
- amyjess 11y agoOr something similar to Nim's metaprogramming features. Nim's templates and macros are wonderful.
- lmm 11y agoDo Nim macros enforce reversibility? If not, they're no better than C++ ones in this regard. Everything I read about Nim has the whiff of propaganda; tell me what it does better rather than just telling me it's good.
- aconz2 11y agoAre Nim's metaprogramming features fundamentally different than C++?