> Nah. For example, int*[] is an array of pointers now, while int[]* is a pointer to array. He suggests to reverse them. I personally consider the syntax that is there now somewhat more "intuitive" - even though it's a bit more complicated.

More "intuitive" - means more like C#? ;-P

Yeah, C/C++ programmers have to develop their intuition to recognize complex
declarations.
But anyhow - sometimes I have to use the language manual to decipher some
really nasty construction...
Don't condemn the next generation of the programmers to such hell!

"Serge K" <skarebo@programmer.net> wrote in message news:a3rc7f$2cgv$1@digitaldaemon.com...
> > Nah. For example, int*[] is an array of pointers now, while int[]* is a pointer to array. He suggests to reverse them. I personally consider the syntax that is there now somewhat more "intuitive" - even though it's a bit more complicated.
>
> More "intuitive" - means more like C#? ;-P

More like C/C++.

> Yeah, C/C++ programmers have to develop their intuition to recognize
complex
> declarations.
> But anyhow - sometimes I have to use the language manual to decipher some
> really nasty construction...

Do you have to declare arrays to pointers of arrays so frequently anyhow? =)

> Don't condemn the next generation of the programmers to such hell!

Well I'm still this generation...

Juan Carlos Arevalo Baeza wrote:

>    which inverts the indices in the type specifier. Or inverting everything:
>
> [5][3]int x; // Array of 5 arrays of 3 ints.
> [5]*[3]int x; // x is an array of 5 pointers to arrays of 3 ints

This might actually be a good idea, but I'm going to modify it some.  Make all of the declarations be around the type, but each marker goes on the side where you use it.  Since the * and & operators go on the left, force *'s to be on the left; since array indexes must go on the right, force them to be there.  Things always read right-to-left, and if you want otherwise, use parens:

int x;            // int
*int x;        // ptr to int
**int x;        // ptr to ptr to int
int[] x;        // array of ints
(*int)[] x;        // array of ptrs to int
*int[] x;        // ptr to array of ints

int[3] x;        // array of 3 ints
int[3][5] x;        // 3 arrays of 5 ints
*int[3][5] x;        // ptr to 3 arrays of 5 ints
(*int[3])[5] x;        // array of 5 ptrs to arrays of 3 ints

Function pointers abandon the C syntax for the same paradigm.  If you put the parens on the type instead of the variable, you can avoid C's abiguity between functions and function pointers.  Perhaps, like class variables, you don't have to specify that it is a pointer - thus we have "function references" instead of "function pointers":

int(char) x;    // reference to a function taking char and returning int
int(char)[5] x;    // array of 5 references to functions taking char and returning
int

*int(char) x;    // let's make this a SYNTAX ERROR, since 99% of programmers won't
remember the spec anyway...
(*int)(char) x;    // reference to a function taking char and returning pointer to
int
*(int(char)) x;    // ptr to reference to a function taking char and returning
pointer to int

int[5](char) x;    // reference to a function taking char and returning array of 5
ints
(int[5](char))[3] x;    // array of 3 references to functions taking char and
returning arrays of 5 ints

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C615A5D.92D6B8F@deming-os.org...

> *int x;        // ptr to int
> **int x;        // ptr to ptr to int

Not so bad. Still I'd prefer int*. Just a matter of personal taste, I believe.

> Function pointers abandon the C syntax for the same paradigm.  If you put
the
> parens on the type instead of the variable, you can avoid C's abiguity
between
> functions and function pointers.  Perhaps, like class variables, you don't
have to
> specify that it is a pointer - thus we have "function references" instead
of
> "function pointers":
>
> int(char) x;    // reference to a function taking char and returning int
> int(char)[5] x;    // array of 5 references to functions taking char and
returning

Agreed.

> *int(char) x;    // let's make this a SYNTAX ERROR, since 99% of
programmers won't

What's wrong with it?

Pavel Minayev wrote:

> > *int(char) x;    // let's make this a SYNTAX ERROR, since 99% of
> programmers won't
>
> What's wrong with it?

My thought was that it would be so rarely used that very, very few programmers would know whether the line above is "ptr to a reference to a function returning int" or "reference to a function returning ptr to int".  Thus, every time somebody uses the syntax, everybody will have to go look it up in the spec. IMHO, it would be easier to just say "this is a syntax error, you must use parentheses to clarify".

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Serge K" <skarebo@programmer.net> wrote in message news:a3raqb$2bvt$1@digitaldaemon.com...
> > I'm all for it.  In fact I suggested the very same thing a few weeks
ago.
> > The only major difference from what I can tell between this and the
> current
> > D syntax for typespecs is that D allows the array specification to come after the variable (for minimal C compatibility I suppose).
>
> Ability to put array specification after variable name seems to be quite
> useless "syntactic sugar" (since "declaration declaring multiple
> declarations" cannot declare variables with different type).
> The only practical reason to use such ability is to write something like
> this:

I agree.

> int  a[3], b[2], c; // currently not allowed.
>
> > I believe the examples you give all work in D as it's currently
specified.
>
> No, currently it works in a quite opposite & mixed way.. ;-)
> It's just in my opinion the language specifications should have as less
> "special cases" as possible.

I agree here too... case in point is how I failed to notice it's different
from D syntax.
It's subtle stuff like that which causes program bugs, so the simpler the
typespec/declaration syntax, the better.  Either straight right-to-left
order, or straight left-to-right order, please.

Sean

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a3rrdo$306$1@digitaldaemon.com...
> Not so bad. Still I'd prefer int*. Just a matter of personal taste, I believe.

That's the trouble. I am just *so* used to the C style, it's hard to break away from it.

Walter wrote:

> "Pavel Minayev" <evilone@omen.ru> wrote in message news:a3rrdo$306$1@digitaldaemon.com...
> > Not so bad. Still I'd prefer int*. Just a matter of personal taste, I believe.
>
> That's the trouble. I am just *so* used to the C style, it's hard to break away from it.

I understand.  But, IMHO, this is so much superior...it has automatic internal clarity and better handles most of the odd special cases that C and D struggle with.

In particular, I am saddened by the mixing of right-hand and left-hand rules in the D spec...it's a cludge that will lead to massive coder confusion in the future. :(  I don't mean this as any attack...it's just that I think that D will thrive only as much as it is easy to use.  Mixed array and pointer declarations are not easy to use :(

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C65304F.B889FE3F@deming-os.org...
> In particular, I am saddened by the mixing of right-hand and left-hand
rules
> in the D spec...it's a cludge that will lead to massive coder confusion in
the
> future. :(  I don't mean this as any attack...it's just that I think that
D
> will thrive only as much as it is easy to use.  Mixed array and pointer declarations are not easy to use :(

Yes, it's a kludge, and I have misgivings about it too.

Walter wrote:

> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C65304F.B889FE3F@deming-os.org...
> > In particular, I am saddened by the mixing of right-hand and left-hand
> rules
> > in the D spec...it's a cludge that will lead to massive coder confusion in
> the
> > future. :(  I don't mean this as any attack...it's just that I think that
> D
> > will thrive only as much as it is easy to use.  Mixed array and pointer declarations are not easy to use :(
>
> Yes, it's a kludge, and I have misgivings about it too.

May I second that?  I believe elegant declaration of intricate data types and structures inevitably leads to simpler and more direct (and less error prone) programming.  I recall with horrors the difficulty I've had in C creating just the oddball declaration I needed to make a very elegant algorithm simple to implement and optimally efficient at runtime.  All too often, the declarations became too complex to write in "clean" C, forcing me to resort to cascaded typedefs and macros to make them even exist, much less work.

I feel D should bend over backwards to make even the nastiest, most complex declaration completely unambiguous and, of vastly greater importance, as easy as possible to understand and use.

Such beastly declarations are relatively rare, but when you need them, you typically also need clarity even more.  The price of having to learn a new way to write such rare and complex declarations should be more than offset by the reduced error and hassle in creating and using them!

Convoluted C declarations really feel more like torture than code.  A kluge, just like the C preprocessor, designed to permit a slightly smaller compiler to be built.   Is this something that should be carried "forward" in D?

Want to see an extremely powerful declaration syntax?  Look at APL.  ;^)   For a powerful but simple declaration syntax, look at PL1 or PL/M.


-BobC