On Tuesday, 8 May 2012 at 13:57:30 UTC, bearophile wrote:
> foobar:
>
>> As others said, the only thing that sort-of makes sense is to copy/paste *declarations* and even those are different enough in D that they deserve at least a look over to make sure they are correct.
>>
>> We shouldn't promote this "goal" at all especially given that it isn't even guarantied to be 100% correct in all cases.
>> Really what we should be promoting is the fact that D is _link_ compatible with C and allows you to use existing C code _without_ porting it to D.
>
> For various reasons I have translated many times routines,
> functions and other small and medium amounts of C code to D. And
> in many cases I have used the C std lib functions to circumvent
> bugs or limitations or performance problems of Phobos. In both
> cases I have found the C functions quite useful, so moving them
> into not built-in stuff is bad for me. The risk of using C
> functions by mistake is low enough.
>
> Bye,
> bearophile

That does not contradict what I said. No one stops you from _translating_ C/C++ code (or any other language for that matter) to D. You shouldn't however rely on _copy/pasting_ C code and expect it to magically just work with 100% certainty.
I also did not say that using C headers should be forbidden, merely that it should obey the code organization - the current scheme which was defined by Walter is to put such headers in Deimos.
I wouldn't mind if Deimos would come bundled with the D tool-chain or be easily accessible via a package manager, Just that code should be kept organized according to our own defined scheme. Besides, what if I find it useful to use e.g. FORTRAN code, should the relevant functions also be in the stdlib?

On Tuesday, 8 May 2012 at 14:48:27 UTC, foobar wrote:
> [...], what if I find it useful to use e.g. FORTRAN code, should the relevant functions also be in the stdlib?

No, FORTRAN has absolutely nothing to do with D.  C, on the other hand, does.  Both druntime and Phobos depend heavily on the C stdlib.  The GC uses malloc/free, std.stdio.File is a wrapper around FILE*, etc.

-Lars

On Tuesday, 8 May 2012 at 14:59:43 UTC, Lars T. Kyllingstad wrote:
> On Tuesday, 8 May 2012 at 14:48:27 UTC, foobar wrote:
>> [...], what if I find it useful to use e.g. FORTRAN code, should the relevant functions also be in the stdlib?
>
> No, FORTRAN has absolutely nothing to do with D.  C, on the other hand, does.  Both druntime and Phobos depend heavily on the C stdlib.  The GC uses malloc/free, std.stdio.File is a wrapper around FILE*, etc.
>
> -Lars

Irrelevant. For all I care druntime could be implemented in Klingon. That doesn't mean its API needs to include Klingon as well. That's called "encapsulation".

On Tuesday, 8 May 2012 at 16:35:05 UTC, foobar wrote:
> On Tuesday, 8 May 2012 at 14:59:43 UTC, Lars T. Kyllingstad wrote:
>> On Tuesday, 8 May 2012 at 14:48:27 UTC, foobar wrote:
>>> [...], what if I find it useful to use e.g. FORTRAN code, should the relevant functions also be in the stdlib?
>>
>> No, FORTRAN has absolutely nothing to do with D.  C, on the other hand, does.  Both druntime and Phobos depend heavily on the C stdlib.  The GC uses malloc/free, std.stdio.File is a wrapper around FILE*, etc.
>>
>> -Lars
>
> Irrelevant. For all I care druntime could be implemented in Klingon. That doesn't mean its API needs to include Klingon as well. That's called "encapsulation".

Um... so you don't mind the C/POSIX declarations being there, you just want them to be private so you aren't tempted to use them in your own code?

-Lars

On Tuesday, 8 May 2012 at 17:03:10 UTC, Lars T. Kyllingstad wrote:
> On Tuesday, 8 May 2012 at 16:35:05 UTC, foobar wrote:
>> On Tuesday, 8 May 2012 at 14:59:43 UTC, Lars T. Kyllingstad wrote:
>>> On Tuesday, 8 May 2012 at 14:48:27 UTC, foobar wrote:
>>>> [...], what if I find it useful to use e.g. FORTRAN code, should the relevant functions also be in the stdlib?
>>>
>>> No, FORTRAN has absolutely nothing to do with D.  C, on the other hand, does.  Both druntime and Phobos depend heavily on the C stdlib.  The GC uses malloc/free, std.stdio.File is a wrapper around FILE*, etc.
>>>
>>> -Lars
>>
>> Irrelevant. For all I care druntime could be implemented in Klingon. That doesn't mean its API needs to include Klingon as well. That's called "encapsulation".
>
> Um... so you don't mind the C/POSIX declarations being there, you just want them to be private so you aren't tempted to use them in your own code?
>
> -Lars

Yes, pretty much.
They are an implementation detail of druntime/phobos.

Other vendors may choose to implement the tool-chain with another language in mind and as long as the API remains the same I shouldn't need to care e.g. how the GC allocation is implemented (Perhaps it's done with FORTRAN's memory allocation routines).

If I ,the user, want to interface with C I need to use the "official" C headers in Deimos. This is after all the official location for that.

On Tuesday, 8 May 2012 at 17:24:24 UTC, foobar wrote:
> On Tuesday, 8 May 2012 at 17:03:10 UTC, Lars T. Kyllingstad wrote:
>> On Tuesday, 8 May 2012 at 16:35:05 UTC, foobar wrote:
>>> On Tuesday, 8 May 2012 at 14:59:43 UTC, Lars T. Kyllingstad wrote:
>>>> On Tuesday, 8 May 2012 at 14:48:27 UTC, foobar wrote:
>>>>> [...], what if I find it useful to use e.g. FORTRAN code, should the relevant functions also be in the stdlib?
>>>>
>>>> No, FORTRAN has absolutely nothing to do with D.  C, on the other hand, does.  Both druntime and Phobos depend heavily on the C stdlib.  The GC uses malloc/free, std.stdio.File is a wrapper around FILE*, etc.
>>>>
>>>> -Lars
>>>
>>> Irrelevant. For all I care druntime could be implemented in Klingon. That doesn't mean its API needs to include Klingon as well. That's called "encapsulation".
>>
>> Um... so you don't mind the C/POSIX declarations being there, you just want them to be private so you aren't tempted to use them in your own code?
>>
>> -Lars
>
> Yes, pretty much.
> They are an implementation detail of druntime/phobos.
>
> Other vendors may choose to implement the tool-chain with another language in mind and as long as the API remains the same I shouldn't need to care e.g. how the GC allocation is implemented (Perhaps it's done with FORTRAN's memory allocation routines).
>
> If I ,the user, want to interface with C I need to use the "official" C headers in Deimos. This is after all the official location for that.

BTW, it makes sense even if druntime is implemented with C/POSIX - it decouples the user-facing headers from those used by the runtime. the runtime could depend on an older stable version than the one exposed to the users.

I assume druntime/phobos uses some windows APIs in their implementations. Now consider the new winRT API for windows. It should be a matter of updating the headers in a separate repository so that it would be exposed to end-users without waiting on a druntime update to utilize those APIs.

Le 08/05/2012 13:59, foobar a écrit :
> On Sunday, 6 May 2012 at 22:06:32 UTC, Jonathan M Davis wrote:
>>> This argument comes up every once in a while even though AFAIK it
>>> is *not* a goal of D and never has been!
>>> D does not and *should not* strive to be source compatible with
>>> C. We already have C++ for that and it is a horrible idea.
>>> D can link with C which allows to use pre-existing C code. we
>>> should *not* encourage converting C code to D code at all. Either
>>> just link the C code or use D idiomatic code.
>>
>> Then you misunderstand. One of the tenets that D holds to is that any
>> C/C++
>> code either compiles as valid D code with identical semantics, or it
>> doesn't
>> compile as D code (there are a few minor exceptions - such as static
>> arrays
>> being passed by value - but not many). This means that we can break
>> compatibility with C/C++ and do our own thing for a lot of stuff but
>> that we
>> can't just redefine what stuff does such that it would silently break
>> code when
>> it's ported from C/C++ to D.
>>
>> That approach is _very_ different from C++'s approach where valid C
>> code pretty
>> much _always_ compiles identically in C++ (the fact that C++ added
>> keywords
>> being the only exception that I can think of at the moment), but that
>> doesn't
>> mean that we don't care about code portability from C/C++ to D.
>> There's a huge
>> difference between designing a language such that porting code to it from
>> another language isn't error-prone and making the new language source
>> compatibile. D does the former. C++ does the latter.
>>
>> Being able to port code from C/C++ to D without having to worry about
>> silent
>> breakage _is_ one of D's goals.
>>
>> - Jonathan M Davis
>
> I have a three main problems with the above:
>
> a. C++ is *not* fully source compatible with C, especially the latest
> C99 conflicts with C++ IIRC.
> b. D isn't either - there are already semantics changes compared to C,
> as you said so yourself, e.g. static arrays, default initialization of
> static floats, etc.
> c. If this is currently a goal of D it really shouldn't be - it prevents
> us from fixing design bugs we inherited from C such as implicit numeric
> coercions.
>
> As others said, the only thing that sort-of makes sense is to copy/paste
> *declarations* and even those are different enough in D that they
> deserve at least a look over to make sure they are correct.
>
> We shouldn't promote this "goal" at all especially given that it isn't
> even guarantied to be 100% correct in all cases.
> Really what we should be promoting is the fact that D is _link_
> compatible with C and allows you to use existing C code _without_
> porting it to D.

I think that goal is misunderstood. It is aimed at human being, not compiler.

If one read D code that look like C, it should be able to understand it easily. I is not supped to compile with 100% exact semantic.

On Tuesday, 8 May 2012 at 19:00:01 UTC, deadalnix wrote:
>
> I think that goal is misunderstood. It is aimed at human being, not compiler.
>
> If one read D code that look like C, it should be able to understand it easily. I is not supped to compile with 100% exact semantic.

Unfortunately that is not the case.
The stated argument is that compiling C code with a D compiler should either compile exactly the same or produce a compilation error.

As discussed, this is _already_ incorrect for some cases, is completely unnecessary since you can link with pre-compiled C code (via a C compiler) _without_ any overhead and this forces us to carry legacy C design flaws.

If you talking about ease of understanding "C-like" D, that's already a given because D belongs to the C-family of languages. For that matter, JavaScript also belongs to the same family and is easily understood (if you write C-like code). yet no one expects to be able to copy/paste C code into a JS script and have it working as/is.

On May 8, 2012, at 9:35 AM, foobar wrote:

> On Tuesday, 8 May 2012 at 14:59:43 UTC, Lars T. Kyllingstad wrote:
>> On Tuesday, 8 May 2012 at 14:48:27 UTC, foobar wrote:
>>> [...], what if I find it useful to use e.g. FORTRAN code, should the relevant functions also be in the stdlib?
>> 
>> No, FORTRAN has absolutely nothing to do with D.  C, on the other hand, does.  Both druntime and Phobos depend heavily on the C stdlib.  The GC uses malloc/free, std.stdio.File is a wrapper around FILE*, etc.
> 
> Irrelevant. For all I care druntime could be implemented in Klingon. That doesn't mean its API needs to include Klingon as well. That's called "encapsulation".

This is difficult to do with the module system.  You'd have to hand-craft .di files with the stdc headers left out to avoid bundling them in the distro.  They could go into core.internal I suppose though.

On May 8, 2012, at 10:24 AM, foobar wrote:

> On Tuesday, 8 May 2012 at 17:03:10 UTC, Lars T. Kyllingstad wrote:
>> On Tuesday, 8 May 2012 at 16:35:05 UTC, foobar wrote:
>>> On Tuesday, 8 May 2012 at 14:59:43 UTC, Lars T. Kyllingstad wrote:
>>>> On Tuesday, 8 May 2012 at 14:48:27 UTC, foobar wrote:
>>>>> [...], what if I find it useful to use e.g. FORTRAN code, should the relevant functions also be in the stdlib?
>>>> 
>>>> No, FORTRAN has absolutely nothing to do with D.  C, on the other hand, does.  Both druntime and Phobos depend heavily on the C stdlib.  The GC uses malloc/free, std.stdio.File is a wrapper around FILE*, etc.
>>>> 
>>>> -Lars
>>> 
>>> Irrelevant. For all I care druntime could be implemented in Klingon. That doesn't mean its API needs to include Klingon as well. That's called "encapsulation".
>> 
>> Um... so you don't mind the C/POSIX declarations being there, you just want them to be private so you aren't tempted to use them in your own code?
> 
> Yes, pretty much.
> They are an implementation detail of druntime/phobos.
> 
> Other vendors may choose to implement the tool-chain with another language in mind and as long as the API remains the same I shouldn't need to care e.g. how the GC allocation is implemented (Perhaps it's done with FORTRAN's memory allocation routines).
> 
> If I ,the user, want to interface with C I need to use the "official" C headers in Deimos. This is after all the official location for that.

I think this is two separate issues.  The GC implementation is very much hidden already.  The only point of exposure for standard C headers is in core.*, and frankly, I think the only ones actually used are core.sys.windows and core.sys.posix (posix admittedly being a superset of standard C, as stated before).