On Friday, 14 May 2021 at 05:27:27 UTC, Walter Bright wrote:
> It's pretty clear that ImportC is not going to be an exact clone of gcc. I've been looking over the __attribute__ documentation, and there doesn't even seem to be a proper grammar for it.

You are better off posing as Clang than GCC.

You have to choose one or the other as extensions tend to be surrounded by #ifdefs

Clang is also used in a new compiler from Intel, but the more challenging extensions are multiprocessing-extensions. Which will creep in over time (meaning, next decade).

On Friday, 14 May 2021 at 05:27:27 UTC, Walter Bright wrote:
> On 5/13/2021 2:04 PM, Iain Buclaw wrote:
>> Well, either one of, or two things will happen:
>> 
>> 1. People will raise bugs against dmd because `gdc foo.c` will be able to compile more code than dmd (and do preprocessing).
>> 
>> 2. People will raise bugs against gdc because `gdc -finline foo.c bar.d` doesn't inline C functions into bar.
>> 
>> I meant conflicts will happen if I change the current behavior so make it so the D compiler handles C sources too i.e: `d21 bar.d foo.c -o bar.o`.
>
> Understood.
>
> It's pretty clear that ImportC is not going to be an exact clone of gcc. I've been looking over the __attribute__ documentation, and there doesn't even seem to be a proper grammar for it.
>
> https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax
>
> There's some wishy-washy wording:
>

I guess in the D grammar, the closest approximation of an attribute-list is just a comma delimited list of call expressions.

__attribute__( (fun1, fun2(2), fun3("bar"), fun4(5, 6)) )

Failing that, just accept any token, until you see the matching closing parenthesis.  Parsing it can be postponed until the semantic phase, same as asm.

I'm afraid my dubious contributions are a bit off topic for
this thread, but one more won't hurt I guess...

On Friday, 14 May 2021 at 08:26:30 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 14 May 2021 at 06:38:34 UTC, Chris Piker wrote:
>> In fact many of our widely used languages are riddled with
>> inconsistencies (I'm looking at you matlab & idl), but that
>> doesn't stop them because the feature set is so nice.
>
> Right, but Matlab is being displaced by Python (at a slow pace). Of course that is also related to licensing (for students), but I think language-issues is also a factor. Especially when writing larger programs, then Python is a clear winner.

In general that's true, but lately Matlab and IDL are making a
comeback among my peers because hardware projects have money to
pay for licensing (staff are so much more expensive than software
licenses anyway) and matplotlib is slow compared to the alternatives.

>> So for us, improved C interop would be a nice bonus, and a good
>> selling point.
>
> Sure! BUT you also didn't dismiss D as a valid tool for you, am I right?

You're right, but I'm just one person at my work site.  I'm looking
to sell others on D.  I'm already sold :)

I think features get users, quality keeps them, so both matter.

On Friday, 14 May 2021 at 18:56:07 UTC, Chris Piker wrote:
> In general that's true, but lately Matlab and IDL are making a
> comeback among my peers because hardware projects have money to
> pay for licensing (staff are so much more expensive than

Matlab is also better for interactive experimentation because the syntax is a bit more compact, but I am no longer using Matlab/Octave. Python/PyCharm + ipython is quite ok.


> You're right, but I'm just one person at my work site.  I'm looking to sell others on D.

What features would make a language easier to sell to your colleagues?

On 5/13/2021 10:57 PM, Max Haughton wrote:
> The only other that I can say is that keep in mind that the blocker is using C not compiling C. I don't want dmd to be my C compiler - so you only need to understand GNU extensions that are used in header files (and don't appear in inline functions in those headers, but still).

I know, it's just a bonus that it can be used as a standalone C compiler. It's not the point of ImportC. It does, however, make it much easier to test ImportC. And who knows what clever uses people will find for it! I'm always amazed at the things people do with D features.

On Friday, 14 May 2021 at 23:59:27 UTC, Walter Bright wrote:
> On 5/13/2021 10:57 PM, Max Haughton wrote:
>> The only other that I can say is that keep in mind that the blocker is using C not compiling C. I don't want dmd to be my C compiler - so you only need to understand GNU extensions that are used in header files (and don't appear in inline functions in those headers, but still).
>
> I know, it's just a bonus that it can be used as a standalone C compiler. It's not the point of ImportC. It does, however, make it much easier to test ImportC. And who knows what clever uses people will find for it! I'm always amazed at the things people do with D features.

One suggestion I have is to add a test suite for the C compiler so that it is clear how conforming it is to Std C. A bunch of tests can be found at:

https://github.com/vnmakarov/mir/tree/master/c-tests

On 5/14/2021 11:56 AM, Chris Piker wrote:
> I think features get users, quality keeps them, so both matter.

An apt summary.

On 5/14/2021 6:11 PM, Dibyendu Majumdar wrote:
> One suggestion I have is to add a test suite for the C compiler so that it is clear how conforming it is to Std C. A bunch of tests can be found at:
> 
> https://github.com/vnmakarov/mir/tree/master/c-tests

Thank you. Those look good.