3 ms·

What 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 wi

by Faint 10y ago

What 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 ago
C++ 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).

by Faint 10y ago

lmm 10y ago

C++ 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).