The D Programming Language (was: Still more new operators)

1168 views
Skip to first unread message

Dave Sill

unread,
Feb 7, 1988, 2:29:25 PM2/7/88
to
>Some years ago I invented the hypothetical notation "e1 ,, e2", which would be
>like the comma operator in that it evaluates its left operand before its
>right operand, but (unlike comma) the result would be the value of the left
>operand. Look what this buys us:
> a,, a=b /* displacement operator, like a :=:= b */
> a=(b,, b=a) /* a simple swap */
> x,, ++x /* same as x++; but generalizable */
> free(stack,, stack=stack->next) /* pop stack */
> stack->value,, pop(stack) /* pop and return stacked value */

I like it. Nice and general, fills a gap missing in C. It's not C,
but it could be D (it *should* be D, not P (pee?)).

Maybe we should start a new newsgroup/mailing-list for the discussion
of such things. It seems like a lot of the current discussion here is
about things that will never make it into ANSI C such as a power
operator, `noalias' :-) et cetera. Sure would improve the S/N ratio
for those interested only in C.

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

"The limits of my language mean the limits of my world."
-- Ludwig Wittgenstein

Bob Rose

unread,
Feb 7, 1988, 7:17:40 PM2/7/88
to
In article <11...@brl-adm.ARPA>, ds...@NSWC-OAS.arpa (Dave Sill) writes:
> >Some years ago I invented the hypothetical notation "e1 ,, e2", which would be
> >like the comma operator in that it evaluates its left operand before its
> >right operand, but (unlike comma) the result would be the value of the left
> >operand. Look what this buys us:
> > a,, a=b /* displacement operator, like a :=:= b */
> > a=(b,, b=a) /* a simple swap */
> > x,, ++x /* same as x++; but generalizable */
> > free(stack,, stack=stack->next) /* pop stack */
> > stack->value,, pop(stack) /* pop and return stacked value */
>
> I like it. Nice and general, fills a gap missing in C. It's not C,
> but it could be D (it *should* be D, not P (pee?)).

But wait, we can do better. Why limit yourself to two operands? Let's
look at some other programming language (like Icon) and get the
correct operator.

The magic operator is

i(x1, x2, x3, ..., xn)

Looks like a function call eh? It's not. i is an integer in the
range from 1 to n and the operator produces the outcome of xi.

So a simple swap is

a = 1(b, b=a); /* much cleaner than ,, */

The the wonderful thing is it wont break any code. So everyone
write your ANSI rep now!!!! 8^)

BTW my vote for min and max is ?< and ?>. Also why not ?: that
produces it first operand if it is not zero else it produces it second
that why the getc macro becomes

#define getc(file) (*(file)++->char ?: _fillbuf(file))
/* note _fillbuf is smart enough to figure out if there was
a '\0' in the input stream or if it was actually at the
end of a buffer and of course the buffer size is BUFFSIZE + 1 */

just thinking aload
-bob
--
Robert R. Rose
Northern Arizona University, Box 20023
Flagstaff, AZ 86011
.....!ihnp4!arizona!naucse!rrr

David Keppel

unread,
Feb 7, 1988, 8:29:47 PM2/7/88
to
In article <11...@brl-adm.ARPA> ds...@NSWC-OAS.arpa (Dave Sill) writes:
>but it could be D (it *should* be D, not P (pee?)).
>
>Maybe we should start a new newsgroup/mailing-list for the discussion
>of such things. It seems like a lot of the current discussion here is
>about things that will never make it into ANSI C such as a power
>operator, `noalias' :-) et cetera. Sure would improve the S/N ratio
>for those interested only in C.

Sounds good to me.

I've been collecting interesting ideas about ``D'' off the net for a while.
If y'all would like to send me your 1 or two favorite "improvements" to
C to be incorporated in "D", I'll send you a summary in response.

Not that I intend to write D or P or whatever, but if somebody wants my
ideas (take my ideas, please!)

;-D on (Creativity is ... hard to define) Pardo

pa...@cs.washington.edu ..!ucbvax!uw-beaver!uw-june!pardo

Sun ECD Software

unread,
Feb 9, 1988, 9:24:14 AM2/9/88
to

In article <11...@brl-adm.ARPA> ds...@NSWC-OAS.arpa (Dave Sill) writes:

>>Some years ago I invented the hypothetical notation "e1 ,, e2", which would be
>>like the comma operator in that it evaluates its left operand before its
>>right operand, but (unlike comma) the result would be the value of the left
>>operand. Look what this buys us:
>> a,, a=b /* displacement operator, like a :=:= b */
>> a=(b,, b=a) /* a simple swap */
>> x,, ++x /* same as x++; but generalizable */
>> free(stack,, stack=stack->next) /* pop stack */
>> stack->value,, pop(stack) /* pop and return stacked value */
>
>I like it. Nice and general, fills a gap missing in C. It's not C,
>but it could be D (it *should* be D, not P (pee?)).

Actually, the last project course at the late Wang Institute developed
a compiler and editor for the D language called Turbo-D. The D language
we used was taken from Dijkstra's guarded command language in his book
"A Discipline of Programming." For the simple swap you have shown, the
D syntax seemed to be much cleaner:
a,b := b,a

The language had some other features, including non-determinate selection
of guards for loops and conditional statements. The project was fun, the
language was useful, and the compiler was fast.

--
Gary F. Pollice | Remember the Wang Institute!!
Sun Microsystems | ARPAnet: gpol...@sun.com
Two Federal Street | UUCP: {decwrl,ihnp4,hplabs,ucbvax}!sun!gpollice
Billerica, MA 01821 | (617)671-0374

Karl Heuer

unread,
Feb 9, 1988, 12:37:56 PM2/9/88
to
In article <5...@naucse.UUCP> r...@naucse.UUCP (Bob Rose ) writes:
>But wait, we can do better [than the proposed ",,"]. Why limit yourself to
>two operands?

> i(x1, x2, x3, ..., xn)
>[where 1 <= i <= n; the result is xi]

If `i' is constant, this is no more powerful than `(x1, ..., xi,, ...,, xn)'
which produces the same result. If `i' is allowed to be an arbitrary integral
expression (which I presume is the case in interpretive Icon), then it is
indeed more powerful but also more expensive to compute. Part of the beauty
of `,,' is that it has a cost comparable to `,'.

>[How about an operator] that produces it first operand if it is not zero else
>it produces it second

I considered proposing that the `||' operator be so extended (yes, this could
break existing code, but only if the operands are nonboolean AND the result is
being used in a nonboolean context). After thinking about it, though, I
decided that this is a step backwards. In programs that properly distinguish
between booleans and integers, there's nothing particularly magic about
`compare against zero'. Why should there be a special-purpose notation for
`e1 != 0 ? e1 : e2' but not for `e1 != -1 ? e1 : e2', say?

What you really want is the `it' pronoun, often used in PDL.
IF long-hairy-expression != 0
RETURN it
ELSE
RETURN other-expression
ENDIF

Karl W. Z. Heuer (ima!haddock!karl or ka...@haddock.isc.com), The Walking Lint
KWZH: We need a construct like `e1 UNLESS IT==0 INWHICHCASE e2'.
GCJ: Yes, and also `IFONTHEOTHERHAND ... WEMAYSAFELYASSUME'.

Steve Wampler

unread,
Feb 9, 1988, 7:12:14 PM2/9/88
to
In article <25...@haddock.ISC.COM>, ka...@haddock.ISC.COM (Karl Heuer) writes:
> In article <5...@naucse.UUCP> r...@naucse.UUCP (Bob Rose ) writes:
> >But wait, we can do better [than the proposed ",,"]. ...

> > i(x1, x2, x3, ..., xn)
> >[where 1 <= i <= n; the result is xi]
> ... If `i' is allowed to be an arbitrary integral

> expression (which I presume is the case in interpretive Icon), then it is
> indeed more powerful but also more expensive to compute. Part of the beauty
> of `,,' is that it has a cost comparable to `,'.

Actually, if 'i' is an arbitrary integral expression, it isn't that much more
expensive to implement than if it's a constant - most of the evaluation
mechanism is already in place in C (excuse me, 'D'). The only extra expense
over computing the value if 'i' is a constant is the cost of evaluating the
expression for 'i' and a simple transfer.


Sigh, let's just keep postnews happy here...
--
Steve Wampler
{....!arizona!naucse!sbw}

David Collier-Brown

unread,
Feb 12, 1988, 10:30:45 AM2/12/88
to
In article <243@eagle_snax.UUCP> gpollice@eagle_snax.UUCP ( Sun ECD Software) writes:
| Actually, the last project course at the late Wang Institute developed
| a compiler and editor for the D language called Turbo-D. The D language
| we used was taken from Dijkstra's guarded command language in his book
| "A Discipline of Programming." ...

| The language had some other features, including non-determinate selection
| of guards for loops and conditional statements. The project was fun, the
| language was useful, and the compiler was fast.

Can you find out if it can be posted? I'd like a (V)HLL like the
Dijkstra language to write hard, complex but non-machine-related
things in. A (M)HLL like P would be nice too (:-)).

--dave
--
David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb
Geac Computers International Inc., | Computer Science loses its
350 Steelcase Road,Markham, Ontario, | memory (if not its mind)
CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.

Karl Heuer

unread,
Feb 16, 1988, 6:14:35 PM2/16/88
to
In article <5...@naucse.UUCP> s...@naucse.UUCP (Steve Wampler) writes:
>> > i(x1, x2, x3, ..., xn)
>> >[where 1 <= i <= n; the result is xi]
>[Karl Heuer states that the generalization to nonconstant `i' is expensive]

>Actually, if 'i' is an arbitrary integral expression, it isn't that much more
>expensive to implement than if it's a constant - most of the evaluation
>mechanism is already in place in C (excuse me, 'D'). The only extra expense
>over computing the value if 'i' is a constant is the cost of evaluating the
>expression for 'i' and a simple transfer.

Sorry, I stand by my statement. If this `pick' operator is supposed to be a
generalization of my proposed `,,' operator, it must preserve the guarantee of
evaluating all of the `x?' operands, in left-to-right order. It sounds like
you're thinking of the expression equivalent of `switch', which would evaluate
exactly one of them. (Which may also be useful, but that's a separate topic.)

Steve Wampler

unread,
Feb 17, 1988, 9:41:56 AM2/17/88
to
In article <25...@haddock.ISC.COM>, ka...@haddock.ISC.COM (Karl Heuer) writes:
> In article <5...@naucse.UUCP> s...@naucse.UUCP (Steve Wampler) writes:
> >> > i(x1, x2, x3, ..., xn)
> >Actually, if 'i' is an arbitrary integral expression, it isn't that much more
> >expensive to implement than if it's a constant - most of the evaluation
> >expression for 'i' and a simple transfer.
> Sorry, I stand by my statement. If this `pick' operator is supposed to be a
> generalization of my proposed `,,' operator, it must preserve the guarantee of
> evaluating all of the `x?' operands, in left-to-right order. It sounds like
> you're thinking of the expression equivalent of `switch', which would evaluate
> exactly one of them. (Which may also be useful, but that's a separate topic.)

Actually, no. However, I wasn't thinking of this as an exact replacement
for the ',,' operator, just as something that does equivalent work. You
can evaluate all the operands and then fairly easily make an arbitrary one
of them available. Think of 'i(x1, x2, x3,..., xn)' as being analogous to
calling a function 'i' that returns its ith argument. Then think of ways
to avoid implementing 'i' as a function. I suppose that compared to the ',,'
operator, there is the overhead of verifying that 'i' evaluated to the
proper range, but that is really a cost of the extra generality, and can
be eliminated if 'i' is a constant.

Of course, the evaluation order for ',,' is well defined, while the
evaluation order (in 'C' at least) for 'i(...)' would match the evaluation
order for function calls, which is much messier. (In 'D', however....).

I think ',,' is an interesting operator, but I personnally prefer 'i(...)',
having used it extensively in Icon - it seems 'more natural' to me. To each
his own.

--
Steve Wampler
{....!arizona!naucse!sbw}

Frank Adams

unread,
Feb 18, 1988, 1:46:38 PM2/18/88
to

Any serious effort to design a successor to C (which does not attempt to be
upward compatible) should first consider what should be taken out and/or
done differently. Adding new things is secondary.

The first thing I would remove is the automatic conversion of arrays to
pointers. This was an understandable mistake, but a mistake nevertheless.
Removing it clears the way for treating arrays as first class objects. (A
consequence of this change is that "a[b]" is no longer definable as
"*(a + b)". We still have that it is equivalent to "*(&a[0] + b)", but this
cannot, of course, be used as a definition.)

Second on the list is defaulting of variables. An undeclared variable
should be an error, not an int. Likewise for functions. I would favor
mandating ANSI-style function prototypes. (Except that the "f(void)"
construct would not be needed -- "f()" means a function with no arguments.)

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.

I would also like to do away with having control statements control single
statements. For example, instead of writing "if (foo) {stmt1; stmt2;}" I
would write "if (foo) stmt1; stmt2; end;". Likewise, I would rewrite the
"for" statement as "for <stmts> while (<exp>) next <stmts> do <stmts> end;".
The "while" and "do ... while" I would generalize to "loop <stmts> while
(<exp>) <stmts> end;". In keeping with the spirit of C, we avoid
superfluous words, and keep the ones we do use short.

With these changes, the {} statement delimiters become much less useful. I
would probably drop them, and add a "begin ... end;" construct for those
cases where a local declaration is desired.

Another shortcoming to be fixed is the automatic fallthrough for select
statements. The default should be exit the statement when a new case is
encountered, with an option to fall through. I don't much like the current
syntax, either. In any event, the syntax should include specifying multiple
values for a case (what is now accomplished by "case a: case b:").

To get even more radical -- with typedefs, enums, const declarations, and
(if we add them) inline functions, do we really need the pre-processor any
more? Some kind of include statement should be provided, of course. Any
decent compiler will optimize "const int foo = 1; if (foo) ... else ...
end;", so preprocessor conditional compilation is hardly necessary.

I would omit the automatic insertion of a null byte at the end of character
constants. If you want nul terminated strings, write the nul. If you want
strings with counts, the language should not get in your way.

I think I would also drop the convention that 0 is a null pointer. Make
"null" a keyword, representing a null pointer of any type.
--

Frank Adams ihnp4!philabs!pwa-b!mmintl!franka
Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108

Karl Heuer

unread,
Feb 18, 1988, 3:47:20 PM2/18/88
to
In article <5...@naucse.UUCP> s...@naucse.UUCP (Steve Wampler) writes:
>In article <25...@haddock.ISC.COM>, ka...@haddock.ISC.COM (Karl Heuer) writes:
>>It sounds like you're thinking of the expression equivalent of `switch',
>>which would evaluate exactly one of [its right operands].

>
>Actually, no. However, I wasn't thinking of this as an exact replacement
>for the ',,' operator, just as something that does equivalent work. You
>can evaluate all the operands and then fairly easily make an arbitrary one
>of them available.

Yes, you can implement it as
(temp[1]=x1, temp[2]=x2, ..., temp[n]=xn, temp[i])
if you're willing to live with the space requirement. (This was noted in the
first draft of my earlier article, but I cut it before posting.)

>I suppose that ... there is the overhead of verifying that 'i' evaluated to
>the proper range ...

Actually, it would be well within "the spirit of C" to let an out-of-range
selector be an undefined condition. Then the verification can be omitted.

>Of course, the evaluation order for ',,' is well defined, while the
>evaluation order (in 'C' at least) for 'i(...)' would match the evaluation
>order for function calls, which is much messier.

And in private correspondence:
>Also, note that, in 'C' at least, the types of e1,...,en
>must match (this isn't true in Icon).

This is important. If we add this `pick' operator but not `,,' on the grounds
that the former can simulate the latter, we would have to assert that
(a) `pick' guarantees to evaluate its right operands left-to-right, and
(b) the right operands must all have the same type if the left operand is
nonconstant, but may be of varying types if the left operand is constant.

(a) is an arbitrary restriction that shouldn't apply to `pick' for the same
reason that it shouldn't apply to function calls (we should let the compiler
do whatever is the most efficient thing), and (b) is a kludge of the same
magnitude as the recently-proposed enhancement to "++" for non-lvalues.

It looks like the best solution is to add both operators! (After all, we're
talking about a hypothetical `D' language here.)

Alan J Rosenthal

unread,
Feb 18, 1988, 10:24:04 PM2/18/88
to

In article <5...@naucse.UUCP> r...@naucse.UUCP (Bob Rose ) writes:
>>[How about an operator] that produces its first operand if it is not zero,
>>else it produces its second.

In article <25...@haddock.ISC.COM> ka...@haddock.ima.isc.com (Karl Heuer) writes:
>I considered proposing that the `||' operator be so extended ...
>After thinking about it, though, I decided that this is a step backwards...


>Why should there be a special-purpose notation for `e1 != 0 ? e1 : e2' but
>not for `e1 != -1 ? e1 : e2', say?
>
>What you really want is the `it' pronoun, often used in PDL.
> IF long-hairy-expression != 0
> RETURN it
> ELSE
> RETURN other-expression
> ENDIF

An obvious (at least to me) way to extend C to provide this is using the
?: operator. e1 ? e2 : e3 compiles to something vaguely like:

calculate e1
jump-if-zero L1
calculate e2
jump-always L2
L1: calculate e3
L2: ...

so, something like "e1 ? : e3" could consistently compile to something like:

calculate e1
jump-if-zero L1
jump-always L2
L1: calculate e3
L2: ...

i.e. just missing the "calculate e2" line, corresponding to the absence
of code in this part of the expression. (yes yes, the two adjacent
jumps can be reduced to one jump.)

Obviously, this would not break any existing code as "e1 ? : e2" is
currently a syntax error. And I think this answers Karl Heuer's
question quoted above.

ajr
--
"noalias considered sailaon"

Brian T. Schellenberger

unread,
Feb 19, 1988, 12:59:50 AM2/19/88
to
|> In article <5...@naucse.UUCP> r...@naucse.UUCP (Bob Rose ) writes:
|> >But wait, we can do better [than the proposed ",,"]. ...
|> > i(x1, x2, x3, ..., xn)
|> >[where 1 <= i <= n; the result is xi]
|> ... If `i' is allowed to be an arbitrary integral <problems?>

Actually, there is a much more natural and powerful way to handle this in D:
one of the nicer things about C is the way you can get letters out of strings
by doing things like:

"abcdefghijklmnopqrstuvwxyz"[letter]

Why not extend this and allow in-line arrays? This would allow the "choose"
operator to work as, for example:

array int {x1, x2, x3, ...}[i]

This of course means that "abc" is exactly the same as

array char {'a', 'b', 'c', '\0'}


. . . just another silly idea.
--
--Brian.
(Brian T. Schellenberger) ...!mcnc!rti!sas!bts

DISCLAIMER: Whereas Brian Schellenberger (hereinafter "the party of the first

gary sarff

unread,
Feb 19, 1988, 2:09:29 PM2/19/88
to

I am interested in "alternative" computer languages, and the ICON computer
language has structures such as are being talked about here, for a general
pick (nth) operator, the exact syntax of <expr>(x1,x2...xn) is used.
<expr> can be an integer constant, an arithmetic expression, the name of
a function in which case the function will be called with all the xi's as
arguments. One can also use &'s instead of commas in which case expression
failure of an xi causes failure of the rest of the expressions and evaluation
halts there. All three <expr> types are handled uniformly, (ICON is written
in C) they all pass through the same C code since something like
2(a,b,c) can be looked at as a function named "2" that returns its second
argument, (but all of them get evaluated anyway).


--
Gary Sarff {uunet|ihnp4|philabs}!spies!argus!gsarff
To program is human, to debug is something best left to the gods.
"Spitbol?? You program in a language called Spitbol?"
The reason computer chips are so small is that computers don't eat much.

Chris Torek

unread,
Feb 20, 1988, 9:16:40 AM2/20/88
to
In article <27...@mmintl.UUCP> fra...@mmintl.UUCP (Frank Adams) writes:
>Any serious effort to design a successor to C (which does not attempt to be
>upward compatible) should first consider what should be taken out and/or
>done differently. Adding new things is secondary.

Uh oh. A ray of sensibility on the net! :-)

Oddly enough (or perhaps given the impending Standard, it is not
so odd), I have been considering the same sort of thing myself.
For those who want to wade through details (such as they are), they
appear below.

One of the nicest things about the C language is what it does NOT
do. The language is small enough to learn and comprehend entirely
in a short time; the list of language oddities is not empty, but
is small (most of them appear below).

>The first thing I would remove is the automatic conversion of arrays to
>pointers.

I am not sure I would make this `first', but I agree. In fact, this
is a side effect of what I would do with aggregate types.

>Second on the list is defaulting of variables. An undeclared variable
>should be an error, not an int.

(An undeclared variable *is* an error, unless you claim `register i'
leaves `i' undeclared.)

>Likewise for functions.

agree; unsure about C++/ANSI syntax

>Another thing that should go is the assumption that the unit of storage is
>the byte.

I thought about this; it gets sticky, and I am still unsure. C's
structure bitfields are the wrong way to get at bits; in particular,
it would be nice to have arrays of bits. But the basic unit of
storage has a way of creeping into the rest of the language, no
matter how hard one attempts to keep them apart.

>I would also like to do away with having control statements control single
>statements. For example, instead of writing "if (foo) {stmt1; stmt2;}" I
>would write "if (foo) stmt1; stmt2; end;". Likewise, I would rewrite the
>"for" statement as "for <stmts> while (<exp>) next <stmts> do <stmts> end;".
>The "while" and "do ... while" I would generalize to "loop <stmts> while
>(<exp>) <stmts> end;".

I disagree with the details, but will note that some human factors
studies have shown (and I agree) that a paired `end' is better than
a single `end', e.g., `if e stmts endif', `while e stmts endwhile'.
On the other hand, other studies have shown that `noise words' inhibit
understanding. I am undecided about this.

>Another shortcoming to be fixed is the automatic fallthrough for select
>statements.

agree

>To get even more radical -- with typedefs, enums, const declarations, and
>(if we add them) inline functions, do we really need the pre-processor any
>more?

Probably. Inline functions should most certainly be added; they
nearly obviate the need for macros.

>I would omit the automatic insertion of a null byte at the end of character
>constants. If you want nul terminated strings, write the nul. If you want
>strings with counts, the language should not get in your way.

A general aggregate constructor is necessary. A specific version of
one that constructs null-terminated strings might be declared in
<strings.h> (or its equivalent). I would like to be able to create
C-style arrays (blocks of memory) as easily as `real arrays' (with
dope vectors). If I could come up with some way of merging arrays
and structures/unions into a single `aggregate' type....

>I think I would also drop the convention that 0 is a null pointer. Make
>"null" a keyword, representing a null pointer of any type.

This would, at one stroke, eliminate half the confusion that plagues
comp.lang.c .... (about 1/3 :-) )

I think the following are important considerations:

- the language should be made as small as possible, but no smaller.

- we should assume that compilers for this language are going to
do a great deal of optimisation; in particular, they will optimise
across entire compilations, not just single files.

- it should be relatively easy to translate `old C' to the new
language.

- it might also be a good idea to steal liberally from C++ (which
of course steals liberally from SIMULA and others).

Very few of my ideas along this line are firm. My biggest worry
is that if the language is too small and malleable, it will suffer
from the same problems as some of the old dynamically-extensible
languages. One solution is to make the language small but the
support `library' (including headers that define standard aggregates
like C-style arrays and strings) a `part' of the language.
--
In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163
(hiding out on trantor.umd.edu until mimsy is reassembled in its new home)
Domain: ch...@mimsy.umd.edu Path: not easily reachable

Doug Gwyn

unread,
Feb 20, 1988, 11:15:33 AM2/20/88
to
In article <23...@umd5.umd.edu> ch...@trantor.umd.edu (Chris Torek) writes:
>>Another thing that should go is the assumption that the unit of storage is
>>the byte.
>I thought about this; it gets sticky, and I am still unsure. C's
>structure bitfields are the wrong way to get at bits; in particular,
>it would be nice to have arrays of bits. But the basic unit of
>storage has a way of creeping into the rest of the language, no
>matter how hard one attempts to keep them apart.

It isn't that bad, really -- I once went through an earlier C dpANS
and identified all the changes necessary to support a distinction
between "byte" (smallest accessible storage unit, which could be a
bit if you wanted to make it so) and "character" (smallest unit of
text). The particular type names I used were "short char" and "char",
respectively. It turned out that it wasn't too difficult to make
the distinction. The idea lost out to the "multi-byte character"
approach embodied in the current draft, which is a pity since that
doesn't support bit addressability and it requires specific calls
to convert MBC sequences to and from textual units (wchar_t). If
you guys really are planning on developing the language D, I hope
you'll consider something along these lines. By the way, if that
becomes a real project, it should get its own mailing list; there's
too many suggestions for changes to C in this newsgroup already..

Eddie Wyatt

unread,
Feb 20, 1988, 12:54:46 PM2/20/88
to

> >Another shortcoming to be fixed is the automatic fallthrough for select
> >statements.
>
> agree

However, some means of fall through should be provided, BUT it should be
explicitly expressed.


>
> >To get even more radical -- with typedefs, enums, const declarations, and
> >(if we add them) inline functions, do we really need the pre-processor any
> >more?
>
> Probably. Inline functions should most certainly be added; they
> nearly obviate the need for macros.

Not probably, definately we still need the pre-processor. The
pre-processor supports a limited form of types as parameters.
Example:

#define alloc(type) ((type *) malloc(sizeof(type)))

Unless you are going to support some other form of polymorphism that
will allow the above to be expressed, leave in the pre-processor.

> >I think I would also drop the convention that 0 is a null pointer. Make
> >"null" a keyword, representing a null pointer of any type.
>
> This would, at one stroke, eliminate half the confusion that plagues
> comp.lang.c .... (about 1/3 :-) )

Unless you require function prototypes to be within scope, null
will not do you much good.

>
> I think the following are important considerations:
>
> - the language should be made as small as possible, but no smaller.

I agree, a very very very important point.

>
> - we should assume that compilers for this language are going to
> do a great deal of optimisation; in particular, they will optimise
> across entire compilations, not just single files.

Which brings up a question, what happens to the asm statement then.
If you have the write you code such that you have no idea
where variables are stored, how can you reliable use assemble statement
that play with storage. I think the conclusion will be trash asm.


--

Eddie Wyatt e-mail: e...@ius1.cs.cmu.edu

John B. Nagle

unread,
Feb 20, 1988, 2:33:19 PM2/20/88
to

Let me suggest a few ground rules for designing a successor to C:

1) It need not be upward compatible with C, but automatic upward
translation should be possible. At the very least, automatic
translation with reliable automatic flagging of nonportable
constructs should be possible.

2) Syntactic changes should be avoided unless a definite gain can
be shown. "I like it better another way" is not sufficient.
Changes to syntax tend to arouse opposition all out of proportion
to their importance. The major problems in language design are
not syntatic.

3) C started life as a weakly typed language, and has been modified
slowly into a strongly typed one. This has resulted in some
strange semantics. This needs to be dealt with.

4) The basic model of a static language close to the machine should
be retained. Attempts to bolt on a very dynamic environment
with heavy underlying machinery, along the lines of LISP or
Smalltalk, should be resisted.

5) The semantics of types is probably the most important issue
to be addressed.

6) The semantics of finite-precision integer arithmetic need to
very well thought out. The semantics of arithmetic should
be independent of the underlying hardware, so that the same
answer is obtained on all machines for all valid operations.
(This is possible, and can be done efficiently, but the
solutions are not well known.)


John Nagle

Charles Daffinger

unread,
Feb 21, 1988, 5:47:38 PM2/21/88
to
In article <27...@mmintl.UUCP> fra...@mmintl.UUCP (Frank Adams) writes:
>
>Any serious effort to design a successor to C (which does not attempt to be
>upward compatible) should first consider what should be taken out and/or
>done differently. Adding new things is secondary.
>
[lots of oh, so familiar changes which just don't look like C...]

I think the language you want was already designed by Nicolas Wirth: Pascal.


-charles

--
Charles Daffinger \ Take me to the river / (812) 339-7354
Box 1662 \ drop me in the water / cd...@iuvax.cs.indiana.edu
Bloomington, IN 47402-1662 {pur-ee,rutgers,pyramid,ihnp4}!iuvax!cdaf
Home of the Whitewater mailing list: whitewate...@iuvax.cs.indiana.edu

David Keppel

unread,
Feb 21, 1988, 7:51:00 PM2/21/88
to
In article <9...@PT.CS.CMU.EDU> e...@IUS1.CS.CMU.EDU (Eddie Wyatt) writes:
>> - we should assume that compilers for this language are going to
>> do a great deal of optimisation; in particular, they will optimise
>> across entire compilations, not just single files.
>
> Which brings up a question, what happens to the asm statement then.
>If you have the write you code such that you have no idea
>where variables are stored, how can you reliable use assemble statement
>that play with storage. I think the conclusion will be trash asm.

I think not. I think it will be to change the semantics of asm into a
varargs function (which may even have the register allocator at its
disposal?):

void
dumb_function( doit_to )
int *splat;
{
enum Labels { START = 1, LOOP, DONE };
extern int splodge;
int r1, r2;

_reg_alloc(2);
asm( START, "movl", ADDR, &splodge, REG, r1 = _register() );
asm( 0, "clrl", REG, r2 = _register() );
asm( LOOP, "tstl", REG, r2 );
asm( 0, "bgeq" LAB, DONE );
asm( 0, "addl", ADDR, sizeof( some_type ), REG, r1 );
asm( 0, "subl", ADDR, sizeof( some_type ), ADDR, splat );
asm( 0, "brb", LOOP );
asm( DONE, NULL );
_reg_unalloc();
/* r1 is just thrown away ... */
}

Alternatively, the opcode could specify the format of the arguments that
it takes (much as printf works), but I think this is unnatural, since if
you had a bunch of typedefs, you couldn't just do:

#ifdef VAX
#define ADD "addl"
#else
#define ADD "add"
#endif

(or something slightly less sick, but I hope this puts the idea across).

No, I haven't thought to closely about this, there may be some fatal flaw.
The worst thing is that this is almost portable ;->

;-D on (Well, C is just portable SNOBOL ;-) Pardo

Johnson Noise

unread,
Feb 21, 1988, 8:09:36 PM2/21/88
to
In article <63...@iuvax.UUCP> cd...@iuvax.UUCP (Charles Daffinger) writes:
>In article <27...@mmintl.UUCP> fra...@mmintl.UUCP (Frank Adams) writes:
>>
>>Any serious effort to design a successor to C (which does not attempt to be
>>upward compatible) should first consider what should be taken out and/or
>>done differently. Adding new things is secondary.
>>
>[lots of oh, so familiar changes which just don't look like C...]
>
>I think the language you want was already designed by Nicolas Wirth: Pascal.
>
>
>-charles
>

Yeah, I think so. There are even those who want to change
= to :=. Computer users (I stress users -- see below) seem to be the
biggest complainers of all "scientists". Algol and PL/1 were designed
a long time ago, everyone thought that they would be THE programming
languages for all humanity/applications. Now people think that ADA
and Modula 2 are THE programming languages. Not many people stop to
look at history. C was just something Ritchie came up with -- it
wasn't a _software_engineering_environment_, just a simple, portable,
utility. It has probably become (along with UN*X) the second greatest
computer science accomplishment ever. It was not due to some great
"design by commitee", just necessity.
A guy I work with sometimes asks the question: "now that we
have all these great modular languages like ADA and Modula 2, I would
think there would be more software using them". This has to do with
Mac stuff which is mostly written in C. The answer is simple: computer
systems people (I stress systems people -- see below) are more interested
in getting the job done. Let's face it, a compiler is just a tool.
It does not write code for you, it does not find algorithmic errors
for you, it is just a way to avoid assembly (this is the reason FORTRAN
is the first greatest computer science accomplishment).
If you don't like C, don't use it. There must be at least 100
different programming languages, none of which are radically different
from Algol, FORTRAN, or LISP. All three of these were invented in the
late 50's-early 60's, so I think you can find what you are looking for
in some variant.
C was designed as a systems implementation language, not THE
language for all humanity/applications. I think it does a very, very
good job. What most people are suggesting (with respect to D) is
another Algol, PL/1, ADA, Modula 2 and whatever else comes up in the
next five years. It will suffer the same fate: crash and burn.


#define systems_person one who gets the job done

#ifdef systems_person
#define user !systems_person
#else
#define user one who waits for someone|something to do the job for him
#endif

I think Henry Spencer's quote says it all: "those who do not understand
UNIX are condemned to reinvent it, poorly".

This is not meant as a flame, just my personal observations.

Herman Rubin

unread,
Feb 22, 1988, 7:56:20 AM2/22/88
to
In article <42...@june.cs.washington.edu>, pa...@june.cs.washington.edu (David Keppel) writes:
> In article <9...@PT.CS.CMU.EDU> e...@IUS1.CS.CMU.EDU (Eddie Wyatt) writes:
> >> - we should assume that compilers for this language are going to
> >> do a great deal of optimisation; in particular, they will optimise
> >> across entire compilations, not just single files.
> >
> > Which brings up a question, what happens to the asm statement then.
> >If you have the write you code such that you have no idea
> >where variables are stored, how can you reliable use assemble statement
> >that play with storage. I think the conclusion will be trash asm.

If we have the compiler replace names by locations (register and/or memory)
of the variables used, there is no more problem with global optimization
than before. In fact, we should do this in C; it is not prohibited by the
language standards, and it certainly makes more sense to be able to write
assembler statements in which the location of the variable is inserted by
the compiler.

Most of the C compilers I know do not do this; it is at the least annoying
not to be able to write such things as

asm(" addl x,y,z");
asm(" addwc u,v,w");

and have the compiler include those location for the variables. (What I do
is to first compile as above and then edit, but it does not always work.)
We also should get rid of those quotes in the process; since asm is a reserved
operator, and its structure requires that what follows starts with ("
and ends with "), while the parentheses may be useful as separators, the
quotes are totally unnecessary (and have been known to cause errors).
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hru...@l.cc.purdue.edu (ARPA or UUCP) or hru...@purccvm.bitnet

mcdo...@uxe.cso.uiuc.edu

unread,
Feb 22, 1988, 9:19:00 AM2/22/88
to

I find it hard to believe that a successor to C is needed or would be
appreciated. I come to this as a former 100% Fortran (and assembler)
programmer who now uses C about 80 % of the time. C does have a few,
minor defects (for instance, I will never , ever understand the syntax
of declarations; I have had a guru make up a huge chart listing dozens of
them, which I carry in my wallet.) So does every other language. C does
one thing extremely well: convert the heart of the machine operations of
a byte-addressible, conventional processor (i.e. the PDP11) into a nice
higher language. It is pleasantly compact, and very full of nice
shortcuts (e.g. "string"[i] ). If you dislike C , try other languages:
Fortran, Pascal, Ada ,Modula 2. Me, well , I like C and Fortran and loathe
the rest. But if a new language is to be designed, and done really well, it
won't be done by committee. For the perfect example look in comp.lang.fortran
and read about 88tran, the totally new language with two heads, brought
to you by X3J3.

Gideon Yuval

unread,
Feb 23, 1988, 2:11:46 PM2/23/88
to

> very well thought out. The semantics of arithmetic should
> be independent of the underlying hardware, so that the same
> answer is obtained on all machines for all valid operations.
> (This is possible, and can be done efficiently, but the
> solutions are not well known.)

Indeed they are not. Can you post a pointer to these solutions?
--
Gideon Yuval, +972-52-522255 (work), -2-690992 (home), yu...@taux02.nsc.com

Frank Adams

unread,
Feb 23, 1988, 4:23:40 PM2/23/88
to
In article <23...@umd5.umd.edu> ch...@trantor.umd.edu (Chris Torek) writes:
|In article <27...@mmintl.UUCP> fra...@mmintl.UUCP (Frank Adams) writes:
|>Any serious effort to design a successor to C (which does not attempt to be
|>upward compatible) should first consider what should be taken out and/or
|>done differently. Adding new things is secondary.
|
|Oddly enough, I have been considering the same sort of thing myself. One of

|the nicest things about the C language is what it does NOT do. The language
|is small enough to learn and comprehend entirely in a short time; the list
|of language oddities is not empty, but is small (most of them appear below).

Agreed.

|>I would also like to do away with having control statements control single

|>statements. ... "if (foo) stmt1; stmt2; end;" ...
|>"for <stmts| while (<exp|) next <stmts| do <stmts| end;" ...


|>"loop <stmts| while (<exp|) <stmts| end;".
|
|I disagree with the details,

I would like to see other proposals.

|[may prefer 'endif' to 'end', but has doubts]

I debated whether to put in 'endif', etc., or 'end' in the above, and
finally opted for the shorter form. Ask me on another day and you might get
a different answer.

|A general aggregate constructor is necessary.

Any suggestions on how to do this?

|I think the following are important considerations:
|
| - the language should be made as small as possible, but no smaller.
|
| - we should assume that compilers for this language are going to
| do a great deal of optimisation; in particular, they will optimise
| across entire compilations, not just single files.

I don't think we should *require* this. The language should still have a
place for the fast and cheap compiler, which still produces reasonably good
code.

| - it should be relatively easy to translate `old C' to the new
| language.
|
| - it might also be a good idea to steal liberally from C++ (which
| of course steals liberally from SIMULA and others).

Yes, but I would not put the object oriented stuff into D. For that, you
get D++.

Overloaded functions are fine, though.

|My biggest worry is that if the language is too small and malleable, it
|will suffer from the same problems as some of the old dynamically-extensible
|languages. One solution is to make the language small but the support
|`library' (including headers that define standard aggregates like C-style
|arrays and strings) a `part' of the language.

Definitely. Library development should go on in parallel to the language
development, and whatever flexibility the language provides should be
reflected in the library.

Richard Harter

unread,
Feb 25, 1988, 4:35:33 AM2/25/88
to
In article <27...@mmintl.UUCP> fra...@mmintl.UUCP (Frank Adams) writes:
>In article <23...@umd5.umd.edu> ch...@trantor.umd.edu (Chris Torek) writes:
>
>|[may prefer 'endif' to 'end', but has doubts]
>
>I debated whether to put in 'endif', etc., or 'end' in the above, and
>finally opted for the shorter form. Ask me on another day and you might get
>a different answer.

Here is an alternative to endif et al. Use labels to start blocks and
'end labels' to end them. For example,

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.
--

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
Richard Harter, SMDS Inc.

Richard Tobin

unread,
Feb 25, 1988, 12:43:09 PM2/25/88
to
In article <9...@PT.CS.CMU.EDU> e...@IUS1.CS.CMU.EDU (Eddie Wyatt) writes:
>> >I think I would also drop the convention that 0 is a null pointer. Make
>> >"null" a keyword, representing a null pointer of any type.
>> This would, at one stroke, eliminate half the confusion that plagues
>> comp.lang.c .... (about 1/3 :-) )
> Unless you require function prototypes to be within scope, null
>will not do you much good.

Ah, but if you you don't make the representation of the null pointer
be the same as that of an integer (or anything else) then you can make
it illegal to pass it (uncast) to a function for which there is no
prototype. You can't do that with zero, unless you want to have to say
(int)0 to pass an integer zero.

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.

-- Richard
--
Richard Tobin, JANET: R.T...@uk.ac.ed
AI Applications Institute, ARPA: R.Tobin%uk.a...@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin

Henry Spencer

unread,
Feb 25, 1988, 3:22:37 PM2/25/88
to
> ... An undeclared variable should be an error, not an int.

Um, perhaps you should learn C before you start designing D...? An
undeclared variable *is* an error.

> 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.

Here we have a key decision: is D to share C's emphasis on generation
of efficient code? (Bearing in mind that this had a lot to do with C's
success.) If so, then trying to forget that bytes exist is a serious
mistake. Most machines cannot handle bits with anywhere near the efficiency
with which they handle bytes; the appropriate base unit for efficient code
*is* the byte.

> ... In keeping with the spirit of C, we avoid


> superfluous words, and keep the ones we do use short.
>
> With these changes, the {} statement delimiters become much less useful. I

> would probably drop them, and add a "begin ... end;" construct...

Please explain how avoiding superfluous words and keeping necessary ones
short is consistent with changing {/} to begin/end for no particular reason.

> To get even more radical -- with typedefs, enums, const declarations, and
> (if we add them) inline functions, do we really need the pre-processor any

> more? ...

The C++ people claim that the answer is "not much", given inline functions
in particular. They do still use it for some specialized problems, though.

> I would omit the automatic insertion of a null byte at the end of character
> constants. If you want nul terminated strings, write the nul. If you want
> strings with counts, the language should not get in your way.

Pray tell, how do you write a counted-string constant? I would suggest
that "abc" should mean a length-3 string with any necessary terminator,
regardless of what flavor of string is in use. That way you get a choice,
without recoding all your string constants.
--
Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology
condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry

Henry Spencer

unread,
Feb 25, 1988, 3:34:25 PM2/25/88
to
> If we have the compiler replace names by locations (register and/or memory)
> of the variables used...

This does of course assume that all locations are addressable in all
instructions, which is emphatically not the case on many machines.

> We also should get rid of those quotes in the process...

What if I want to write asm("mov ')', r0")? The quotes are a reasonable way
of keeping the syntax of the assembler entirely out of the compiler's own
syntax handling, which is a good thing, especially for portable compilers.

Mark Brader

unread,
Feb 25, 1988, 7:19:57 PM2/25/88
to
> Any serious effort to design a successor to C (which does not attempt to
> be upward compatible) should first consider what should be taken out and/or
> done differently. Adding new things is secondary.
>
> The first thing I would remove is the automatic conversion of arrays to
> pointers.

So far I agree.

> (A consequence of this change is that "a[b]" is no longer definable as
> "*(a + b)".

Here I disagree. We can have it both ways. Allow automatic conversion
of arrays to pointers *where pointers are required*. That is, if you say
"b = a;", where a is an array, you get *either* a pointer assignment or
an array assignment, depending on whether b is a pointer or array variable.

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.

Mark Brader "C takes the point of view
SoftQuad Inc., Toronto that the programmer is always right"
utzoo!sq!msb, m...@sq.com -- Michael DeCorte

gordan

unread,
Feb 26, 1988, 11:12:29 PM2/26/88
to
-> ... An undeclared variable should be an error, not an int.
-
- [various flames stating that an undeclared variable *is* an error]


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_.").

Of course, in the above example, 'b' is not a variable, but a formal
parameter. Still, this is a problem... I once had a hard-to-find bug
that resulted from a missing formal parameter declaration defaulting to
int. _Has_ this been changed in ANSI C?
--
I am the Lizard King "Vous cherchez Jim, Monsieur?"
and I can do anything
-- caretaker at Gordan Palameta
-- Jim Morrison Pere Lachaise mnetor!lsuc!maccs!gordan

James Jones

unread,
Feb 27, 1988, 4:25:54 AM2/27/88
to
In article <1988Feb25....@utzoo.uucp>, he...@utzoo.uucp (Henry Spencer)
writes:

> > ... An undeclared variable should be an error, not an int.
>
> Um, perhaps you should learn C before you start designing D...? An
> undeclared variable *is* an error.

Perhaps the original author was referring to letting undeclared identifiers
which are followed by something that looks like an actual parameter list
default to being an extern function returning int, and to the ability to
elide int from declarations (which, if I rightly understand the X3J11 Draft,
can still be done as long as there's *some* keyword that lets the compiler
conclude that it's looking at a declaration). If that's indeed what the
original author was referring to, I sincerely agree with him. (It would
be nice if X3J11 deprecated it, too--which it may have, I don't recall.)

James Jones

Richard A. O'Keefe

unread,
Feb 27, 1988, 6:39:48 AM2/27/88
to
In article <24...@cca.CCA.COM>, g-...@cca.CCA.COM (Richard Harter) writes:
> Here is an alternative to endif et al. Use labels to start blocks and
> 'end labels' to end them. For example,
>
> if (boolean expression)
> foo: ....
> end foo
> else
> bar: ....
> end bar
>
He has just re-invented BCPL. Where C has { and }, BCPL had $( and $).
The name for these was "section brackets". There was an extra hack:
"tagged section brackets". If <id> looked like an identifier,
$(<id> and $)<id> were tagged section brackets (each was a single token).
So in BCPL this example would be
TEST boolean-expression THEN
$(FOO
...
$)FOO
ELSE
$(BAR
...
$)BAR

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.

Can anyone who has experience with using this feature suggest why it has
remained rare. In particular, does anyone know why it isn't in C, given
that it was in BCPL? (Not that I think it's needed.)

Herman Rubin

unread,
Feb 27, 1988, 6:51:56 AM2/27/88
to
In article <1988Feb25....@utzoo.uucp>, he...@utzoo.uucp (Henry Spencer) writes:
> > If we have the compiler replace names by locations (register and/or memory)
> > of the variables used...
>
> This does of course assume that all locations are addressable in all
> instructions, which is emphatically not the case on many machines.

This is another reason for the user to be able to force the compiler to put
things in registers. The stupid compiler should not be able to force the
user to use many instructions because it does not see the need for register
variables. This applies also to such constructs as register pairs, triples,
etc. Naturally, this would require some way of modifying the register number,
but so what? This is simple, compared to the machinations that compilers
now undertake.

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?

> > We also should get rid of those quotes in the process...
>
> What if I want to write asm("mov ')', r0")? The quotes are a reasonable way
> of keeping the syntax of the assembler entirely out of the compiler's own
> syntax handling, which is a good thing, especially for portable compilers.

Someone has posted an example where the failure was due to a " in the assembler
instruction. It is just as easy, since C requires a ; to end a statement, to
tell the compiler that until it sees ); to continue processing for the
assembler, and to have some escape mechanism for inserting ); into the
assembler statement. Alternatively, if we get rid of the ;s as mandatory
terminators (which I think is a good idea), have an escape mechanism for
inserting ) in an assembler statement. Is this worse than not being able
to put ", or even "), in an assembler statement?

Richard Harter

unread,
Feb 27, 1988, 6:14:38 PM2/27/88
to
In article <7...@cresswell.quintus.UUCP> o...@quintus.UUCP (Richard A. O'Keefe) writes:
>In article <24...@cca.CCA.COM>, g-...@cca.CCA.COM (Richard Harter) writes:
>> Here is an alternative to endif et al. Use labels to start blocks and
>> 'end labels' to end them....

>He has just re-invented BCPL.

Er, you give me too much credit. A feature of BCPL, perhaps,
but not the whole thing> :-)

>Where C has { and }, BCPL had $( and $).
>The name for these was "section brackets". There was an extra hack:
>"tagged section brackets". If <id> looked like an identifier,
>$(<id> and $)<id> were tagged section brackets (each was a single token).
>So in BCPL this example would be
> TEST boolean-expression THEN
> $(FOO
> ...
> $)FOO
> ELSE
> $(BAR
> ...
> $)BAR

>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.
>
>Can anyone who has experience with using this feature suggest why it has
>remained rare. In particular, does anyone know why it isn't in C, given
>that it was in BCPL? (Not that I think it's needed.)

As it turns out I do have experience with this exact feature in PL/I.
I once inherited a 40,000 line PL/I program with a 5000 line main program
which used nested tagged begin/end blocks. I can tell you that multiple
closure is a real disaster. Fundamentally, the problem is that you can
remove an end statement, thereby changing the block structure of the program,
and the program is still syntactically correct and compiles. In a large
program which runs across many pages you can't visually confirm that all
the blocks align properly. It's been a long time now, and I can't recall
the gory details any more. However the practical effect was the same as
having a C switch construct with some of the terminating case 'break'
statements unintentionally missing.

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.

Doug Gwyn

unread,
Feb 27, 1988, 7:32:41 PM2/27/88
to
In article <1988Feb25....@utzoo.uucp> he...@utzoo.uucp (Henry Spencer) writes:
>Most machines cannot handle bits with anywhere near the efficiency
>with which they handle bytes; the appropriate base unit for efficient code
>*is* the byte.

Be careful; cause and effect are circular here. I've been contacted by
more than one computer architect who wanted bit addressability but had
trouble convincing management to accept the slightly added expense because
they would observe that such a facility could not be exploited from popular
high-level languages. In fact, I have many applications for bit arrays
and bit maps, and there is a severe performance penalty caused by lack of
hardware support for them (and high-level language access to such support).

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...

>Please explain how avoiding superfluous words and keeping necessary ones
>short is consistent with changing {/} to begin/end for no particular reason.

A better reason for a change here is the problems cause by "dangling else"
and accidental ";" after the closing ")" of a while(). The idea that such
clauses control a single statement (which might be a compound statement)
makes C susceptible to such errors; using unique bracketing keywords would
be safer.
while condition do ;-separated_statements done
if condition then ;-separated_statements else ;-separated_statements fi
If would also be nice if such statements could return values (so ?: could
be dispensed with). Better yet, adopt notation more supportive of concurrent
processing, such as Dijkstra's "guarded" commands. Why not support the future?

Doug Gwyn

unread,
Feb 27, 1988, 7:49:01 PM2/27/88
to
In article <10...@maccs.UUCP> gor...@maccs.UUCP (gordan) writes:
>... defaulting to int. _Has_ this been changed in ANSI C?

No, like other warts, since this is widely used in correctly-written
(according to K&R rules) C code, and since it does not pose any true
technical problems, it must continue to be tolerated. Fix it in "D".

a...@alice.uucp

unread,
Feb 28, 1988, 9:16:50 PM2/28/88
to
The best scheme I've seen for labelled blocks comes from SETL.
In SETL, statements like `IF' and `WHILE' begin blocks which
must be ended by `END' statements. Thus one can write:

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;

These tokens are optional, but if they appear, they must match
the corresponding tokens from the opening statement.

Ralf....@b.gp.cs.cmu.edu

unread,
Feb 29, 1988, 8:06:01 AM2/29/88
to

In article <24...@cca.CCA.COM>, g-...@cca.CCA.COM (Richard Harter) writes:
}As a side point, I like the suggestion that someone made that there be
}a fallthrough statement rather than automatic fallthrough.

So, you would like to have to write
switch(var)
{
case foo: fallthrough;
case bar: fallthrough;
case baz: fallthrough;
case mung: /* code to do something for all four cases */
}
?

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

--
{harvard,uunet,ucbvax}!b.gp.cs.cmu.edu!ralf -=-=- AT&T: (412)268-3053 (school)
ARPA: RA...@B.GP.CS.CMU.EDU |"Tolerance means excusing the mistakes others make.
FIDO: Ralf Brown at 129/31 | Tact means not noticing them." --Arthur Schnitzler
BITnet: RALF%B.GP.CS.CMU.EDU@CMUCCVMA -=-=- DISCLAIMER? I claimed something?

Guy Middleton

unread,
Feb 29, 1988, 1:27:07 PM2/29/88
to
In article <24...@cca.CCA.COM> g-...@CCA.CCA.COM.UUCP (Richard Harter) writes:
> In article <7...@cresswell.quintus.UUCP> o...@quintus.UUCP (Richard A. O'Keefe) writes:
> >In article <24...@cca.CCA.COM>, g-...@cca.CCA.COM (Richard Harter) writes:
> >> Here is an alternative to endif et al. Use labels to start blocks and
> >> 'end labels' to end them....
>
> >He has just re-invented BCPL.

There is another thing that should be reintroduced: case ranges in switch
statements. These were part of B (although they were not in BCPL):

switch (x) {
case <0: /* ... */
break;
case 0::10: /* ... */
break;
case >10: /* ... */
default:
}

John Stanley

unread,
Feb 29, 1988, 3:28:49 PM2/29/88
to

>> 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.

---
John Stanley (jo...@viper.UUCP)
Software Consultant - DynaSoft Systems
UUCP: ...{amdahl,ihnp4,rutgers}!meccts!viper!john

Jonathan Leffler

unread,
Feb 29, 1988, 4:08:59 PM2/29/88
to
In article <63...@iuvax.UUCP> cd...@iuvax.UUCP (Charles Daffinger) writes:
>I think the language you want was already designed by Nicolas Wirth: Pascal.

More likely: Modula-2

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

#include <disclaimer.h>
Jonathan Leffler (jo...@sphinx.co.uk)

Frank Adams

unread,
Feb 29, 1988, 6:07:47 PM2/29/88
to
In article <24...@cca.CCA.COM> g-...@CCA.CCA.COM.UUCP (Richard Harter) writes:
| if (boolean expression)
| ....
| end
| else
| ....
| end

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.

Frank Adams

unread,
Feb 29, 1988, 6:40:56 PM2/29/88
to
In article <1988Feb25....@utzoo.uucp> he...@utzoo.uucp (Henry Spencer) writes:
>> ... An undeclared variable should be an error, not an int.
>
>Um, perhaps you should learn C before you start designing D...? An
>undeclared variable *is* an error.

Mea culpa. The C compilers I use give warnings for undeclared functions and
several other things, which I treat as errors; so sometimes I forget which
ones are really errors.

The point still stands as regards undeclared functions, though.

>> 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.
>
>Here we have a key decision: is D to share C's emphasis on generation
>of efficient code?

Yes.

>If so, then trying to forget that bytes exist is a serious
>mistake. Most machines cannot handle bits with anywhere near the efficiency
>with which they handle bytes; the appropriate base unit for efficient code
>*is* the byte.

This makes C nicely efficient on *many* machines; but there are others on
which a larger size would be much better. Not every machine is byte
addressable.

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.

>> ... In keeping with the spirit of C, we avoid
>> superfluous words, and keep the ones we do use short.
>>
>> With these changes, the {} statement delimiters become much less useful. I
>> would probably drop them, and add a "begin ... end;" construct...
>
>Please explain how avoiding superfluous words and keeping necessary ones
>short is consistent with changing {/} to begin/end for no particular reason.

I was thinking that with the other changes I proposed, the compound
statement would be needed only for declaring variables local to part of a
function. This use is not important enough to justify allocating two special
symbols to it.

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.

>> do we really need the pre-processor any more? ...
>
>The C++ people claim that the answer is "not much", given inline functions
>in particular. They do still use it for some specialized problems, though.

Overall, the preprocessor seems to be used as a way to hack prototypes for
the next extension to the language. C++ people tend to use it for
parameterized types, early C used it for consts and enums, etc. This may be
an argument for keeping it.

>> I would omit the automatic insertion of a null byte at the end of character
>> constants. If you want nul terminated strings, write the nul. If you want
>> strings with counts, the language should not get in your way.
>
>Pray tell, how do you write a counted-string constant?

struct string {char * data; int size};
char dummy[] = "This is my string."
struct string s = {&dummy, sizeof(dummy)};

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

>I would suggest that "abc" should mean a length-3 string with any necessary
>terminator, regardless of what flavor of string is in use. That way you get
>a choice, without recoding all your string constants.

And how do you specify what flavor of string is "is use?".

Frank Adams

unread,
Feb 29, 1988, 6:46:24 PM2/29/88
to
Clearly, assembler statements should have been defined as:

#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).

Dave Decot

unread,
Feb 29, 1988, 10:45:27 PM2/29/88
to
Array first-class-ness and aggregate constants could be easily provided
within C (not that I want to discourage D-zigners; it's a meritorious idea).

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 */
}


reduce(a, n)
int a[100][100];
int n;
{
/* ... */
}

Barnacle Wes

unread,
Mar 1, 1988, 1:39:45 AM3/1/88
to
Frank, if you want to write your programs in Ada, write them in Ada.
Don't try to re-write a C compiler to accept Ada programs. In fact,
you should re-post this message in comp.lang.ada, I think you'd find a
more receptive audience there. Since the name Ada has already been
used, and your language is sufficiently different from C to NOT name
it D, perhaps you could call it "DoD". But that's been used, too,
hasn't it?

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

--
/\ - "Against Stupidity, - {backbones}!
/\/\ . /\ - The Gods Themselves - utah-cs!utah-gr!
/ \/ \/\/ \ - Contend in Vain." - uplherc!sp7040!
/ U i n T e c h \ - Schiller - obie!wes

Dave Sill

unread,
Mar 1, 1988, 1:23:13 PM3/1/88
to
In article <2258...@uxe.cso.uiuc.edu> mcdo...@uxe.cso.uiuc.EDU writes:
>I find it hard to believe that a successor to C is needed or would be
>appreciated.

Yes, C is adequate for most of today's needs. But it does have its
problems and weaknesses. If we want to have a language to take its
place tomorrow, we had better start thinking about it today, though.

>I come to this as a former 100% Fortran (and assembler)
>programmer who now uses C about 80 % of the time. C does have a few,
>minor defects (for instance, I will never , ever understand the syntax
>of declarations; I have had a guru make up a huge chart listing dozens of
>them, which I carry in my wallet.) So does every other language.

To varying degrees. Hopefully D will learn from C, and at least not
repeat the same mistakes.

>C does
>one thing extremely well: convert the heart of the machine operations of
>a byte-addressible, conventional processor (i.e. the PDP11) into a nice
>higher language.

Certainly an appropriate behavior for a systems programming language
designed in the early seventies. But D should be targeted to a more
general purpose, as C is being used today. Also, D should be more
adaptable to unconventional processors than C is. E.g., it should be
more suitable for parallel processing environments.

>It is pleasantly compact, and very full of nice
>shortcuts (e.g. "string"[i] ). If you dislike C , try other languages:
>Fortran, Pascal, Ada ,Modula 2. Me, well , I like C and Fortran and loathe
>the rest.

D would not be for people who dislike C. It would be for people who
like C but find it lacking by today's standards in certain areas.

>But if a new language is to be designed, and done really well, it
>won't be done by committee. For the perfect example look in comp.lang.fortran
>and read about 88tran, the totally new language with two heads, brought
>to you by X3J3.

We aren't designing D here. We are pointing out those things lacking
in C that we'd like to see done right in a currently hypothetical
successor. Of course if somebody wanted to digest our discussions,
design a language based on them, implement a compiler (perhaps based
on GNU C or C++), call it D, and distribute it freely, I wouldn't
complain.

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

"The limits of my language mean the limits of my world."
-- Ludwig Wittgenstein

Dave Sill

unread,
Mar 1, 1988, 3:03:10 PM3/1/88
to
(Not really a C issue)

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

"There is very much importance in character sets."
-- Me

Doug Gwyn

unread,
Mar 1, 1988, 4:43:11 PM3/1/88
to
In article <12...@brl-adm.ARPA> ds...@NSWC-OAS.arpa (Dave Sill) writes:
>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?

ISO extended the character set several years ago. It has also been
extended (in more than one way) to accommodate Kanji characters.
C source can be in EBCDIC (for example); it seems inappropriate to
require either a specific character code "standard", or an even
larger set of characters than it already uses, given the amount of
trouble with this we've already had.

Karl Heuer

unread,
Mar 1, 1988, 7:50:52 PM3/1/88
to
>In article <1988Feb25....@utzoo.uucp> he...@utzoo.uucp (Henry Spencer) writes:
>>Most machines cannot handle bits with anywhere near the efficiency
>>with which they handle bytes; the appropriate base unit for efficient code
>>*is* the byte.

"Word-addressible cannot handle bytes with anywhere near the efficiency
with which they handle words; the appropriate base unit for efficient code
is the word." Right?

On a word-addressible machine, there is a perceived need to address objects
smaller than one word; hence most C compilers give you access to individual
bytes via "char". (There may be some that define char as a machine word, but
I'm not familiar with any.) Similarly, on byte-addressible machines there is
a (less) perceived need to address objects smaller than one byte.

If sizeof were measured in bits (the original statement in this thread, I
believe), then (a) no functionality would be lost, because you get the number
of char-sized bytes by using sizeof(thing)/sizeof(char); and (b) it becomes
possible to add a datatype "bit" with sizeof(bit)==1. Code that doesn't use
it would still be just as efficient as it used to be. Code that does use it
on a bit-addressible machine would have access to the entire address space.
And code that uses it on a byte- or word-addressible machine may have to use
goofy pointers, just like (char *) on a word-addressible machine. (Presumably
the author of such code is aware of the space-time tradeoffs.)

In article <73...@brl-smoke.ARPA> gw...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>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).)

This is a less radical proposal, which would be consistent with C.

>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).

I see this as a different problem, which is better solved by "long char". For
example, a Japanese system on a bit-addressible machine should be able to use
both features: 1-bit short char, 8-bit char, 16-bit long char.

>>Please explain how avoiding superfluous words and keeping necessary ones
>>short is consistent with changing {/} to begin/end for no particular reason.
>
>A better reason for a change here is the problems cause by "dangling else"
>and accidental ";" after the closing ")" of a while().

A better change would be to leave the punctuation alone, and but make the
braces required even for a null- or single-statement body. In other words,
change the syntax to read "compound-statement" instead of "statement".

>If would also be nice if such statements could return values (so ?: could
>be dispensed with).

Yes, let's make *all* statements return values (more precisely, remove the
distinction between expressions and statements). Then there's no need for the
distinction between ?: vs. if-else, nor () vs. {}, nor the comma operator vs.
semicolon. (The semicolons in the "for" statement are a minor nuisance, but
no worse than non-operator commas. "for ((i=0; j=N); i<N; (++i; --j))" is
parsable.) Statements that have no obvious value (while; elseless if) could
be void expressions.

Karl W. Z. Heuer (ima!haddock!karl or ka...@haddock.isc.com), The Walking Lint

Karl Heuer

unread,
Mar 1, 1988, 7:59:03 PM3/1/88
to
In article <73...@brl-smoke.ARPA> gw...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:

In a similar vein, using "int" (or the "implied int" you get by leaving out
the type) for a function which returns no value should disappear.

Hey Doug, couldn't this be deprecated on the same grounds as old-style
function declarations? A new syntax ("void") has been standardized which does
the job better, and the old syntax makes it harder to diagnose certain bugs.

Dave Sill

unread,
Mar 2, 1988, 10:14:06 AM3/2/88
to
>In article <12...@brl-adm.ARPA> ds...@NSWC-OAS.arpa (Dave Sill) writes:
>>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?
>
>ISO extended the character set several years ago. It has also been
>extended (in more than one way) to accommodate Kanji characters.

Yes, I've read the ISO standards you refer to (ISO 646, ISO 2022, ISO
2375, ISO 6429), they're sitting on my desk right now. ISO 646 is
like ASCII, except that it allows the construction of "composite
graphic characters". This is great, the sequence "=<CR>/", for
example, could be displayed as a "not-equal" symbol. Unfortunately,
ISO 646 doesn't say what these composite characters look like, so it
could be displayed as a ham sandwich, or as an equals sign with the
first character of the line replaced with a /. Real useful.

ISO 2022 covers extensions to ISO 646 using alternate graphical
character sets, escape sequences, and 8-bit codes. But it says
nothing about what a given pattern looks like in a given character
set. It does, however, maintain interchangeability between 7-bit and
8-bit standard and extended environments, which is A Good Thing.

ISO 2375 is a procedure for registering ISO 2022 escape sequences.
This seems like a step in the right direction. Too bad they don't
have such a procedure for the alternate graphical character sets.

ISO 6429 contains control functions for display devices. It's
interesting to note that although this standard has been available
since '83, only one vendor that I'm aware of claims conformance
(Canon, in their laser printers. If there are others you're aware of,
I'd like to know). Not exactly overwhelming acceptance.

The real problem, though, is not so much in the code itself as it is
in the display devices, terminals, keyboards, et cetera, that are used
to enter and display these characters. Even if the ISO standards
defined the code for a right-pointing-arrow, what key or key-
combination would have to be used to enter one? How could it be
displayed?

>C source can be in EBCDIC (for example); it seems inappropriate to
>require either a specific character code "standard",

So you're saying we can't extend the set of graphical characters we
use in languages because someone might not have the characters
available? What about trigraphs, or a similar mechanism?

>or an even
>larger set of characters than it already uses, given the amount of
>trouble with this we've already had.

The trouble is not that we have too many characters available, it's
that we have too few! For example, if we had a left-pointing-arrow
character that could be used for assignment, the whole == versus =
problem would not exist.

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

"The limits of my language mean the limits of my world."
-- Ludwig Wittgenstein

Ned Nowotny

unread,
Mar 2, 1988, 11:40:20 AM3/2/88
to
Followup -To:


In discussing various successor languages, perhaps the following naming
conventions would be in order:

C - The language we all know and love (or loath, as the case may be).

C++ - The well-know C-like language with object-oriented extensions.

D - The natural C-like successor language.

D++ - The natural C++-like successor language.

C+C - C with extensions for numerical analysis.

C[N] - C with extensions for vector architectures and optimization.

(C) - Functional C.

!C - A pseudo-C with a high degree of structuring and strong typing.

&&C++ - ANSI C.

--

Ned Nowotny (n...@ghostwheel.aca.mcc.com.UUCP)

Doug Gwyn

unread,
Mar 2, 1988, 12:52:20 PM3/2/88
to
In article <28...@haddock.ISC.COM> ka...@haddock.ima.isc.com (Karl Heuer) writes:
>If sizeof were measured in bits ...

>In article <73...@brl-smoke.ARPA> gw...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>>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 reason for not insisting on sizeof() being in bits was that it would
add at least three bits to the required size_t for a byte-oriented
implementation, with no particular gain in that case.

>Yes, let's make *all* statements return values ...

I once designed a language like this for a special purpose. It worked, but
you need to figure out what to do about declarations. What values should
they return?

Doug Gwyn

unread,
Mar 2, 1988, 12:54:11 PM3/2/88
to
In article <28...@haddock.ISC.COM> ka...@haddock.ima.isc.com (Karl Heuer) writes:
>Hey Doug, couldn't this be deprecated on the same grounds as old-style
>function declarations?

It's been suggested before, but hey, send it in. Maybe you can think of
more persuasive arguments.

Doug Gwyn

unread,
Mar 2, 1988, 1:04:55 PM3/2/88
to
In article <6...@viper.Lynx.MN.Org> jo...@viper.UUCP (John Stanley) writes:
>... 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.

It's already basically there:

#include <limits.h> /* (we may have to rename this header) */
#define bitsize(obj) (CHAR_BIT*sizeof(obj))

The only thing this doesn't work on is bit-fields, functions, or
incomplete types.

Doug Gwyn

unread,
Mar 2, 1988, 1:14:09 PM3/2/88
to

My point is that it does no good to introduce a language that uses
funny APL-like symbols, when the vast majority of existing and
near-future terminals and printers won't support the symbols. (I
doubt that many even support the full set already registered with
ISO.) What you end up with are a bunch of kludges, like the proposed
ANSI C trigraphs, that everybody ends up having to cope with. By
limiting the language symbols to those commonly available, you make
programs much more readable in practice.

It isn't clear to me that funny APL-like symbols are preferable to
short keywords (for example). Note that even the mathematicians are
starting to use such notations in preference to inventing mystical
symbols, especially in category theory.

Doug Gwyn

unread,
Mar 2, 1988, 1:30:43 PM3/2/88
to
In article <27...@mmintl.UUCP> fra...@mmintl.UUCP (Frank Adams) writes:
>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.

Obviously, you let the compiler take care of allocating suitable sizes.
For it to do this, the programmer needs to specify something about the
intended usage of the variable, such as is done with enumeration types,
Booleans, and subscript ranges in various languages.

Doug Gwyn

unread,
Mar 2, 1988, 1:35:54 PM3/2/88
to
In article <27...@mmintl.UUCP> fra...@mmintl.UUCP (Frank Adams) writes:
>Clearly, assembler statements should have been defined as:
>#asm <statement>
>instead of
>asm("statement");

A properly-designed system programming language should not have such
a feature at all. (It is not guaranteed in C, either.) The interface
between the optimized code produced for the HLL and the in-line
assembly code is quite problematic. Also, the compiler should not be
forced to have an assembler built-in just to handle such stuff; many
compilers directly generate relocatable object code.

If there is some feature that might be worth having asm() for, for
example "rotate" instructions, then consider designing it into the
HLL.

Chris Torek

unread,
Mar 2, 1988, 5:22:57 PM3/2/88
to
-In article <24...@cca.CCA.COM> g-...@cca.CCA.COM (Richard Harter) writes:
-}As a side point, I like the suggestion that someone made that there be
-}a fallthrough statement rather than automatic fallthrough.

In article <2229...@ralf.home> Ralf....@B.GP.CS.CMU.EDU writes:
-So, you would like to have to write
- switch(var)
- {
- case foo: fallthrough;
- case bar: fallthrough;
- case baz: fallthrough;
- case mung: /* code to do something for all four cases */
- }

While this would work, if we assume D has aggregate constructors,
there is a handsomer way:

switch (e) {
case [1, 2, 3, 5, 7, 13, 19, 23]: ...
}
/* syntax above is only for demonstration */
--
In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163
(still on trantor.umd.edu because mimsy is not yet re-news-networked)
Domain: ch...@mimsy.umd.edu Path: ...!uunet!mimsy!chris

Frank Adams

unread,
Mar 2, 1988, 8:26:29 PM3/2/88
to
In article <2...@aiva.ed.ac.uk> ric...@uk.ac.ed.aiva (Richard Tobin) writes:
|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.

I certainly *would* require this.

Matt Landau

unread,
Mar 2, 1988, 8:49:12 PM3/2/88
to
In comp.lang.c (<24...@umd5.umd.edu>), ch...@trantor.umd.edu (Chris Torek) writes:
>While this would work, if we assume D has aggregate constructors,
>there is a handsomer way:
>
> switch (e) {
> case [1, 2, 3, 5, 7, 13, 19, 23]: ...
> }
> /* syntax above is only for demonstration */

And of course we add ranges, giving

switch(e)
{
case [1, 2, 3..7, 13, 19, 23..36]:
.
.
.
default:
.
.
.
}
/* what he said */

Richard A. O'Keefe

unread,
Mar 2, 1988, 9:29:14 PM3/2/88