assembly vs HLL

[Dick Dunn]

> | 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.