View mode: basic / threaded / horizontal-split · Log in · Help
December 18, 2008
Re: Things that may be removed
> 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
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
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
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
"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
"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
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
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
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
"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.
1 2 3 4 5
Top | Discussion index | About this forum | D home