On Tuesday, 8 May 2012 at 21:17:21 UTC, Sean Kelly wrote:
> 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.

Having an internal package is a good idea. Don did the same for the Math code. More over, the general issue with the module system should be fixed. There was a recent discussion about Andrei's DIP, precisely about addressing this problem.

On Tuesday, May 08, 2012 14:17:14 Sean Kelly wrote:
> 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.

We've previously discussed having _all_ of the C system call functions from the various OSes that we support being in druntime, and I very much think that that's the right way to go. Phobos and druntime then have whatever they need as for as standard C and system call functions go, and anyone who needs any which aren't wrapped by Phobos in some manner has them available to them. Anyone that doesn't want to use any of those C function directly, doesn't have to, but I don't see any reason to hide them just because someone doesn't want to use them in their code.

If the problem is that certain C functions end up getting used a lot when they should have D wrappers of some kind which better encapsulate their functionality, then maybe we add the appropriate wrappers to Phobos. But that's a completely different issue. Hiding the C functions doesn't help us any.

It makes sense to make truly internal stuff internal, but the standard C function declarations and OS system functions are _not_ internal to druntime. They're _very_ much external. druntime is just providing them because they're functionality which is core to the system that any D program is running on.

- Jonathan M Davis

On 08-05-2012 23:31, Jonathan M Davis wrote:
> On Tuesday, May 08, 2012 14:17:14 Sean Kelly wrote:
>> 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.
>
> We've previously discussed having _all_ of the C system call functions from
> the various OSes that we support being in druntime, and I very much think that
> that's the right way to go. Phobos and druntime then have whatever they need
> as for as standard C and system call functions go, and anyone who needs any
> which aren't wrapped by Phobos in some manner has them available to them.
> Anyone that doesn't want to use any of those C function directly, doesn't have
> to, but I don't see any reason to hide them just because someone doesn't want
> to use them in their code.

+1. We have better things to fix.

>
> If the problem is that certain C functions end up getting used a lot when they
> should have D wrappers of some kind which better encapsulate their
> functionality, then maybe we add the appropriate wrappers to Phobos. But
> that's a completely different issue. Hiding the C functions doesn't help us
> any.

I do think we could benefit from hiding the (deprecated) std.c.* modules on dlang.org (I posted about this a while back).

>
> It makes sense to make truly internal stuff internal, but the standard C
> function declarations and OS system functions are _not_ internal to druntime.
> They're _very_ much external. druntime is just providing them because they're
> functionality which is core to the system that any D program is running on.
>
> - Jonathan M Davis

-- 
- Alex

On 5/8/2012 3:36 PM, foobar wrote:
> 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.

Thousands of my C/C++ floating point constants are broken by the CTFE change since as 'integer'-like float constants 31.f and won't compile anymore, since its trying to do f(31) to them for me now . . .

On 5/8/2012 7:56 PM, Sean Cavanaugh wrote:
> On 5/8/2012 3:36 PM, foobar wrote:
>> 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.
>
> Thousands of my C/C++ floating point constants are broken by the CTFE
> change since as 'integer'-like float constants 31.f and won't compile
> anymore, since its trying to do f(31) to them for me now . . .
>
>
>

s/CTFE/UFCS

On 5/8/2012 7:56 PM, Sean Cavanaugh wrote:
> On 5/8/2012 3:36 PM, foobar wrote:
>> 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.
>
> Thousands of my C/C++ floating point constants are broken by the CTFE
> change since as 'integer'-like float constants 31.f and won't compile
> anymore, since its trying to do f(31) to them for me now . . .
>
>
>

s/CTFE/UFCS

On May 8, 2012, at 2:31 PM, Jonathan M Davis wrote:
> 
> We've previously discussed having _all_ of the C system call functions from the various OSes that we support being in druntime, and I very much think that that's the right way to go. Phobos and druntime then have whatever they need as for as standard C and system call functions go, and anyone who needs any which aren't wrapped by Phobos in some manner has them available to them. Anyone that doesn't want to use any of those C function directly, doesn't have to, but I don't see any reason to hide them just because someone doesn't want to use them in their code.
> 
> If the problem is that certain C functions end up getting used a lot when they should have D wrappers of some kind which better encapsulate their functionality, then maybe we add the appropriate wrappers to Phobos. But that's a completely different issue. Hiding the C functions doesn't help us any.

I personally use "import core.stdc" as an indicator that there may be some feature missing from Phobos.  It's easily greppable, and easy to avoid using the routines.  In fact, I think "import core" anything should be an exceptional case in a typical D application.  Everything exposed in Druntime is for what I'd consider power users.  Unsafe threads, runtime and GC hooks, platform API calls, etc.  It's all there because the higher-level stuff needs it, but is really not intended for general use.


> It makes sense to make truly internal stuff internal, but the standard C function declarations and OS system functions are _not_ internal to druntime. They're _very_ much external. druntime is just providing them because they're functionality which is core to the system that any D program is running on.

Once upon a time, there was a D runtime library (unrelated to Druntime) that has no C library dependence at all.  It was an interesting idea, but I don't know that there's any system that D targets which doesn't support C.

On 08/05/12 14:50, Andrej Mitrovic wrote:
> On 5/8/12, Don Clugston<dac@nospam.com>  wrote:
>> That bug was fixed in git not long after release.
>
> I still get it with this version:
> http://d.puremagic.com/test-results/test_data.ghtml?dataid=180993
> Same errors: http://pastebin.com/8uqgskHd

OK, looks like it's a different bug. Please put in bugzilla, with status of regression.

Sean Cavanaugh wrote:
> On 5/8/2012 3:36 PM, foobar wrote:
> >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.
> 
> Thousands of my C/C++ floating point constants are broken by the CTFE change since as 'integer'-like float constants 31.f and won't compile anymore, since its trying to do f(31) to them for me now . . .

I wholeheartedly agree that breaking changes are frustrating. But especially this one was needed. What we should provide is a clear path to fix the code. In your case, search and replace using a regular expression like s/(\d+).f/\1.0f/g is the way to fix your code in less than 5 minutes I hope.

Jens

On 08-05-2012 23:48, Sean Kelly wrote:
> On May 8, 2012, at 2:31 PM, Jonathan M Davis wrote:
>>
>> We've previously discussed having _all_ of the C system call functions from
>> the various OSes that we support being in druntime, and I very much think that
>> that's the right way to go. Phobos and druntime then have whatever they need
>> as for as standard C and system call functions go, and anyone who needs any
>> which aren't wrapped by Phobos in some manner has them available to them.
>> Anyone that doesn't want to use any of those C function directly, doesn't have
>> to, but I don't see any reason to hide them just because someone doesn't want
>> to use them in their code.
>>
>> If the problem is that certain C functions end up getting used a lot when they
>> should have D wrappers of some kind which better encapsulate their
>> functionality, then maybe we add the appropriate wrappers to Phobos. But
>> that's a completely different issue. Hiding the C functions doesn't help us
>> any.
>
> I personally use "import core.stdc" as an indicator that there may be some feature missing from Phobos.  It's easily greppable, and easy to avoid using the routines.  In fact, I think "import core" anything should be an exceptional case in a typical D application.  Everything exposed in Druntime is for what I'd consider power users.  Unsafe threads, runtime and GC hooks, platform API calls, etc.  It's all there because the higher-level stuff needs it, but is really not intended for general use.
>

I just hope none of it goes away. I make extensive use of many core.* modules.

>
>> It makes sense to make truly internal stuff internal, but the standard C
>> function declarations and OS system functions are _not_ internal to druntime.
>> They're _very_ much external. druntime is just providing them because they're
>> functionality which is core to the system that any D program is running on.
>
> Once upon a time, there was a D runtime library (unrelated to Druntime) that has no C library dependence at all.  It was an interesting idea, but I don't know that there's any system that D targets which doesn't support C.

*Is* there any system that doesn't support C? ;)

-- 
- Alex