🚀 go-pugleaf

From article <24349:04:46:47@stealth.acf.nyu.edu>, by brnstnd@stealth.acf.nyu.edu:
> In article <14242@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
>   [ make syntax line-based ]
> I agree! Let's make it column-based, too. And let's reserve a column for
> indicating comments. Wow, I think we're onto something here. :-)

Don't laugh! There are people seriously considering using indentation
level as the flow-control mechanism.  If that's not column sensitive,
I don't know what is!  (By the way, indentation level _has_ been used
this way in an existing language: MODCAP (used to be called MADCAP - don't
know why they changed the name).)

> [... end_of_line == end_of_construct ...]
> Comments, yes. Statements, no. The studies you're referring to compared
> line-based syntax to Pascal or C, where adding a semicolon after a block
> or statement can cause a syntax error or change the meaning of the code.
> Such syntactic problems disappear when loops are explicitly terminated.

On the other hand, I've seen a study of C which indicated a large percentage
of syntax errors was due to missing semicolons.  The overwhelming majority
of such errors were at the end_of_line.  This seems to indicate that even
C programmers tend to regard the end_of_line as the end_of_statement (at
least subconsiously).  Meanwhile, I've done my own study of C code available
to me (sources that come with SUN, etc.).  Out of over 5000 lines of C,
I found only 11 cases of a simple statement which wrapped across a line
boundary.  One of these 11 was, manifestly, an error!  So, it causes a
lot of problems and is used very infrequently - why keep it?

> A study in Computer Languages several years back found that terminated
> loops ended up with by far the fewest errors per programmer.

Yes, and the infamous 'Hare' experiments in the 70's showed that programs
using 'IF ... ENDIF' had fewer errors than 'IF() GOTO L ... L:', which
in turn had _FEWER_ errors than 'IF()BEGIN ... END'.  After that, even
N. Wirth gave up on 'compound-statements' as a flow control mechanism.

> [...]
>> Ada's control constructs are among the few thing they did well.
> 
> Given the lack of any macro facility, they did fine. They would have
> done much better to provide a standard method to define new control
> structures, then reduced the standard set to three or four with no
> special cases.

There _are_ only three or four!  IF ... ELSEIF ... ELSE ... ENDIF,
LOOP ... END LOOP, CASE ... END CASE, GOTO.  That's four.  The special
cases all apply to loops: the FOR ... LOOP, the WHILE ... LOOP, and
the LOOP ... EXIT ... END LOOP.

Also, there is a problem with using macros to make control structures:
the lack of standardization.  If you make up a CASE construct which
I find peculiar, I will have difficulty with your code.  Giving me the
expanded version won't be of much help either - unless it turns into
_very_ legible standard code (in which case, why bother inventing a
new control structure?).

> [... no need for pointers _AT_ALL_ ...]
> Oh, yeah! In a language with tasks, automatic threading, and message
> passing, I've never seen the need for semaphores _AT_ALL_!! C'mon, be
> serious.

I am serious!  By your argument the following is valid:

  Oh, yeah! On a machine with conditional jumps, built-in arithmetic,
  and instructions in memory, I've never seen the need for a Turing
  machine _AT_ALL_!!   C'mon, be serious.

And yet, I don't know anyone who does production work on Turing machines.
In the language you described above, semaphores would probably _not_ be
very heavily used (at least, not directly).  And, with a well designed
language, pointers would probably not be needed either (at least, not
directly).  The advantage of these higher level ways of computing is
that they allow the programmer to be more _precise_ about what the
program does.

By the way, the correct analogy for pointers is GOTO statements.  Pointers
and GOTOs are isomorphic to each other when you compare control constructs
to data structuring features.  Pointers can lead to 'spaghetti' data in
the same way that GOTOs lead to 'spaghetti' code.  Pointers have more
severe disadvantages though: whereas GOTOs are usually restricted to
purely local targets, pointers can, and usually do, point outside the
local scope.  The compiler is therefore completely unable to make any
simplifying assumptions about the data flow of any code which involves
pointers together with global data or other pointers or even local data
which has been passed by reference to some other procedure!

J. Giles