December 18, 2008 Re: Things that may be removed | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | > Ary Borenszweig: >> Why, of course, the C syntax for types: >> int (*x[5])[3]; >> int (*x)(char); >> int (*[] x)(char); >> *Ugh*... bearophile wrote: > Try porting code that uses heavily n-dimensional tensors from C to D, and you understand why supporting the C syntax for arrays (with inverted coordinates in the definition) is a godsend :-) Maybe we could enable them conditionally? pragma(parser, enable_cstyle_func_and_array_decls); { int (*x[5])[3]; } |
December 18, 2008 Re: Things that may be removed | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | bearophile wrote: > Ary Borenszweig: >> Why, of course, the C syntax for types: >> int (*x[5])[3]; >> int (*x)(char); >> int (*[] x)(char); >> *Ugh*... > > Try porting code that uses heavily n-dimensional tensors from C to D, and you understand why supporting the C syntax for arrays (with inverted coordinates in the definition) is a godsend :-) That's a good point. But can't you do: extern(C) { ... } for that? Well, some signatures might leek in the interface, but if they are hard to understand (I could learn them, but if there's a simpler notation, what for?) than it'll be harder to use for D users, and they'll feel they are programming in a mix of C and D, not in D. > > Bye, > bearophile |
December 19, 2008 Re: Things that may be removed | ||||
---|---|---|---|---|
| ||||
Posted in reply to Christian Kamm | On Wed, 17 Dec 2008 23:04:43 -0800, Christian Kamm <kamm-incasoftware@removethis.de> wrote: >> Ary Borenszweig: >>> Why, of course, the C syntax for types: >>> int (*x[5])[3]; >>> int (*x)(char); >>> int (*[] x)(char); >>> *Ugh*... > > bearophile wrote: >> Try porting code that uses heavily n-dimensional tensors from C to D, and >> you understand why supporting the C syntax for arrays (with inverted >> coordinates in the definition) is a godsend :-) > > Maybe we could enable them conditionally? > > pragma(parser, enable_cstyle_func_and_array_decls); > { > int (*x[5])[3]; > } > They are conditional: you choose to write them or not <g> |
December 19, 2008 Re: Things that may be removed | ||||
---|---|---|---|---|
| ||||
Posted in reply to cemiller | Reply to cemiller,
> On Wed, 17 Dec 2008 23:04:43 -0800, Christian Kamm
>
>> pragma(parser, enable_cstyle_func_and_array_decls);
>> {
>> int (*x[5])[3];
>> }
> They are conditional: you choose to write them or not <g>
>
I want DMD (and grep) to help me chose to not let my minions make me READ them
|
December 21, 2008 Re: Things that may be removed | ||||
---|---|---|---|---|
| ||||
Posted in reply to Christian Kamm | "Christian Kamm" <kamm-incasoftware@removethis.de> wrote in message news:gicsm9$2qiv$1@digitalmars.com... <snip> > Maybe we could enable them conditionally? > > pragma(parser, enable_cstyle_func_and_array_decls); > { > int (*x[5])[3]; > } What would this do? Enable C-style declarations for the whole source file? From this point forward? Within the active scope? If it's meant to apply to the content of the given {}, then there should be a semicolon there. Either way, it wouldn't work. The whole point of pragmas is for features that a given compiler may or may not support. And if a given compiler doesn't support this syntax, it will fail regardless. Stewart. -- My e-mail address is valid but not my primary mailbox. Please keep replies on the 'group where everybody may benefit. |
December 21, 2008 Re: Things that may be removed | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | "bearophile" <bearophileHUGS@lycos.com> wrote in message news:gici0r$2d56$1@digitalmars.com... > Ary Borenszweig: >> Why, of course, the C syntax for types: >> int (*x[5])[3]; >> int (*x)(char); >> int (*[] x)(char); >> *Ugh*... > > Try porting code that uses heavily n-dimensional tensors from C to > D, and you understand why supporting the C syntax for arrays (with > inverted coordinates in the definition) is a godsend :-) That sounds like a case of wanting to use D for legacy apps. I'm not sure that we really need C syntax for that, especially considering that legacy apps are one thing in the "Who D is Not For" list. This syntax ought to be at least deprecated soon, and eventually removed. Somebody recently exposed an ambiguity in D's syntax due to this legacy: is Identifier ( * Identifier ) ( Identifier ) ; a declaration of a function pointer or a call to a function returned by a function? Stewart. -- My e-mail address is valid but not my primary mailbox. Please keep replies on the 'group where everybody may benefit. |
December 21, 2008 Re: Things that may be removed | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | Christian Kamm: >> Maybe we could enable them conditionally? >> >> pragma(parser, enable_cstyle_func_and_array_decls); >> { >> int (*x[5])[3]; >> } Stewart Gordon wrote: > What would this do? Enable C-style declarations for the whole source > file? > From this point forward? Within the active scope? If it's meant to apply > to the content of the given {}, then there should be a semicolon there. I assume you mean 'should not be'. That's true, but I didn't want to alter the grammar of the pragma statement to allow for it. Since there's no dedicated mechanism for compiler control, there aren't many options. I guess a version(CStyle_decls) with the side effect of enabling the parsing of C style declarations inside its block could work too. But it's not pretty either. > Either way, it wouldn't work. The whole point of pragmas is for features that a given compiler may or may not support. And if a given compiler doesn't support this syntax, it will fail regardless. Well, there are a few predefined pragmas, like msg and lib. This could also be a required, predefined one. But don't get hung up on the syntax. My main point was that most D modules will not use the C style declarations. They may be useful when porting legacy code though, so being able to enable them on a per file or per block basis seemed like a reasonable compromise if getting rid of them completely is not an option. |
December 21, 2008 Re: Things that may be removed | ||||
---|---|---|---|---|
| ||||
Posted in reply to Christian Kamm | Christian Kamm wrote: > Christian Kamm: >>> Maybe we could enable them conditionally? >>> >>> pragma(parser, enable_cstyle_func_and_array_decls); >>> { >>> int (*x[5])[3]; >>> } > > Stewart Gordon wrote: >> What would this do? Enable C-style declarations for the whole source >> file? >> From this point forward? Within the active scope? If it's meant to apply >> to the content of the given {}, then there should be a semicolon there. > > I assume you mean 'should not be'. That's true, but I didn't want to alter > the grammar of the pragma statement to allow for it. How do you mean, alter the grammar? Pragmas allow ----- pragma(ident) // influence block of declarations { declaration; declaration; } ----- with this type of semantic (see http://www.digitalmars.com/d/1.0/pragma.html). > Since there's no dedicated mechanism for compiler control, there aren't many > options. I guess a version(CStyle_decls) with the side effect of enabling > the parsing of C style declarations inside its block could work too. But > it's not pretty either. That's an ugly hack. Don't use a version to do a pragma's job. Anyway, my vote is for eliminating C-style declarations altogether. |
December 21, 2008 Re: Things that may be removed | ||||
---|---|---|---|---|
| ||||
Posted in reply to Frits van Bommel | Frits van Bommel wrote:
> How do you mean, alter the grammar? Pragmas allow
> -----
> pragma(ident) // influence block of declarations
> { declaration;
> declaration;
> }
> -----
> with this type of semantic (see
> http://www.digitalmars.com/d/1.0/pragma.html).
Ah, I didn't realize that was legal. Thanks for pointing it out!
|
December 21, 2008 Re: Things that may be removed | ||||
---|---|---|---|---|
| ||||
Posted in reply to Christian Kamm | "Christian Kamm" <kamm-incasoftware@removethis.de> wrote in message news:gilm7t$1h2j$1@digitalmars.com... > Frits van Bommel wrote: >> How do you mean, alter the grammar? Pragmas allow <snip> > Ah, I didn't realize that was legal. Thanks for pointing it out! Furthermore, you'd have to alter the grammar anyway in order to support this feature, by adding PragmaStatement: pragma ( parser , enable_cstyle_func_and_array_decls ) NoScopeStatementThatMayContainCStyleDecls among other things. Stewart. -- My e-mail address is valid but not my primary mailbox. Please keep replies on the 'group where everybody may benefit. |
Copyright © 1999-2021 by the D Language Foundation