Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cbosgd.UUCP
Path: utzoo!watmath!clyde!cbosgd!kww
From: kww@cbosgd.UUCP (Kevin Wall)
Newsgroups: net.lang.c
Subject: Re: assembly vs HLL
Message-ID: <817@cbosgd.UUCP>
Date: Thu, 31-Jan-85 14:45:12 EST
Article-I.D.: cbosgd.817
Posted: Thu Jan 31 14:45:12 1985
Date-Received: Sun, 3-Feb-85 07:40:52 EST
References: <282@decwrl.UUCP> <1051@opus.UUCP>
Reply-To: kww@cbosgd.UUCP (Kevin Wall)
Organization: Bell Labs, Columbus
Lines: 27

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