I might point out that zcobol (part of z390) was a translation of COBOL
syntax which was then converted to Assembler by a large set of
macros...thankyou Don Higgins
And while I'm here, I posted "HLASM RFE revisited", but the bounce back went
into my Spam folder...it isn't and I would appreciate you guys finding it
and responding
Melvyn Maltz.
----- Original Message -----
From: "Charles Mills" <[email protected]>
To: <[email protected]>
Sent: Monday, December 11, 2017 10:16 PM
Subject: Re: Macro Processors
I get your point. The assembler macro facility is more like a facility for
writing extensions to the assembler than it is like the C macro
preprocessor. That ability to write a macro that is integrated in its
processing with the main passes of the assembler -- yes, that is very cool.
In C I can write a macro FOO(bar) that expands out into C code -- shorthand,
in other words. But an assembler macro has the ability to be more like an
extension of the assembler itself, not simply a shorthand for some more
wordy assembler instructions.
Charles
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:[email protected]]
On Behalf Of John Ehrman
Sent: Monday, December 11, 2017 12:19 PM
To: [email protected]
Subject: Macro Processors
Charles Mills noted...
Date: Sat, 9 Dec 2017 17:58:15 -0800
From: Charles Mills <[email protected]>
PL/I has a very powerful "macro" (preprocessor, I think they call it)
facility. I don't know it well at all, but in my impression it is more
powerful than either assembler or C macros.
I agree that PL/I's macro preprocessor is indeed powerful; but it and
all other macro facilities I know of lack a key feature of HLASM's
conditional assembly and macro facility: an intimate interaction
between the base language and the macro language. While the
