May 15
On Sun, May 15, 2022 at 06:18:58AM +0000, forkit via Digitalmars-d wrote: [...]
> I understand the appeal of making it easier to use C libraries in a otherwise D solution. But that does not progress or advance the nature of software development, and the responsibility programmers have to their clients.
> 
> I was (initially) attracted to D because of how it advanced the
> problem of writing safe code (particulary @safe). This is what would
> make D 'popular'.
> 
> But ImportC is short-sighted in my opinion, and is a step in the opposite direction.
> 
> The focus should instead be on @safe, not C.

Making it easier to use C libraries actually *increases* the motivation to write @safe code.

Because, if I were to start a new project and I need to use a C library, then if it was too hard to interface D with that C library, it'd incentivize me to write the project in C instead. Net result: I write more unsafe code -- because it'd be in C.

OTOH, if it was easy to integrate that C library, I would be motivated to write D code instead.  Net result: I write more @safe code.  Sure it's not 100%, but that's still better than 0%.

There is, of course, the option of rewriting said C library in D. But that's a low-incentive option, because it requires a lot of time/effort, and is a net loss from a business POV (why reinvent functionality that already exists / increases time to market, which reduces competitiveness).  Depending on which library you're talking about, this cost could be very prohibitive.  Concrete example: text layout with something like Cairo.  There is NO WAY I'm gonna be able to reinvent the whole thing myself; that'd take me several lifetimes to pull off. (And believe me, I've tried. Text layout is an extremely convoluted and messy process, with tons of unexpected complexities in this day and age of internationalization and Unicode.  It's not something you can just reinvent in a fortnight; it took YEARS for existing solutions to be produced, and requires expertise you probably do not have (and would not have for years even if you were to start studying it now).  You can't just throw it all out the window because OMG it's not written in D so it's BAD!)

Which would you rather have -- more projects to be written in C because that's the only way you can leverage this existing technology, because it's too hard to use it from D; or more projects to be written in D because you can easily use a C library with minimum friction, so you actually *have* the option of writing it in D in the first place?


T

-- 
Живёшь только однажды.
May 15

On Sunday, 15 May 2022 at 11:25:47 UTC, H. S. Teoh wrote:

He has been talking nonsense .Just ignore him.

May 15

On Sunday, 15 May 2022 at 10:59:41 UTC, Ola Fosheim Grøstad wrote:

>

On Sunday, 15 May 2022 at 10:43:01 UTC, zjh wrote:

Take some time to modify the C source code, and you can link with D. It's well worth the time. Then I can use D all the way.

May 15

On Sunday, 15 May 2022 at 12:33:23 UTC, zjh wrote:

>

95%.

It can be completely implemented that ,original 20 modifications needed, but now only 1/2 modification is needed.
This can be achieved through various matching macros auto convert.Like Atila's dpp convert.

May 15

On Sunday, 15 May 2022 at 12:41:20 UTC, zjh wrote:

>

On Sunday, 15 May 2022 at 12:33:23 UTC, zjh wrote:

>

95%.

It can be completely implemented that ,original 20 modifications needed, but now only 1/2 modification is needed.
This can be achieved through various matching macros auto convert.Like Atila's dpp convert.

I think macro expansion should be done in the lexer, differences between C and D should be resolved in the parser and in the static analysis after parsing. All content of the macro can be assumed to be proper C, but things that are passed in as parameters can refer to D-code and that is where you need to be careful and perhaps introduce new language constructs if it turns out that the analysis is too difficult or even change the semantics of the D language (difficult to say in advance).

I don't think one should encourage to use this feature until it is done, as then you have no way to change the approach and you risk being stuck with something that is inadequate.

I think this is a clear cut case of: be prepared to do it properly or don't do it at all.

May 15

On Sunday, 15 May 2022 at 13:00:26 UTC, Ola Fosheim Grøstad wrote:

>

On Sunday, 15 May 2022 at 12:41:20 UTC, zjh wrote:

>

I think macro expansion should be done in the lexer, differences between C and D should be resolved in the parser and in the static analysis after parsing.

Macros match can be done just with mixin.
And most macros have patterns. They are very similar to string mixin.
Of course, I don't know if they can handle monster macros like boost? Maybe ,it deserve the try .After all, they are also macros.
If you can't make sure, just report it. then manual modify.
If you can do it, just do it accurately .
This is entirely feasible.

Just treat the macro as another small language.
Similar to ImportC, take another different branch.

May 15

On Sunday, 15 May 2022 at 13:12:29 UTC, zjh wrote:

>

Macros match can be done just with mixin.

Not really, because they contain fragments of C-code. So if you inject them straight into D-code it may look like gibberish to the D compiler. You also cannot parse a C fragment without knowing the context.

So what you need to do is to use a parser that allows mixing D and C code under the assumption that the C-tokens are tagged as C and the D-tokens are tagged as D.

This is probably possible (maybe requires some adjustments) since D already is very close to C in its structure.

E.g. assume a C-macro called FUNCTION:

$FUNCTION(void,functionname){…}

After lexing the lexer annotate the tokens in the expanded FUNCTION macro as coming from a C-macro, and it will try at different branch in the parser that is oriented towards C and not D. From this it will build a D-compatible function signature before adding the body of the function (which is regular D code).

May 15

On Sunday, 15 May 2022 at 13:41:31 UTC, Ola Fosheim Grøstad wrote:

>

Not really, because they contain fragments of C-code. So if you inject them straight into D-code it may look like gibberish to the D compiler.

>

So what you need to do is to use a parser that allows mixing D and C code under the assumption that the C-tokens are tagged as C and the D-tokens are tagged as D.

This is probably possible (maybe requires some adjustments) since D already is very close to C in its structure.

You are right,
This should be feasible.

May 15
On 5/15/2022 4:55 AM, H. S. Teoh wrote:
> There is, of course, the option of rewriting said C library in D.
In my experience, it is not an option to rewrite working C code into D.

Note that I have successfully converted small and medium C code projects to D. I've done other translations of programs from one language to another.

1. if you don't have a test suite for the program, a successful conversion becomes an order of magnitude harder

2. converting a program all at once does not work. It must be done incrementally, one function at a time

3. even so, when faced with a large, complex project, there's just no business case for doing a conversion

Even just converting the .h files to D can be a major, rather unpleasant undertaking. We've put a lot of time into converting the various system .h files into D for druntime. There's always a risk of a mistake, and we've made them and the result is bizarre crashes because of ABI mismatches. Hand-checking them is error-prone, tedious and very boring work.

ImportC makes things so much easier. You can write new D code and hook it up with your existing C code base. You can get reliable, easy, and accurate access to .h files. D will happily work with a project that's a patchwork of C and D code.

I.e. it dramatically lowers the barrier to adopting D.

As for languages other than C, they routinely have a C interface. ImportC makes it easy to hook up with them via the C interface they provide.
May 15
On 5/15/2022 4:25 AM, H. S. Teoh wrote:
> TL;DR: if ImportC had been done 10 years ago, I'd have had MORE
> motivation to write more D code, not less.  And if interfacing D with C
> had been harder than it was, I'd have been motivated to write my project
> in C rather than D (or just decided not to start the project in the
> first place).

I made a big mistake not doing ImportC 15 years ago!