4 ms·

The problem isn't even code generation. It's the fact that the C preprocessor adopts the most retarded model one can possibly think of, text replacement. Read

by qsort 6y ago

The problem isn't even code generation. It's the fact that the C preprocessor adopts the most retarded model one can possibly think of, text replacement. Read the paragraph following point 3. in the following link, and laugh or cry (your choice): https://man7.org/linux/man-pages/man3/pthread_cleanup_push.3.html https://man7.org/linux/man-pages/man3/pthread_cleanup_push.3... Thinking in terms of strings of text instead of the abstract syntax tree is literally the roman numerals of computer science.

throwaway_pdp09 6y ago
To be fair you're rolling in the luxury of hindsight. It wasn't that log ago that a supercomputers had only a few MB of memory. Price US$7.9 million in 1977 (equivalent to $33.3 million in 2019) Weight 5.5 tons (Cray-1A) Memory 8.39 Megabytes https://en.wikipedia.org/wiki/Cray-1#Cray-1M https://en.wikipedia.org/wiki/Cray-1#Cray-1M in the 1970s. Dig up the spec of the PDP and be, well, something'd. Not sure what. Glad you were born now, I guess.
- qsort 6y ago
  Not sure how this is relevant to the topic at hand. Sure, there are many features of C that are easy to laugh at but in context make a lot of sense, but the macro system is not one of them. Hart/Levin LISP had hygienic macros, just saying... And you don't even need the full generality of a compiler to have limited but still useful AST-rewriting macros, there are a ton of ways this could be implemented very cheaply in terms of both memory and cpu, none of which are rocket science. Seriously, the fact that textual macros are terrible isn't even a controversial point. Maybe I'm too young to be a Real Programmer(tm), but this 'everything is text' idea never made sense to me.
  - deleted 6y ago
    [deleted]
  - Supermancho 6y ago
    > 'everything is text' idea never made sense to me. As a Programmer(tm), you spend more time debugging code (or specifically, reading it) than writing code. Everything as text makes this less painful than sussing it out of ASM behavior. It's a natural conclusion, given enough time.
  - renox 6y ago
    I don't know: debugging textual macro isn't fun but it isn't that hard either (provided you can convince your stupid build system to add a -E to your compiler flags), debugging AST macro sounds to me like debugging templates: a nightmare..
    - qsort 6y ago
      It's true that going down the macro rabbit hole is hardly ever a win, no matter how you handle it. But I don't buy that textual macros are really any better. For starters, they are impossible to reason about, because they can always involve action at a distance. Also you are completely giving up whatever type safety you have (which is admittedly not much in pure C, but better than nothing), and because cpp has no notion of what valid C looks like, your program could even compile without even printing a warning if you write a macro that's wrong just in the right way. There are cases where a simple textual macro is fine, and that's what the designers probably envisioned. But it's a slippery slope: because the macro system is there, it will be used, and because it will be used, it will shape how the language looks around itself.
  - AnimalMuppet 6y ago
    Lisp's syntax (or lack thereof) make it much easier to write a macro processor for than something like C, though. If your position is "They shouldn't have used something with that complicated a syntax", that might be a defensible point, but now we're not talking about the preprocessor.
    - qsort 6y ago
      My position is that the preprocessor (at least as far as textual substitution macros are concerned) was a mistake even considering the technical limitations of the time, unlike features like raw pointers, abundance of undefined behavior, void, etc., that are bad right now but were completely understandable (and likely even better than any other realistic alternative) at the time. constexpr + inline would have covered 99% of the macro use cases. Alternatively, a limited system of AST rewriting wouldn't have been significantly harder to write than cpp and would have achieved many of the same goals. As a totally random, non-factual, non-argumentative guess that could be 100% wrong, I believe the idea of the preprocessor was influenced by the general 'unix philosophy' principle that everything should be treated as text.
      - throwaway_pdp09 6y ago
        No offence but you're not recognising that things were very, very different. C was designed as a language for small sytems. It's used for ridiculously large and inapprpriate thinga now. The #include is terrible but it was ok back then - things were small enough to hold in your head. No longer. Compilers were simpler back when C was designed. IIRC PDPs often had just a few K of memory. A megabyte would be huge in the 80's. A textual preprocessor can be done in a couple of K I'd guess, or less. Also a preprocessor is useful for many other things unrelated to the C language. I understand your frustration but things started that way for a good reason, please don't criticise unless you really understand that. Feel free to criticise the inertia that means we have much the same stuff nearly half a century later (but also understand why).
Joker_vD 6y ago
POSIX.1 permits pthread_cleanup_push() and pthread_cleanup_pop() to be implemented as macros that expand to text containing '{' and '}', respectively. I'm sorry, what? Why would you permit that? On Linux, the pthread_cleanup_push() and pthread_cleanup_pop() functions *are* implemented as macros that expand to text containing '{' and '}', respectively. This means that variables declared within the scope of paired calls to these functions will be visible within only that scope. Yeah, and people call me a joker. But I wouldn't manage to invent this even if I tried to.
- qsort 6y ago
  To be fair that particular example isn't as terrible as it looks because that's (generally) the intended behavior. But yeah, this is the type of arcane bullshit that comes up all the times in system-level C programming. C is a great language, but the environment you find yourself programming in is layers upon layers of barely intelligible nonsense that nobody needs nor wants.

by qsort 6y ago

throwaway_pdp09 6y ago

To be fair you're rolling in the luxury of hindsight. It wasn't that log ago that a supercomputers had only a few MB of memory. Price US$7.9 million in 1977 (equivalent to $33.3 million in 2019) Weight 5.5 tons (Cray-1A) Memory 8.39 Megabytes https://en.wikipedia.org/wiki/Cray-1#Cray-1M https://en.wikipedia.org/wiki/Cray-1#Cray-1M in the 1970s. Dig up the spec of the PDP and be, well, something'd. Not sure what. Glad you were born now, I guess.

qsort 6y ago
Not sure how this is relevant to the topic at hand. Sure, there are many features of C that are easy to laugh at but in context make a lot of sense, but the macro system is not one of them. Hart/Levin LISP had hygienic macros, just saying... And you don't even need the full generality of a compiler to have limited but still useful AST-rewriting macros, there are a ton of ways this could be implemented very cheaply in terms of both memory and cpu, none of which are rocket science. Seriously, the fact that textual macros are terrible isn't even a controversial point. Maybe I'm too young to be a Real Programmer(tm), but this 'everything is text' idea never made sense to me.
- deleted 6y ago
  [deleted]
- Supermancho 6y ago
  > 'everything is text' idea never made sense to me. As a Programmer(tm), you spend more time debugging code (or specifically, reading it) than writing code. Everything as text makes this less painful than sussing it out of ASM behavior. It's a natural conclusion, given enough time.
- renox 6y ago
  I don't know: debugging textual macro isn't fun but it isn't that hard either (provided you can convince your stupid build system to add a -E to your compiler flags), debugging AST macro sounds to me like debugging templates: a nightmare..
  - qsort 6y ago
    It's true that going down the macro rabbit hole is hardly ever a win, no matter how you handle it. But I don't buy that textual macros are really any better. For starters, they are impossible to reason about, because they can always involve action at a distance. Also you are completely giving up whatever type safety you have (which is admittedly not much in pure C, but better than nothing), and because cpp has no notion of what valid C looks like, your program could even compile without even printing a warning if you write a macro that's wrong just in the right way. There are cases where a simple textual macro is fine, and that's what the designers probably envisioned. But it's a slippery slope: because the macro system is there, it will be used, and because it will be used, it will shape how the language looks around itself.
- AnimalMuppet 6y ago
  Lisp's syntax (or lack thereof) make it much easier to write a macro processor for than something like C, though. If your position is "They shouldn't have used something with that complicated a syntax", that might be a defensible point, but now we're not talking about the preprocessor.
  - qsort 6y ago
    My position is that the preprocessor (at least as far as textual substitution macros are concerned) was a mistake even considering the technical limitations of the time, unlike features like raw pointers, abundance of undefined behavior, void, etc., that are bad right now but were completely understandable (and likely even better than any other realistic alternative) at the time. constexpr + inline would have covered 99% of the macro use cases. Alternatively, a limited system of AST rewriting wouldn't have been significantly harder to write than cpp and would have achieved many of the same goals. As a totally random, non-factual, non-argumentative guess that could be 100% wrong, I believe the idea of the preprocessor was influenced by the general 'unix philosophy' principle that everything should be treated as text.
    - throwaway_pdp09 6y ago
      No offence but you're not recognising that things were very, very different. C was designed as a language for small sytems. It's used for ridiculously large and inapprpriate thinga now. The #include is terrible but it was ok back then - things were small enough to hold in your head. No longer. Compilers were simpler back when C was designed. IIRC PDPs often had just a few K of memory. A megabyte would be huge in the 80's. A textual preprocessor can be done in a couple of K I'd guess, or less. Also a preprocessor is useful for many other things unrelated to the C language. I understand your frustration but things started that way for a good reason, please don't criticise unless you really understand that. Feel free to criticise the inertia that means we have much the same stuff nearly half a century later (but also understand why).

Joker_vD 6y ago

POSIX.1 permits pthread_cleanup_push() and pthread_cleanup_pop() to be implemented as macros that expand to text containing '{' and '}', respectively. I'm sorry, what? Why would you permit that? On Linux, the pthread_cleanup_push() and pthread_cleanup_pop() functions *are* implemented as macros that expand to text containing '{' and '}', respectively. This means that variables declared within the scope of paired calls to these functions will be visible within only that scope. Yeah, and people call me a joker. But I wouldn't manage to invent this even if I tried to.

qsort 6y ago
To be fair that particular example isn't as terrible as it looks because that's (generally) the intended behavior. But yeah, this is the type of arcane bullshit that comes up all the times in system-level C programming. C is a great language, but the environment you find yourself programming in is layers upon layers of barely intelligible nonsense that nobody needs nor wants.