4 ms·
DING! This is what always happens. If you want to get useful manipulations done to code you'll eventually creep up to a Turing complete system. Now you have a t
by Faint 10y ago
DING! This is what always happens. If you want to get useful manipulations done to code you'll eventually creep up to a Turing complete system. Now you have a type system where you could calculate any program transformation, albeit in really really convoluted, slow and ugly way.
It would have been SO much better to give the language proper macros to begin with. I mean, a library that's actually meant for doing AST manipulations, and a way to tell the compiler "apply this transformation to that code before doing anything else with it", instead of another compiler-only interpreted language inside the original language. People would not have to learn 2 different syntaxes, and compilation would probably be faster (well I'm thinking more of heavily templating dependant C++ libraries here).
- curried_haskell 10y agoYo dawg, do you need a programming language inside your programming language?
- exDM69 10y agoYes. Otherwise you'll end up with an ugly Python or Perl script that generates code, coupled with ugly build system hacks to make it work. This will happen sooner or later.
- DonHopkins 10y agoThe Java culture fetishizes code generation. It's like somebody decreed "We want to take over the world, and one measure of that is lines of code. So there should be a hell of a lot more Java code: start writing Java code that generates more Java code!"
- acjohnson55 10y agoGo culture, too, for that matter.
- LnxPrgr3 10y agoHow else are you going to do stuff like this? https://github.com/phresnel/metatrace https://github.com/phresnel/metatrace I'm just sad that Java's accidental compute system managed to be uglier (and apparently far less useful) than C++'s. The language could use some accidental features to counter the lack of intentional ones.
- gpderetta 10y agoAST Macros are useful for AST level manipulation, but the problem is that usually at that point you do not have full type information (name resolution or even type inference hasn't run yet), so they can't take decision depending on types which is sometime what you want. C++-like templates can be seen as type level macros (or rewrite rules) and run with full type information.
- lmm 10y agoI very much disagree. Even if they've ended up accidentally Turing complete (which, don't get me wrong, is bad), they at least guide you towards the right thing to be doing at compile time: simple, declarative transformations. I have never seen a macro system that wasn't immediately abused for unmaintainable clever-clever things, whereas this has only emerged ~10 years after Java introduced generics.
- Faint 10y agoWhat if, there was a in standard "macro" library of the language * easy and standard way of doing the most often used things (like replacing type identifier with another) * automatic handling of what-stuff-came-from-which-line of code, to facilitate better error reporting by that macro library * honest to god stack trace from the macro library if it falls flat on it's face I mean, if you've ever seen errors that C++ compilers gurgle out from heavily templated code, I don't imagine macro library being any worse off a priori. Basically, when the compiler puts out a 3 screen error message, it's almost always much faster to just eye which lines it's referring to and read the code, than trying to decipher what the error message is actually trying to say... Trying to avoid Turing completeness ends up introducing new concept/syntax to the language every time there is a need to do something that could not be done before. It ends up bloating the base language making it hard to reason about, and remember how every nook and cranny work/interact. That's why the "simple core language + macros" -kind of approach holds appeal to me. I'd rather see a comprehensive standard library as a cure for lack of standardization (not being able to read other peoples code) than base language that just keeps getting more and more complex with time. Then again, maybe I'm just naive, I've only worked in small teams or alone.
- lmm 10y agoC++ is a spectacularly bad example, it's not always like that. > * easy and standard way of doing the most often used things (like replacing type identifier with another) I think you're talking about a conventional type system, or something close to it. > I mean, if you've ever seen errors that C++ compilers gurgle out from heavily templated code, I don't imagine macro library being any worse off a priori. Basically, when the compiler puts out a 3 screen error message, it's almost always much faster to just eye which lines it's referring to and read the code, than trying to decipher what the error message is actually trying to say... Honestly I think the biggest problem with macros is the compiler/tooling side - if you allow compilation to just run arbitrary code that does whatever, there's no structure for the tools to make use of. I would agree that compilers need to make error handling a lot more first-class and offer good support for that kind of use case. Rust is a positive example, with a lot of emphasis on good compiler errors - needed because they know how hard it is to satisfy their borrow checker. It would be great to apply that same level of support to errors from custom code (and really there's no reason Rust-style ARM couldn't be ordinary library functions in a language with good high-level constructs - you can use monadic regions to express the same behaviour).