From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: The need for an assembler (was: Favorite CPU)
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Sat, 29 Aug 1992 08:02:10 GMT

In article <jimf.714924310@centerline.com> jimf@centerline.com (Jim Frost) writes:
>
>There have been non-standard implementations of Pascal around for
>years that allow symbolic labels on gotos.
>
>In fact, I've never used a Pascal that *didn't* have symbolic labels
>(I can't say the same for FORTRAN).

Perhaps they even work properly, but there are more "rigorous" implementations
of PASCAL where the goto is as lame as originally defined, and works in as
panicky a way that the spec of the language allows it to be.

>
>>>>Why would I want to use a language where you need
>>>>FORWARD statements because it doesn't do enough passes to do it without me?
>>>
>>>Why slow the compiler down for programmers who wouldn't use the language
>>>anyway :-)
>
>>A silly remark that doesn't answer the question.  This is a major ugly
>>feature of the language: all internal procedures have to come first, and
>>when they reference each other, a kludge is needed to pull it off.
>
>That's what happens when you have type-safe languages.  You'll find
>that predeclaration is also necessary in most other type-safe
>languages.  It's true, it's to help out the compiler.  So what?

So maybe I don't want the body of my subroutines to appear first.  I could
possibly accept the declaration of the routines first, but not the body of
it as well.  PL/I always lets me put what I want where I want it.  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.  Strong typing in
languages doesn't have to demand rigourous overall ordering of section types.
That sounds like a military intrusion into an otherwise sensible design.  (Is
this how we come to ADA :-).)

>
>>BTW, if HLL theory is that it abstracts what computers actually do,
>>then why the deficiency in so many languages regarding goto?  Do people
>>believe that computers lack program control branch instructions?
>
>Nope, but using abstracted branches (if/else, for, while, repeat, etc)
>leads to much easier-to-follow code.  Easier-to-follow code is the
>goal in a large project, since the code has to be developed and
>maintained by many people.

The first sentence is an opinion.  The second sentence is true, but not a
consequence specifically of the first sentence.  Using GOTO may be light
years more easy to follow or be clearer about what's going on.  PL/I gives
you a better choice as to what makes the most sense.  Aberration of code
to substitute an existing control structure doesn't make it better, it
just obfuscates the program, and may invite inefficiency or side-effects
consequences such as logically conjuncted subexpressions, etc.  BTW, GOTO 
may be just as abstract as any other statement in the language, so this is
just the old "gotos are harmful" argument in disguise.  (My abstracted
features list is better than your abstracted features list, etc.)

cjl