On 6 March 2014 22:53, Walter Bright <newshound2@digitalmars.com> wrote:
> On 3/6/2014 2:32 PM, Vladimir Panteleev wrote:
>>
>> First of all, even considering the idea of putting everything in one
>> package, it
>> should not be "core". There are many D-specific things in "core" right
>> now. It's
>> probably best to keep OS includes and D stuff differently.
>
>
> Sure. The package name isn't important, it's what follows that is.
>
>
>
>> Second, I think that the different ways with how C and D approach headers
>> (list
>> of include paths vs. module system and package hierarchy) warrants
>> considering
>> another solution. For example, at least on Windows, the compiler consults
>> at
>> least two include directories: the C runtime includes (for declarations
>> that are
>> part of C and whatever part of POSIX emulation is included), and the
>> Windows
>> SDK. Sometimes, components migrate from one project to another (e.g.
>> DirectShow
>> was moved out of the DirectX SDK and into the Windows Platform SDK). Thus
>> I
>> think it would be preferable to keep things organized in packages rather
>> than
>> flattening everything together.
>
>
> What I want to see is a strong correspondence between what a C coder would write when #including system files, and the corresponding D import. What I object to are:
>
> 1. Trying to reinvent, improve, refactor, fix, clean up, etc., the OS api. This is not in D's charter. We have no resources to do it properly anyway.
>

I don't think that is what druntime does in terms of it's C interfacing modules.  What it does do is make it more logical for people to find what they are looking for, or if they want to make changes, which areas to look at.


> 2. Trying to split C's header files into separate posix / nonposix modules. As in (1), this is beyond the scope of what D is trying to do.
>

I think the word posix seems to be the cesspool that's repeatedly brought up here to fan the flames here.   What about the linux/freebsd/osx/windows packages?


> 3. Pushing versioning into user code, as in:
>
>     version (linux) import os.linux.whatever;
>     else version (FreeBSD) import os.freebsd.whatever;
>     ...
>     else static assert(0);
>
> as opposed to:
>
>     import os.whatever;
>
> I understand the sentiment that this will signal to the user that he's using non-portable imports, but I don't think it's worth it. Portability is what Phobos is for, not OS api interfaces.
>

This is something that needs to be worked on, but I'm not convinced a flat hierachy will solve anything.

Regards
Iain

On Tuesday, 4 March 2014 at 00:09:47 UTC, Walter Bright wrote:
> This is an important debate going on here:
>
> https://github.com/D-Programming-Language/druntime/pull/732
>
> It has a wide impact, and so I'm bringing it up here so everyone can participate.

I originally posted issue 11666 after reading Iain's post here [1], as I am trying to port the D Runtime to a bare-metal platform and couldn't see the abstractions in the D Runtime.

If this statement about Iain's stance is correct ("Iain wants to be able to split a single platform easily from the rest") then I am with Iain.

However, I see from the whole posix/C debate, that D is having somewhat of an identity crisis.  And I think if D could decide what it wants to be, the solution may present itself.

*Question*
Does D's implementation require an OS, or does the OS's implementation require a language like D?

I refer you to a suggestion by Manu here [2].
"I prefer the idea already mentioned of making a more well-defined
separation of D-core (static stuff), and then the rest as a higher layer."

I think there should be 3 different abstractions in the D Runtime:
1. Language features.
2. OS features built on those core language features.
3. Language features built on those OS features

Finally Phobos can be built on top of 3.

Each one of those abstractions would require a platform's folder/package.  How those folders/packages should be organized can be further debated, but without first making these abstractions, the discussion becomes too convoluted.

My opinions:
* D should not require C
* D should not do things the C way
* Some features of D should not require an OS

destroy(me);

Mike

[1] http://forum.dlang.org/post/mailman.1526.1333966829.4860.digitalmars-d@puremagic.com
[2] http://forum.dlang.org/post/mailman.18.1392171489.6445.digitalmars-d@puremagic.com

On 6 March 2014 23:46, Sean Kelly <sean@invisibleduck.org> wrote:
> On Thursday, 6 March 2014 at 22:53:40 UTC, Walter Bright wrote:
>>
>>
>> 4. Attempts to eliminate code duplication in OS api interface modules. A desire to do this comes up repeatedly. I can expand on this if anyone remains unconvinced :-)
>
>
> I 100% agree with this.  Trying to avoid code duplication here leads to madness.

Indeed, I don't recall a single port-related pull in the last several months that tried to do any refactoring.  I think the general consensus among the current mantainers is that explicit versioning is good, vague/fallback else is bad.  However on the flip side, the more ports you add into one single file, the more you descend back into the madness you were initially trying to avoid.

I hope code duplication in many files rather than one file is in the interest of everyone. :)

On Thursday, 6 March 2014 at 23:56:35 UTC, Iain Buclaw wrote:
> I hope code duplication in many files rather than one file is in the
> interest of everyone. :)

The only people it doesn't benefit are the ones maintaining multiple ports :)

I agree with Walter that "attempts to eliminate code duplication in OS api interface modules" is misguided.

Software often has common implementations simply by coincidence, not because there is an inherent relationship between them.

Mike

On Mar 7, 2014 12:10 AM, "Mike" <none@none.com> wrote:
>
> On Thursday, 6 March 2014 at 23:56:35 UTC, Iain Buclaw wrote:
>>
>> I hope code duplication in many files rather than one file is in the interest of everyone. :)
>
>
> The only people it doesn't benefit are the ones maintaining multiple
ports :)
>

I disagree. It makes my work more organised, and it removes the trap of deduping without the hassle.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Thursday, 6 March 2014 at 23:56:35 UTC, Iain Buclaw wrote:
>
> Indeed, I don't recall a single port-related pull in the last  several
> months that tried to do any refactoring.  I think the general
> consensus among the current mantainers is that explicit versioning is
> good, vague/fallback else is bad.  However on the flip side, the more ports you add into one single file, the more you descend back into the madness you were initially trying to avoid.
>
> I hope code duplication in many files rather than one file is in the interest of everyone. :)

Yep.  I think I mentioned in the github thread that while
versioning implementations within a single module worked for me,
it was because I was only targeting 3 platforms.  With the number
of targets GDC and LLDC have, I think breaking things up as you
suggest is a preferable option.

On 3/6/2014 3:51 PM, Iain Buclaw wrote:
> On 6 March 2014 22:53, Walter Bright <newshound2@digitalmars.com> wrote:
>> 1. Trying to reinvent, improve, refactor, fix, clean up, etc., the OS api.
>> This is not in D's charter. We have no resources to do it properly anyway.
>
> I don't think that is what druntime does in terms of it's C
> interfacing modules.

Usually not. But proposals to do such come up now and then - I just want to head these off before anyone invests effort in it.


> What it does do is make it more logical for
> people to find what they are looking for, or if they want to make
> changes, which areas to look at.

Eh, "more logical" is a trap. I'd prefer a simple 1:1 correspondence between C and D for OS api's. Then there's nothing clever about it, no decisions to make, and the user familiar with C will know where it is.


>> 2. Trying to split C's header files into separate posix / nonposix modules.
>> As in (1), this is beyond the scope of what D is trying to do.
>>
>
> I think the word posix seems to be the cesspool that's repeatedly
> brought up here to fan the flames here.   What about the
> linux/freebsd/osx/windows packages?

Eliminate the linux/freebsd/osx/windows package inventions. I don't see in C code:

    #include <sys/linux/sys/foo.h>

so why should we do that? Again, what I propose is really simple from a user point of view - a 1:1 mapping between what he'd type in for C vs what he'd type in for D.


>> 3. Pushing versioning into user code, as in:
>>
>>      version (linux) import os.linux.whatever;
>>      else version (FreeBSD) import os.freebsd.whatever;
>>      ...
>>      else static assert(0);
>>
>> as opposed to:
>>
>>      import os.whatever;
>>
>> I understand the sentiment that this will signal to the user that he's using
>> non-portable imports, but I don't think it's worth it. Portability is what
>> Phobos is for, not OS api interfaces.
>>
>
> This is something that needs to be worked on, but I'm not convinced a
> flat hierachy will solve anything.

What it will solve is when the user reads the OS api documentation, and it says:

    #include <sys/ioctl.h>

then the user knows that in D he has to do:

    import whatever.sys.ioctl;

What the user should not have to do is:

    version (linux) import whatever.linux.sys.ioctl;
    else version (FreeBSD) import whatever.freebsd.sys.ioctl;
    else version (OSX) import whatever.osx.sys.ioctl;
    ...
    else static assert(0);

nor:

    import whatever.posix.sys.ioctl;
    version (linux) import whatever.linux.sys.ioctl;
    else version (FreeBSD) import whatever.freebsd.sys.ioctl;
    else version (OSX) import whatever.osx.sys.ioctl;
    ...
    else static assert(0);

On Friday, 7 March 2014 at 00:53:18 UTC, Walter Bright wrote:
>
> What it will solve is when the user reads the OS api documentation, and it says:
>
>     #include <sys/ioctl.h>
>
> then the user knows that in D he has to do:
>
>     import whatever.sys.ioctl;
>
> What the user should not have to do is:
>
>     version (linux) import whatever.linux.sys.ioctl;
>     else version (FreeBSD) import whatever.freebsd.sys.ioctl;
>     else version (OSX) import whatever.osx.sys.ioctl;
>     ...
>     else static assert(0);
>
> nor:
>
>     import whatever.posix.sys.ioctl;
>     version (linux) import whatever.linux.sys.ioctl;
>     else version (FreeBSD) import whatever.freebsd.sys.ioctl;
>     else version (OSX) import whatever.osx.sys.ioctl;
>     ...
>     else static assert(0);

Toe be fair, I expect the user would almost never be importing
platform-specific headers.  Importing the posix headers is all
that should be needed in the common case.  Or if you need
something platform-specific, then don't import the posix header
because doing so is redundant--the platform header publicly
imports it anyway.

However, as much as I like that having the Posix headers strongly
encourages the user to write portable code, I can see the idea
doesn't have a lot of traction around here.  I beleive Iain's
proposal is to phase them out and do exactly what you suggest,
only to make "whatever" "core.foo" rather than simply "core".
Which works for me as well.

On 3/6/2014 5:10 PM, Sean Kelly wrote:
> However, as much as I like that having the Posix headers strongly
> encourages the user to write portable code, I can see the idea
> doesn't have a lot of traction around here.  I beleive Iain's
> proposal is to phase them out and do exactly what you suggest,

Thanks, Sean, I appreciate the graciousness of your reply.


> only to make "whatever" "core.foo" rather than simply "core".
> Which works for me as well.

I don't have any axe to grind about what the "whatever" expands to, I'm cool with either.

On 7 March 2014 01:24, Walter Bright <newshound2@digitalmars.com> wrote:
> On 3/6/2014 5:10 PM, Sean Kelly wrote:
>>
>> However, as much as I like that having the Posix headers strongly encourages the user to write portable code, I can see the idea doesn't have a lot of traction around here.  I beleive Iain's proposal is to phase them out and do exactly what you suggest,
>
>
> Thanks, Sean, I appreciate the graciousness of your reply.
>
>
>
>> only to make "whatever" "core.foo" rather than simply "core". Which works for me as well.
>
> I don't have any axe to grind about what the "whatever" expands to, I'm cool with either.


I assume the C headers will remain strictly under core.stdc?  So it might make sense to transition core.sys -> core.stdc.sys?