[comp.lang.c] Verbose declarations proposal

gwyn@brl-smoke.ARPA (Doug Gwyn ) (12/20/87)

In article <1449@houdi.UUCP> marty1@houdi.UUCP (M.BRILLIANT) writes:
>I propose that the C language be extended to ...

Forget it.  There might have been some point in such a proposal a few
years ago, early in the standardization process, but it is far too late
for such a dramatic change in the language at this stage.

chris@mimsy.UUCP (Chris Torek) (12/20/87)

In article <1449@houdi.UUCP> marty1@houdi.UUCP (M.BRILLIANT) writes:
>... using the basic type declarators like int, char, etc., combined
>with a few simple phrases: "pointer to", "function returning",
>"array of", and maybe a few others.  Any complicated type declaration,
>if means anything at all, can be explained to a neophyte in these terms.

I will let this assertion pass.  Anyway ...

>	type (array[] of pointer to array[][5] of pointer to
>		function(double) returning array[3][5][7] of int) bar;
>would be synonymous with a concise type declaration that I couldn't
>write to save my life.

	% cdecl
	declare bar as array of pointer to array of array 5 of pointer
	to function(arg) returning array 3 of array 5 of array 7 of int
[the last two are a single line, broken here for clarity]
	Warning: Unsupported in C -- Function returning array
	int (*(*bar[])[][5])(arg)[3][5][7]

As you can see, this is not a legal declaration.  Also, it needs
sizes for the arrays if it is to be a type (change `int ...' to
`typedef int ...' to make bar a typedef for this type).

cdecl has been posted to the net many times; there are probably
24 copies on your machine already, each in some user's private
directory.  Why not find one and install it?
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

marty1@houdi.UUCP (M.BRILLIANT) (12/22/87)

My mailer (vn) doesn't say who this is from:
> 
> In article <1449@houdi.UUCP> marty1@houdi.UUCP (M.BRILLIANT) writes:
>>I propose that the C language be extended to ...
> 
> Forget it.  There might have been some point in such a proposal a few
> years ago, early in the standardization process, but it is far too late
> for such a dramatic change in the language at this stage.

Maybe it should remain anonymous.  What it says is that C is too old
to change.  That is, it's a dead language and will be replaced rather
than adapted.  Funny thing, they said that about FORTRAN.

M. B. Brilliant					Marty
AT&T-BL HO 3D-520	(201)-949-1858
Holmdel, NJ 07733	ihnp4!houdi!marty1

marty1@houdi.UUCP (M.BRILLIANT) (12/22/87)

Chris Torek writes:
> Summary: You want cdecl
> ...
> cdecl has been posted to the net many times; there are probably
> 24 copies on your machine already, each in some user's private
> directory.  Why not find one and install it?

Security being what it is, I have no good way of knowing who has it
in private directories.  If so many users like it, why isn't it a
standard tool, like lint?

M. B. Brilliant					Marty
AT&T-BL HO 3D-520	(201)-949-1858
Holmdel, NJ 07733	ihnp4!houdi!marty1

marty1@houdi.UUCP (M.BRILLIANT) (12/22/87)

In article <9898@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> In article <1449@houdi.UUCP> marty1@houdi.UUCP (M.BRILLIANT) writes:
> >... using the basic type declarators like int, char, etc., combined
> >with a few simple phrases: "pointer to", "function returning",
> >"array of", and maybe a few others.  Any complicated type declaration,
> >if means anything at all, can be explained to a neophyte in these terms.
> 
> I will let this assertion pass.  Anyway ...
> ...
> cdecl has been posted to the net many times; there are probably
> 24 copies on your machine already, each in some user's private
> directory.  Why not find one and install it?

Security being what it is, I can't look around for private copies. 
However, we have a Labs-wide set of experimental tools, and a version
of cdecl is in it.  But it just prints out "this tool - cdecl - not
installed yet."  So I doubt that there are 24 copies.

But my assertion about simple phrases stands fast.  According to the
online manual entry for cdecl, its verbose language uses just the three
phrases I suggested.

If Chris thinks cdecl is such a useful tool that any UNIX(tm) system
probably has 24 copies, why isn't it a standard tool, like lint?
Answer: it will be.  Next question: why not incorporate it in the
compiler?

M. B. Brilliant					Marty
AT&T-BL HO 3D-520	(201)-949-1858
Holmdel, NJ 07733	ihnp4!houdi!marty1

OWENSJ%VTVM1.BITNET@CUNYVM.CUNY.EDU (John Owens) (12/23/87)

>> Forget it.  There might have been some point in such a proposal a few
>> years ago, early in the standardization process, but it is far too late
>> for such a dramatic change in the language at this stage.
>
>Maybe it should remain anonymous.  What it says is that C is too old
>to change.  That is, it's a dead language and will be replaced rather
>than adapted.  Funny thing, they said that about FORTRAN.

It was from Doug Gwyn, if I remember correctly, and it doesn't say that
about C at all.  It's a comment about the standardization process that's
been going on for the past few years, which is attempting to ensure C's
viability into the future, and is making changes to the C language.  What
Doug meant was just that the committee is in the last stages of review and
approval of the standard, and it's much too late to introduce brand new ideas.
Maybe in the next standard. :-)

        -John Owens                     +1 703 961 7827
        Virginia Tech   Communications Network Services
        OWENSJ@VTVM1.CC.VT.EDU      OWENSJ@VTVM1.BITNET

peter@sugar.UUCP (Peter da Silva) (12/23/87)

There's method to the madness:

In article <1449@houdi.UUCP>, marty1@houdi.UUCP (M.BRILLIANT) writes:
> I propose that the C language be extended to allow verbose type
> declarations in these words, in addition to the present conventions for
> concise type declarations.
> ...
> and the verbose declaration:
> 	type (array[] of pointer to array[][5] of pointer to
> 		function(double) returning array[3][5][7] of int) bar;
> would be synonymous with a concise type declaration that I couldn't
> write to save my life.

I'd hate to figure out how to use something like this myself. In practice
you'de never be able to use it... if you can't write the declaration,
you can't use it. If you can't understand the declaration, you can't
use it. And if the declaration is organised differently than the use,
you're not likely to connect one to another.

Or do you want to define a verbose usage language.

Personally, I think anyone who'd use something like the above expression
should be shot. No matter how they declared it.

You can always write a preprocessor that turns C-BOL into C. Shouldn't
even be too hard. A couple of days work with Yacc.
-- 
-- Peter da Silva  `-_-'  ...!hoptoad!academ!uhnix1!sugar!peter
-- Disclaimer: These U aren't mere opinions... these are *values*.

gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/06/88)

In article <1454@houdi.UUCP> marty1@houdi.UUCP (M.BRILLIANT) writes:
>My mailer (vn) doesn't say who this is from:

Me (Gwyn@BRL.MIL).

>> In article <1449@houdi.UUCP> marty1@houdi.UUCP (M.BRILLIANT) writes:
>>>I propose that the C language be extended to ...
>> Forget it.  There might have been some point in such a proposal a few
>> years ago, early in the standardization process, but it is far too late
>> for such a dramatic change in the language at this stage.
>Maybe it should remain anonymous.  What it says is that C is too old
>to change.  That is, it's a dead language and will be replaced rather
>than adapted.  Funny thing, they said that about FORTRAN.

I guess we're interpreting "the C language" in two different ways.
My interpretation was "the forthcoming C language standard".  Yours
may be "local experimental implementation".  There is nothing wrong
with experimenting with extensions to C, which might or might not
later be adopted in a revised C language standard (say, in the year
1998).  However, portable applications need to avoid relying on
such unofficial language features.

For example, I believe several vendors are contemplating adding a
"complex" data type to their C implementations, although for ANSI C
conformance that extension has to be disabled (it infringes on the
name space guaranteed to applications).

It is quite possible that instead of C-98 we might have a C++
standard by that time.