On Tue, Jul 16, 2013 at 10:02 PM, deadalnix <deadalnix@gmail.com> wrote:

> On Wednesday, 17 July 2013 at 04:32:12 UTC, Timothee Cour wrote:
>
>> On Tue, Jul 16, 2013 at 9:14 PM, Walter Bright <newshound2@digitalmars.com>**wrote:
>>
>>  On 7/16/2013 8:49 PM, Timothee Cour wrote:
>>>
>>>  So how about a library solution instead, which doesn't require compiler
>>>> change:
>>>>
>>>>
>>> While semantically a great idea, technically I don't think CTFE is up to implementing a C front end yet.
>>>
>>>
>> it would trivially, with CTFE exec.
>> Yet another enabling use case.
>>
>
> Just because a bad solution is faster to implement doesn't make it good.
>

Being lazy is good. Less bugs to fix, etc.

On Wednesday, 17 July 2013 at 05:12:00 UTC, Timothee Cour wrote:
> what's a non-full C front end? If it's not a real C front end it's gonna
> break with certain macros etc. Not good.
>

Macro are processed before parsing? No need for a full C frontend to handle macros.

> I see no point in re-implementing a C front end when we can simply use an
> existing one to do the job (eg clang). This would also allow to parse C++
> just as well.

When you only need a very limited part of the fronted, it make sense. Here we don't need to parse function body for instance, and we can skip most of semantic analysis (if not all ?).

Possibly instead of 'include' would be better use 'include_C' as opposed to C++ or any other language.

On Tue, Jul 16, 2013 at 11:01 PM, deadalnix <deadalnix@gmail.com> wrote:

> On Wednesday, 17 July 2013 at 05:12:00 UTC, Timothee Cour wrote:
>
>> what's a non-full C front end? If it's not a real C front end it's gonna break with certain macros etc. Not good.
>>
>>
> Macro are processed before parsing? No need for a full C frontend to handle macros.
>
>
>  I see no point in re-implementing a C front end when we can simply use an
>> existing one to do the job (eg clang). This would also allow to parse C++
>> just as well.
>>
>
> When you only need a very limited part of the fronted, it make sense. Here we don't need to parse function body for instance, and we can skip most of semantic analysis (if not all ?).
>

you'd still need to parse C files recursively (textual inclusion...), handle different C function calling conventions, different C standards, you'd need a way to forward to dmd different C compiler options (include paths to standard / custom libraries), and eventually people will want to parse C++ as well anyways. That can be a lot of work. Whereas using existing tools takes much less effort and is less error prone.

On Tuesday, 16 July 2013 at 14:15:55 UTC, Jacob Carlborg wrote:
> Made a proof of concept to automatically parse, translate and import C header files in D using DStep. DMD is linked against DStep and does not start new process to make the translation.
>
> I added a new pragma, include, that handles everything. Use like this:
>
> // foo.h
> void foo ();
>
> // main.d
>
> module main;
>
> pragma(include, "foo.h");
>
> void main ()
> {
>     foo();
> }
>
> DMD: https://github.com/jacob-carlborg/dmd/tree/dstep
> DStep: https://github.com/jacob-carlborg/dstep/tree/c_api

This sounds pretty cool, and the suggestion from Timothee also makes a lot of sense.

Is there any way we can rig this to behave as if it were a CTFE invocation?  It could be treated like an intrinsic up to the point where we have powerful-enough CTFE to replace it.  I'm still not sure if Walter would be OK with this, but I figure I'd mention it, since it could give us something really nice without having to wait for CTFE to get good.

On 7/16/2013 10:04 PM, deadalnix wrote:
> On Wednesday, 17 July 2013 at 04:14:56 UTC, Walter Bright wrote:
>> On 7/16/2013 8:49 PM, Timothee Cour wrote:
>>> So how about a library solution instead, which doesn't require compiler change:
>>
>> While semantically a great idea, technically I don't think CTFE is up to
>> implementing a C front end yet.
>
> This is the right path. We don't need the full front end, do we ?

Yeah, you do need the full front end. It's pretty amazing how the simplest of .h files seem determined to exercise every last, dark corner of the language.

If the converter doesn't accept the full language, you're just going to get a dump truck unloading on it.

On 2013-07-17 07:04, deadalnix wrote:

> This is the right path. We don't need the full front end, do we ?

Oh, yes we do. You will always run into corner cases your tool cannot handle until you have a complete front end. I tried that first, before I used libclang.

-- 
/Jacob Carlborg

On 2013-07-17 08:29, angel wrote:
> Possibly instead of 'include' would be better use 'include_C' as opposed
> to C++ or any other language.

Or there could be an optional argument indicating the language.

pragma(include, "foo.h", "C");

-- 
/Jacob Carlborg

On 2013-07-16 17:05, Dicebot wrote:

> While this a relatively common request, I don't think such stuff belongs
> to compiler. It creates extra mandatory dependencies while providing
> little advantage over doing this as part of a build system.

I started to think a bit about this. One might need to specify various options to translate the header file. Options like include paths and similar. That might be quite problematic to do in a pragam, or via DMD command line options.

-- 
/Jacob Carlborg

On 2013-07-17 10:14, Walter Bright wrote:

> Yeah, you do need the full front end. It's pretty amazing how the
> simplest of .h files seem determined to exercise every last, dark corner
> of the language.
>
> If the converter doesn't accept the full language, you're just going to
> get a dump truck unloading on it.

When you do have a complete front end you can choose how to handle the language constructs the tool cannot (yet) translate. I.e. just skip it, insert a comment or similar.

If you don't have a full front end and encounters something that you cannot translate, you will most likely have weird behaviors.

-- 
/Jacob Carlborg