development tool taxonomy

[Nathan Baker]

[NOTE: follow-ups set to alt.lang.asm]

"Nathan" <nathan...@nospicedham.gmail.com> wrote in message
news:075dfd4c-470d-4265...@e16g2000yqj.googlegroups.com...
On Mar 20, 9:37 pm, Hugh Aguilar <hughaguila...@nospicedham.yahoo.com>
wrote:

> > So, I have decided that HLA *is* an assembler but that it most
> > definitely deserves its own UseNet home. Therefore, look for an RFD
> > real soon.
>
> HLA has a lot of emphasis on macros that support HLL features. I would
> make a distinction between traditional assembly-languages, such as
> MASM, TASM, NASM, FASM, etc.., and high-level assembly-languages like
> HLA that support HLL features (of course, TASM had OOP support, so its
> Ideal Mode was largely in this camp, although it was mostly a
> traditional assembler). For a long time, I thought of Forth as being
> an overgrown macro-assembler. I didn't really think of Forth as being
> a HLL itself. Later on, a lot of Forthers got involved in
> standardizing Forth, which largely moved Forth from the macro-
> assembler arena into the HLL arena --- whether that was a good idea or
> a bad idea, is debatable (this move corresponded with Forth's
> downfall, which may not be coincidental). Anyway, my approach to
> assembly-language was not that different from Randy Hyde's, except
> that I'm a Forth programmer and he is (apparently) a Pascal
> programmer.
>
> When you write your RfD, I would suggest that you try for a forum that
> supports all high-level assemblers, not just HLA. This would include
> most Forth-based assemblers. Also, Gambit Scheme has an assembler that
> would definitely fit this forum. Also, various people (maybe me in the
> future) may write preprocessors for traditional assemblers (NASM,
> FASM, etc.) that give these assemblers HLL features (that is how HLA
> started out, and it still can be used like this, although it generally
> does its own assembly now).

Just an update in case anyone is interested... I am strongly leaning
toward 'comp.compilers.hla' instead of the 'comp.lang.*' branch. The
primary reason being that the focus should be about the tool, the process,
and the outcome. It also highlights the breadth of technical knowledge that
Randy packed into his implementation -- therefore suggesting that those
concepts are also topical for the group.

Later...

Nathan.
--
http://clax.inspiretomorrow.net