Earlier quoted context omitted.
However the declaration-mirrors-use idea does not apply to function arguments. If you have "void (* f)(int * arg)", you would not use it like "(* f)(* arg)" unless your arg is actually "int * * ". This could be fixed. Instead of "void (* f)(int * x)" we would write "void (* f)(x &int)". Now it makes sense, the declaration says that we could call the function if we pass the address of some int y, as if by "(* f)(&y)".…
1) The use of the Python feature for arrays I find confusing as it is not orthogonal to the rest of your new and improved syntax for C. Everywhere else, you change C's declaration order of , in your new syntax to place the identifier of the declarator first, followed by any pointer ops, and lastly the type. You are changing the pointer op " " from a prefix that needed to be read right-to-left, after locating the iden…
Cdecl – Turns English phrases into C declarations
51–56 of 56 posts
Re: Cdecl – Turns English phrases into C declarations
#52Earlier quoted context omitted.
However the declaration-mirrors-use idea does not apply to function arguments. If you have "void (* f)(int * arg)", you would not use it like "(* f)(* arg)" unless your arg is actually "int * * ". This could be fixed. Instead of "void (* f)(int * x)" we would write "void (* f)(x &int)". Now it makes sense, the declaration says that we could call the function if we pass the address of some int y, as if by "(* f)(&y)".…
1) The use of the Python feature for arrays I find confusing as it is not orthogonal to the rest of your new and improved syntax for C. Everywhere else, you change C's declaration order of , in your new syntax to place the identifier of the declarator first, followed by any pointer ops, and lastly the type. You are changing the pointer op " " from a prefix that needed to be read right-to-left, after locating the iden…
For functions, I think the -> syntax is the only thing that makes sense. It's just natural, first you need the arguments then you get the return value.
> That would mean you have 2 styles of pointers, one as a prefix and one as a suffix to the declarator identifier. So you now have to read both right-to-left and left-to-right, which seems to cancel out the benefits of only reading declarations in left-to-right order!
I'm not following. There are not two styles of pointers, a pointer is declared like "&type". Functions are declared like "(args) -> ret" which is read left-to-right (function taking such arguments and returning such value). A function pointer is simply a pointer to a function like "&(args) -> ret".
> Q: How do these proposed changes affect the parsing of the new C syntax?
I guess I should have added ? C would never adopt such a radical change. In any case, I don't see how it would be fundamentally more difficult to parse than the current declaration syntax. There would be problems disambiguating the two (what is "foo bar;" if foo and bar are both typedefs?). Maybe changing to require a colon after the name would make that simpler "fun: (arg: int) -> int".
Re: Cdecl – Turns English phrases into C declarations
#53Earlier quoted context omitted.
1) The use of the Python feature for arrays I find confusing as it is not orthogonal to the rest of your new and improved syntax for C. Everywhere else, you change C's declaration order of , in your new syntax to place the identifier of the declarator first, followed by any pointer ops, and lastly the type. You are changing the pointer op " " from a prefix that needed to be read right-to-left, after locating the iden…
For the arrays, I agree "[10] int" is better. For functions, I think the -> syntax is the only thing that makes sense. It's just natural, first you need the arguments then you get the return value. > That would mean you have 2 styles of pointers, one as a prefix and one as a suffix to the declarator identifier. So you now have to read both right-to-left and left-to-right, which seems to cancel out the benefits of onl…
By reading both left-to-right and right-to-left I mean: "star" pointer in front of the identifier read right-to-left with return function type on the left and ampersand pointer read left-to-right with return function type on the right of "->"
Here are 2 of your function examples you gave:
This example has both an outermost "void" function return type on the left and another to the right of "->" "void (* f)(g &(int) -> void)" Instead use the following to always read left-to-right and get rid of the "star" pointer: "f &(g &(int) -> void) -> void"
Your next example has 2 "void" function return types on the left, and one "void" to the right of "->" "void (* f)(g &(void (* h)(x &int)) -> void)" Instead use the following to always read left-to-right: "f &(g &(h &(x &int) -> void) -> void) -> void"
Re: Cdecl – Turns English phrases into C declarations
#54Earlier quoted context omitted.
For the arrays, I agree "[10] int" is better. For functions, I think the -> syntax is the only thing that makes sense. It's just natural, first you need the arguments then you get the return value. > That would mean you have 2 styles of pointers, one as a prefix and one as a suffix to the declarator identifier. So you now have to read both right-to-left and left-to-right, which seems to cancel out the benefits of onl…
By 2 styles of pointers used in functions, see below taken from your examples. By reading both left-to-right and right-to-left I mean: "star" pointer in front of the identifier read right-to-left with return function type on the left and ampersand pointer read left-to-right with return function type on the right of "->" Here are 2 of your function examples you gave: This example has both an outermost "void" function…
Re: Cdecl – Turns English phrases into C declarations
#55Earlier quoted context omitted.
By 2 styles of pointers used in functions, see below taken from your examples. By reading both left-to-right and right-to-left I mean: "star" pointer in front of the identifier read right-to-left with return function type on the left and ampersand pointer read left-to-right with return function type on the right of "->" Here are 2 of your function examples you gave: This example has both an outermost "void" function…
I did say "original C declaration syntax forms needs to be deprecated and only the newly invented syntax forms should be used". So the new invented syntax alone is complete (you can express anything with &, (args)->ret and [count]type).
I believe you have a clean, readable syntax for C declarations.
The Go Programming Language's declaration syntax is very similiar, except that "star" is retained and acts just as your "&"
I don't have a complete list, but have been looking at classifying programming languages into one of 2 categories:
Category 1 declaration syntax: Type identifier ;
or
Category 2 declaration syntax: identifier Type ; with perhaps a colon or other punctuation between the identifier and Type.