From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Newsgroups: alt.folklore.computers
Subject: Re: The need for an assem
Date: 5 Sep 92 04:26:45 GMT
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University

In article <4513.168.uupcb@ssr.com> dick.zeitlin%acc1bbs@ssr.com (Dick Zeitlin)  writes:
>CL> .Computers can read files much better than people can.  I want my
>  > .computer to read my file and figure out what I mean by it.
>  > .Clearly, this can be done, but a lame language spec copout
>  > .forces me to simplify the compiler design in the interest of the
>  > .quick buck made by the compiler vendor.  On this kind of issue,
>  > .we were better off 25 years ago :-(.  (And even if I use FORWARD
>  > .statements, I still have to put the related bodies before the main
>  > .code.  For a "top-down approach" this seems rather demented.
>
>I wonder how many languages you've designed, and how many compilers
>you've written.  You seem quick to criticize HLLs because, on the one
>hand, they can't read your mind and do what you want (as distinct
>from what you write) while, simultaneously, you want them so free-form
>as to not inhibit your thought process or stifle that ambiguity.  And,
>of course, they should operate as fast as an assembler does.

As it happens, I'm not much of a compiler writer, I only participated in
writing pieces of four of them, but I have written a couple of assemblers.
All of the syntactical freedom I refer to was available over twenty years
ago when it was normal for compilers to be written in multiple passes so
that the syntax rules didn't have to be kludged to "punish" the programmer
in the interests of compilation speed.  Admittedly the original versions
just read the files multiple times, in part because memory space was limited.
The next advance was a tokenizing pass to allow a compressed source equivalent
to be read repeatedly.  Eventually, machines grew to have enough memory
capability to just tokenize and store.  Yet, today's cheap languages don't
even try, and the goal is single-pass wimpitude.

>
>If a language is designed to reduce the ambiguity of your thought, it's
>going to be constraining in some way.  If you have such a strong desire
>for free form presentation of concepts to be interpreted by the machine,
>why are you advocating a language that allows for no interpretation; no
>use of the computer to "read my file and figure out what I mean by it."
>Assembler is the antithesis of that concept!

Your viewpoint is one of someone brainwashed by the "fascists" of CS as
someone called them.  You see me advocating a return to what already was
available and you can't see that your "institutionalized" limitations are
a bad vantage point to judge what I call programming freedom.  Others have
posted on some salient points, such as the argument about preventing useful
GOTOs.

Contrary to your notions, assembler is actually fairly regimented and is
much more confining syntactically than hll, at least at the typical statement
level.  The free form only comes in the form of macro expressions; the rest
is severely regimented.  However, the argument for assembler is not for what
it is as a language per se, but rather as an expression for what it allows
the machine to be told what to do, that confining abstractive hll languages
simply prevent.  In this case, structure is counter-productive because you
can't express the code you want to execute.  Remember, hll's are abstractions
of *subsets* of what a machine can do.  It is conceivable that a hll could
be developed that actually permitted defining some of the concepts available
only in assembler, but for now, the industry seems to be moving in the
opposite direction so I wouldn't hold my breath.  In the meantime, don't
attempt to make an abstract argument against what I'm saying, because that's really comparing apples to oranges :-).  When someone is an expert on a 
particular architecture, they can express in machine language what they are
trying to make the machine do at the lowest level.  Assembly language is
just a step up from that, taking some of the housekeeping drudgery out of
it and not much more.  It is conceivable that for each structure a programmer
uses, we could define an element of a language (not any current one, but a
proposed superset that might be harder to learn than assembler!).  In any
case, don't confuse the issues of syntax of a language, and the ability
to make code happen they way you want it to.  Relative to languages such as
PASCAL, I would think that a programmer is being treated like the proverbial
"bird in a gilded cage", but any cage is still a prison.

>
>I'd suggest that the appropriate action for you is to design a language
>and write a compiler that avoids all the pitfalls that you've been
>complaining about.

I don't have to, since 20 or more years ago, others did.

cjl
Newsgroups: alt.folklore.computers