ddb@mrvax.DEC (DAVID DYER-BENNET MRO1-2/L14 DTN 231-4076) (01/21/85)
> HAH!!!!!!!! > > 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. 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. BLISS is nice because it gives you the low-level control of the machine WITHIN THE LANGUAGE, and without sacrificing global optimizations. (BLISS is also not nice for some reasons, but they are better known and less interesting.) -- David Dyer-Bennet -- ...decwrl!dec-rhea!dec-mrvax!ddb
rcd@opus.UUCP (Dick Dunn) (01/25/85)
> > 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.
rpw3@redwood.UUCP (Rob Warnock) (01/27/85)
+--------------- | > 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?... | ...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)... +--------------- Counter-point: When the set of macros is not a "personal language" but a "project" or "application field" language, the use of macros can have resounding POSITIVE benefits. The problem is private cryptic code, not the use of macros per se. A readable external description of the meta-language helps a lot, as does a clear and consistent style of use. Example: See the book, "The Macro Implementation of SNOBOL4", by Raplh Griswold (Freeman 1972). SNOBOL came up fairly easily on many machines. Example: At a similar time, Bill Waite's STAGE2 macro language was being used to port a whole host of compilers and tools across machines, much like the Software Tools in Ratfor today. Example: Ratfor is "just" a set of macros, yet STUG lives! Example: The FOCAL interpreters (of the MUMPS/JOSS traditions) were all written in assembler using a few common macros for certain lexical-analysis tasks. The same macro names and functions (and often routine names and tags within routines) survived across many versions and across several machines: PDP-8, PDP-11, PDP-10. Since the STYLE was the same, any FOCAL maintainer could pick up another version of FOCAL and understand it clearly, EVEN IF THE ASSEMBLY LANGUAGE WAS UNFAMILIAR. ["Tip 'O The Hat" to Richie Lary!] The point is, the undisciplined random use of ANYTHING can produce garbage which is hard to maintain. Conversely, a little clear thinking about the problem, combined with the sparing use of powerful tools, can simplify things. The main simplifying tool we have to work with is "abstraction", allowing us to "chunk" things into manageable sizes. Macros are a way to create abstract instructions. Our abstractions can be useful, or they can be clumsy. "Macros don't create confusion, people create confusion..." ...and clarify it. Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404
rcd@opus.UUCP (Dick Dunn) (01/29/85)
> | That's the problem with these sets of macros mentioned by >>: each one is a > | different language with different characteristics (and bugs)... > +--------------- > > Counter-point: When the set of macros is not a "personal language" but > a "project" or "application field" language, the use of macros can have > resounding POSITIVE benefits. The problem is private cryptic code, not the > use of macros per se. Rob (>) is right in principle. It can be difficult to make the judgment call on what to do when you've obviously passed the "personal language" situation but may not have reached the "application field". In one sense, the availability of powerful macro processors simply shifts the tradeoff point for the answer to the question, "Is this problem big enough and different enough to justify a new language?" It makes it much easier to go off and invent a new language--something which should be done with some trepidation. > ... > Example: See the book, "The Macro Implementation of SNOBOL4", by Raplh Griswold > (Freeman 1972). SNOBOL came up fairly easily on many machines. Looking at the tradeoff here, it's clear that the cost of implementing SNOBOL from scratch is huge. At the time SNOBOL4 was being ported to various machines, there were no languages available on any reasonable subset of these machines which could be used as implementation languages. Note that Griswold's more recent work on Icon (with Hanson, et al) has been implemented in C. I would surmise that the availability of C is good enough to outweigh a special-purpose implementation language as used for SNOBOL4. (Anyone from arizona care to comment?) > Example: At a similar time, Bill Waite's STAGE2 macro language was being used > to port a whole host of compilers and tools across machines, much like the > Software Tools in Ratfor today. One of the difficulties with STAGE2 implementations of various items of software was that STAGE2 presents you with a wide range of possibilities, all at a VERY low level. You end up with a whole host of sets of macros, often developed by different people. There's a fair set of "standard bugs" that you encounter when learning to write STAGE2 macros, and every new implementor has to learn them. Bill has said that one of the problems with the STAGE2 approach to porting software is the proliferation of macro packages. I suspect it was a key incentive in the work he did later on in trying to develop a more widely usable (dare I say "universal"?) intermediate "language". I don't think Rob and I are too far apart in principle, though we do seem to differ on the tradeoff point. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Never offend with style when you can offend with substance.
kww@cbosgd.UUCP (Kevin Wall) (01/31/85)
In article <1051@opus.UUCP> rcd@opus.UUCP (Dick Dunn) writes: >> > 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 Just think how much more we'll be able to [ab]use this with operator overloading and the like in the new C++ :-) Kevin Wall kww@cbosgd AT&T Bell Laboratories, Columbus