Live data from Hacker News

Cdecl – Turns English phrases into C declarations

cdecl.org

51–56 of 56 posts

Re: Cdecl – Turns English phrases into C declarations

#51
post #48

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…

I did something wrong and the asterisk or star, representing C's pointer op, has been dropped from my prior posting. I apologize, also for poor formatting.

Re: Cdecl – Turns English phrases into C declarations

#52
post #48

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…

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

#53
post #52

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

#54
post #52

Earlier 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…

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

Re: Cdecl – Turns English phrases into C declarations

#55
post #54

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

Ok, I got it now. Thanks. My faulty understanding.

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.

Post reply on HN