cottrell@nbs-vms.ARPA (01/30/85)
That's part of programming. What do you think the macro capability is there for? Macros are merely inline subroutines. Are you saying we should not use ban 'JSR' instructions too? The net effect is that we have to look elsewhere to see what is happening. > Furthermore, developing macros can make an assembler look more > structured and introduce some higher-level concepts, but it normally > makes the code produced LESS good than hand coding. If that is true, how can a compiler produce better code than by hand? High level languages are in a sense complex macros. Anyway, your code is probably I/O bound. */
cottrell@nbs-vms.ARPA (01/30/85)
[eat me] /* I got bitten by the line eater, so I'll post this again... > > > For the bare language, I might agree. However, any macro programmer > > >worth the name after a year or so will have developed a set of macros > > >that enable high level constructs but still allow precise control of > > >the machine. I personally have a set of macros that give me more > > > > AAAARGH!!!!! One of the most common complaints I hear from those > > who must maintain code is that the programmer had developed his own > > personal language out of macros. THIS DOESN'T MAKE CODE EASIER > > TO MAINTAIN, IT MAKES IT FAR, FAR, HARDER. > > Case in point: ever tried to work on the Bourne shell code? It helps to > know a little of the syntax of ALGOL 68. Of course, not even the mighty > cpp can transform C into ALGOL 68, so what you get is a unique language. > That's the problem with these sets of macros mentioned by >>: each one is a > different language with different characteristics (and bugs). A compiler > is just a clever macro-processor for a specific set of macros, with the > macros usually optimized so that they're expanded by inline code instead of > interpretively. > -- > Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 > ...Keep your day job 'til your night job pays. I hate to disagree with a fellow deadhead but... That's part of programming. What do you think the macro capability is there for? Macros are merely inline subroutines. Are you saying we should not use ban 'JSR' instructions too? The net effect is that we have to look elsewhere to see what is happening. The Bourne Shell code is nontrivial anyway. I support some of Bourne's macros as an attempt to fix C (yes I can criticize it) to require an explicit END statement for IF, FOR, WHILE, SWITCH, & DO. I find this model more robust than the 'next statement' construct, which can bite you by matching else's with the wrong if, and require addition of braces when adding the second statement to a clause. In practice, tho, I rarely get hurt by this, and a sufficiently paranoid hacker can always use the braces. > Furthermore, developing macros can make an assembler look more > structured and introduce some higher-level concepts, but it normally > makes the code produced LESS good than hand coding. If that is true, how can a compiler produce better code than by hand? High level languages are in a sense complex macros. Anyway, your code is probably I/O bound. "Going where the climate suits my CODE" */
jab@uokvax.UUCP (02/03/85)
/***** uokvax:net.lang.c / brl-tgr!cottrell / 12:01 pm Jan 30, 1985 */ > > > > For the bare language, I might agree. However, any macro programmer > > > >worth the name after a year or so will have developed a set of macros > > > >that enable high level constructs but still allow precise control of > > > >the machine. > > > > > > AAAARGH!!!!! One of the most common complaints I hear from those > > > who must maintain code is that the programmer had developed his own > > > personal language out of macros. THIS DOESN'T MAKE CODE EASIER > > > TO MAINTAIN, IT MAKES IT FAR, FAR, HARDER. > > > > Case in point: ever tried to work on the Bourne shell code? > > That's part of programming. What do you think the macro capability > is there for? Clarity and portability. I'm not above writing a set of library routines to make my life easier (the Software Tools distribution is a good example of such a set) but except for "extreme" circumstances, it's not clear that it's worth it to the N'th guy down the line who has to maintain the code. At the University of Oklahoma, our PDP-11 software came from the Purdue/ECN: this gave the person setting up this machine a fine base to start with. The one thing that constantly bit us was a person there who wrote all his programs (system-wide programs, like the editor!) to use HIS OWN VERSION of the Standard I/O library. This guy #include'd it from his HOME directory! (No, John, it wasn't you.) Try maintaining that. Jeff Bowles Lisle, IL
cottrell@nbs-vms.ARPA (02/12/85)
/* > At the University of Oklahoma, our PDP-11 software came from the Purdue/ECN: > this gave the person setting up this machine a fine base to start with. The > thing that constantly bit us was a person there who wrote all his programs > (system-wide programs, like the editor!) to use HIS VERSION of the Standard > I/O library. This guy #include'd it from his HOME directory! (No, John, it > wasn't you.) > > Try maintaining that. > > Jeff Bowles > Lisle, IL Sadly enuf, stdio has been thru a lot of changes. There was the early versions, the portable i/o lib (-lp), ported copies back to v6, berkeley, etc. Perhaps he captured a specific version he was used to, perhaps he added his own features. Perhaps he should have altered the names or changed them all to capitals. I myself have often wanted different features. "You can't tell the players without a scorecard!" */