if (boolean expression)
foo:            ....
                end foo
        else
bar:            ....
                end bar

This may look odd, but it does have the advantage that it makes the block
delimiting explicit.  One would also need to be able to use unlabelled blocks
(in macros, for example), so

        if (boolean expression)
                ....
                end
        else
                ....
                end

would also fly.  A disadvantage (from some viewpoints) is that, since labels
now delimit control blocks, they can't be used for goto's.

Sometimes, I think this might be a good idea.
--

Of course, when designing a new language you certainly could require
that functions never be used unless there is a prototype (or
"declaration" as one might call it) in scope.

The present definitions of * and [] can then be happily retained.  In fact,
the entire present treatment of arrays can be happily retained, and thus
arrays-as-first-class-objects could go into C itself -- except for one thing.
Function calls.

If the rule was that a prototype of the form "void fun (int a[4], int *b);"
declared a function with one array and one pointer argument, then calls to
this function could follow the semantics I outlined above; a call of the form
fun(a,a); would pass the whole array a as the first argument, and a pointer
to its start as the second argument.  (Barring some form of "conformant
arrays", the dimension 4 would have to match exactly.)

Of course, in the present draft, that declaration declares a function with
two pointer arguments.  If this becomes as entrenched in the language in
connection with the new prototype syntax as it is with the old function
definition syntax, we will never get arrays-as-first-class-objects.
This is one reason why I and others have suggested that declarations such
as the above should at least cease to have their present meaning.

Perhaps what the original poster meant by his statement was that, for
instance, the following is legal:

  foo (a, b)
  char a;     /* b is implicitly an int */
  {
   ...
  }

(Chapter and verse:  K & R, Appendix A, Section 10.1, "Any identifiers
whose type is not given are taken to be _int_.").

PL/I has a similar feature, one can write
        label: DO;
            statements
        END label;      /* I may have this wrong */
There is a difference, though.  In BCPL, the tags on the brackets must
match exactly, but in PL/I a tagged END may close any number of tagged
and untagged DOs.

Also, it is rash to assume that the programmer does not make mistakes.  If the
location types of the arguments do not work with the instruction, this is a
programming error; what are diagnostic and error messages for?

As a side point, I like the suggestion that someone made that there be
a fallthrough statement rather than automatic fallthrough.

As to rarity of usage, I suspect the problem is that it is a nice feature
if you use it in a standardized disciplined manner, but that if it is not
obligatory it will be used haphazardly, and that it has no particular value
in that case.   Now that I think on it, you don't need it for small pieces
of code, where everything is clear.  It may have some value for large
programs (as in large number of lines per file).  However my experience
is that the way to deal with the difficulties created by writing large
procedures is not to not write large procedures! :-).

OK, Richard, you win -- D should not have labelled blocks.

--

My "short char" proposal did not REQUIRE bit addressability, but it did
allow it to be exploited if the implementor decided it was wanted.
(1 = sizeof(short char) <= sizeof(char).)  The other main implementation
would be to let a "short char" be an 8-bit byte and a normal "char" be
big enough to hold an entire textual unit (typically 16 bits in Japan).
Unfortunately not many committee members seem to be bit-map programmers...

        IF x > y
        THEN    max := x;
        ELSE    max := y;
        END;

(I think I have the semicolons right; I'm sure about the one after END)

When these structures are nested deeply, one may be confused about
just what is being ended.  To reduce confusion, the programmer may
insert any number of tokens from the opening statement between the
END and the semicolon:

        IF x > y
        THEN    max := x;
        ELSE    max := y;
        END IF x > y;

Or add yet another special case (automatic fallthrough if and only if there
is no code between the two labels)?

 >> Another thing that should go is the assumption that the unit of storage is
 >> the byte.  The base unit of storage is the bit, and sizeof should return the
 >> number of bits in the object.  This enables to treat objects smaller than a
 >> byte as first class objects.

  While I'm totaly against changing the existing functionality of the
sizeof() operator, what I would be totaly in favor of would be the
addition-to-ansi-C of a new operator that would have a similar
functionality, but which would return the number of -bits- in
something.  The name bitsize() would be my suggested name for this
operator.

  This would provide one MAJOR advantage.  It would allow writing code
or header files that would be 100% portable without having to know
about each and every compiler/OS/machine's identifer defines.  If you
needed a 12 bit integer type, your headers could have #if statements
that would provide the next integer type equal or larger that 12 bits.
No more #ifdef'ing special integer types individualy for each system
when you're trying to make efficient code run on multiple machines.

  An additional minor advantage would be the capability of writing
the kinds of functions we normaly use sizeof for to work with bitfield
variables..

  This is a relatively minor addition to any existing compiler
(multiply sizeof by 8 for most machines... and return the bitsize
that's probably already a field in the evaluation structure for a
bitfield variable...) and would make some major advancements possible
in source code portability...

  Doug Gwyn, I'd appreceate hearing your reaction on this suggestion.
If it's never come up as a suggestion, feel free to play with it.  If
it's been considered and rejected, I'd like to hear the reasoning
behind the rejection.  

After all, that was what Wirth intended to design when he designed Pascal.

Note that this does *not* solve the dangling else problem.  That being the
case, I see no reason to prefer it to the current syntax.
--

The point still stands as regards undeclared functions, though.

Conversely, on those machines which *do* have bit addressing, C provides
very inefficient access to it.

We need to figure out how to make D efficient without regard to the
addressing unit of the machine.  Off-hand, I'm not sure how to do that.

This overlooks the compound statement forming the body of the function.  This
is easily enough dealt with by making the function syntax be:
        type declarator declarations statements end ;
instead of
        type declarator { declarations statements }

One possible use for the braces would be as type parentheses, so one could
write:
        {int *} a, b;
to make both a and b pointers to int.  I think using this for casts would
improve readability as well.  (That is, replace the parentheses around the
cast type with braces.)

This is an off-the-cuff idea, there may be better ones.

If you want the length immediately preceding the string, you need new syntax
and/or the pre-processor to avoid writing the string twice.

#asm <statement>

instead of

asm("statement");

This is almost worth doing in C; I would certainly do it in D (assuming the
preprocessor is kept).
--

The basic ideas are that "a[]" is an array lvalue, and that aggregate
constants are natively typeless and must always be either cast or assigned
to the appropriate type.  Two examples follow.

(Watch out for the extensions to printf(3S) and scanf(3S) for array handling.)

I will explain any of this if desired.

EXAMPLE 1

    int thing(i, a, b)[2]
    int i, a[2], b[2];
    {
       int val[2];

       val[0] = a[i] - b[0];
       val[1] = a[i] - b[1];

       return (val[]);
    }

    main()
    {
        typedef int PAIR[2];

        char *message = "END-OF-EXAMPLE";

            PAIR p1, p2, p3[2];

            p1[] = {2, -3};
            printf(p1: "%(2)4d\n", p1);

            p2[] = {1, 7};
            printf("p2: %(2)4d\n\n", p2);

            p3[0][] = thing(0, p1[], p2[]);
            p3[1][] = thing(1, p1[], (PAIR) {1, 7});

            printf("p3: %(2;  )(2, )d\n\n", p3);

            printf("%(* )c\n", strlen(message), message);
            printf("%(*:-])c\n", strlen(message)*2/3, (char *)NULL);
    }

prints

    p1:    2  -3
    p2:    1   7

    p3: 1, -5;  -4, -10

    E N D - O F - E X A M P L E
    :-]:-]:-]:-]:-]:-]:-]:-]:-]

ANOTHER EXAMPLE

main()
{
    int array[10][10];
    int array2[100][10] = {0};      /* fills entire auto array with 0s */
    int row;

        scanf("%(10 )(10 )d", array);  /* reads free-format 10x10 array */

    /* copy array into top 10 rows of array2 */
        for (row = 0; row < 10; row++)
            array2[row][] = (int [100]) array[row][];   /* cast is not needed */

        reduce( (int [100][100]) array2[], 10);      /* this cast is required */

        for (row = 0; row < 10; row++)               /* copy the rows back */
            array[row][] = array2[row][];

        printf("%(10\n)(10 )6d\n", array);    /* display square array */

        (-: :-)         (-: :-)         (-: :-)

=========
The opinions expressed above are mine.

Am I the only person in the world that thinks it's time to scrap
ASCII?

Look at the contortions we have to go through in C because there
aren't really enough characters for the operators needed.  Look at the
messes we get into under the UNIX shells with quote characters,
delimiters, et cetera.  Wouldn't it be simpler if punctuation was
punctuation and metacharacters were metacharacters and there was no
overlap between the two?

APL, of course, solved this problem by inventing its own character
set.  Unfortunately, it was nonstandard and there was almost no
equipment that used that character set.

The time is ripe for a more flexible "Code for Information
Interchange".  How many more years/decades will we be forced to make
do with a lousy 95 symbols: all predefined, most vastly overloaded?

C would have been much more usable language if it hadn't had to have
been mapped to ASCII.  D could be the best of C and APL if a larger
character set was available.

I know, I know, the cost of such a change would be phenomonal.  Even
deciding on a new standard will be hard/expensive/time-consuming, but
it's *got* to be done sooner or later.  (Not until we've lived with
several incompatible proprietary systems for a while, though.)

I just needed to get that off my chest, sorry if I bothered you.

=========
The opinions expressed above are mine.

"There is very little importance in instruction sets."
                                        -- Ted Nelson