🚀 go-pugleaf

In article <1992Nov2.020339.1171@mwk.uucp>, gleason@mwk.uucp writes:
>   Now that MACRO-32 is more a compiler than an assembler ...

Lord, give me strength!

> What fantasy extensions would you make, to make MACRO-32 better
> for your work?

All you need is a serious, -real- MACRO capability. The ability to
invoke LIB$FIND_IMAGE_SYMBOL from inside a macro.

Then, given that, I would cause my macros to invoke a small LISP interpreter,
such as SIOD. Then I could have macros that were powerful enough to
be a compiler for any language that I felt like generating that day.

Of course, it would also be nice if communication between the
compiler back-end (i.e. MACRO-32) and my middle-front-end stuff
was more structured than mere ascii representation of a stream
of statements.

Historical note: 

The LISP compilers at MIT started out as -assemblers-. For what was
called LAP, lisp assembly programs. Stuff like this:

 (.ENTRY MYPROG)
 (MOVE R0 (@R5))
 (JSR FOOBAR)

To make this into a compiler all you had to do was add macroexpansion
and a database capability (keep track of compiler assumptions etc).

-gjc