🚀 go-pugleaf

In <43a5ij$s2b@news0.rain.rg.net>, Paul Long <plong@perf.com> writes:
>That's a specious argument. I can imagine advantages and disadvantages of it
>being similar to the switch statement. And frankly, both of our syntaxes are
>really ugly. :-P

I agree, but I was attempting to design something that fits into
the "style" of C and C++.  It is actually much messer than the
syntax that I personally use (conceptually).

>Sounds familiar. I think Knuth also considered this for situation indicators.

I derived my syntax from a paper that Knuth wrote years ago (and
could not put my hands on today).  In that paper he used the term
"situation labels" and not "situation indicators" so he may have
written a more recent paper with the different terminology.  However,
the concepts seem the same.

>Cool.

I wish I could still use it!  It was for a Z80 running CP/M.  A very
long time ago!

>I just never encounter situations where a continue statement would be useful--I
>don't think that way. I recently found this in another programmer's code:

I do.  Generally not in extremely simple systems, but on a regular
basis.

>that could have been more clearly written, IMO, as:
>
>    while (x) {
>       if (!y) {
>           a;
>       }
>    }

Yes, but what about code more like...

   while (x)
      {
      significant statements....
      if (y)
         continue;
      significant statements...
      if (x)
         break;
      signficant statements...
      }

No matter how you roll the loop, you are still stuck.  I have
seen that sort of thing when scanning input on a frequent
basis.

>For the same reason that I wouldn't include, for example, a computed-goto
>statement in a language, neither would I include a continue statement--I don't
>see a need.

I would be both more severe and more forgiving.  I would simply
disallow the unstructured goto.  I would, however, allow structured
gotos (such as in my situation label syntax).  The basic rules are
that a structured goto may repeat a block or exit a block.  And
when exiting the transfer of control is always forward.  That may
be applied in nested blocks and so includes things like the return
statement.  You may not jump into the middle of block.  You may
not jump between arbitrary points within a block.  The generated
flow graph MUST be reducible -- which is guaranteed by all of
the suggested control structures, but is not guaranteed for the
unstructured goto.

Further, I would allow significantly more control structures to
provide the needed semantic variants (in fact, I recognize (and
think in terms of) more than 50 control structures and their
modifiers.

> Languages are usually a very personal, subjective expression of
>"good programming" on the part of the designer,

Agreed, and everyone's idea of good programming will differ.  What
I *REALLY* have in mind is so restrictive that virtually nobody would
use it -- except a few fellow fanatics.  However, I strongly feel that
will become, in time (not twenty, but quite possibly 50 years), the
dominant approach and so I continue to work towards it.

>that you would feel the same way about things that
> I would put in a language.

Possibly, but I have been collecting and organizing control
structures for twenty years now.  I have considered some
really weird structures and some I now accept might be
pretty weird to you.  So I might be more open that you
expect.

>You'd like PL/I.

I wrote many a PL/1 program in my mainframe days.  I consider
it to be a very restricted language.  Currently C++ is probably
the best language to use in most cases, and I would fall back
to Eiffel (and, maybe, Smalltalk for convenience) if C++ would
not do what I want.  However, Eiffel is too restrictive at this
time for general use.  Not in basic concepts which are great,
but in the procedural aspect of the language -- basically a
takeoff from PASCAL which is the worst of all languages.

>A problem with a "rich" language is that dialects are formed.

That depends on what you mean by "dialects".  If you mean that
a programmer will tend to use a certain subset of the language
you might be right.  If you mean that compiler writers are likely
to omit part of the language, you can control that through
trademarks and legal licensing (at least for a while).

And that is not necessary.  It depends on the skills of the
language designer.  I am currently working on a new language
(an interrim language, not my final language) where I am
taking C++ and stripping things out.  I am then adding back
a very few new ideas, with the result is that the actual
language is much smaller.  But it is upward compatible with
C++ with only a very few restrictions.  The trick is in the
language design and in consistency between features.

The idea is to turn C++ into a fully consistent, simple object
oriented language.  There are no primitive data types, for
example.  But all of your int, float, etc. declarations will
still work correctly.

So an apparently large language can actually be conceptually
simple if extremely consistent and well designed.  This is not
something we have seen too often in the language arena.  This
means that the language implementors will be unlikely to leave
anything out because it would fundamentally cripple the
language and programmers will be more likely to use more of
the language because the design consistency makes it easy
to remember the different features.

>That's silly. Do you think he should also make, for example, only left-hand
>turns so that he turns in "one and only one way." Come on.

An excellent example!  This is EXACTLY the way I feel about
every language that Wirth has designed, and the basic design
philosophy in general.


Michael Lee Finney