On Wednesday, 5 March 2014 at 17:16:34 UTC, Regan Heath wrote:
> It seems this will satisfy Walter without impacting Sean..

As I understand, the idea is that Sean get little trying to fix posix standard: the only way to check if the code works on some platform is to compile and test it on that platform and posix standard doesn't change that. So various platforms ended up adding new functions to posix headers. Having straightforward translations of headers takes less thinking and probably helps migrate from C and doesn't change posix compliance of the headers - it remains conventional.

It can be a module pragma:

pragma(restrictImportTo,"core.sys.posix.ucontext")
module ports.linux.ucontext;

On Thu, 06 Mar 2014 11:17:36 -0000, Kagamin <spam@here.lot> wrote:

> On Wednesday, 5 March 2014 at 17:16:34 UTC, Regan Heath wrote:
>> It seems this will satisfy Walter without impacting Sean..
>
> As I understand, the idea is that Sean get little trying to fix posix standard: the only way to check if the code works on some platform is to compile and test it on that platform and posix standard doesn't change that. So various platforms ended up adding new functions to posix headers. Having straightforward translations of headers takes less thinking and probably helps migrate from C and doesn't change posix compliance of the headers - it remains conventional.

Sure.

The core.sys.<platform>.* modules are/will be straight translations.

Walter wants additional core.* and core.sys.* modules which map to core.sys.<platform>.* as appropriate.

Sean wants/uses core.sys.posix.* modules, which are maintained by someone and only contain posix definitions for all platforms.

Iain wants to be able to split a single platform easily from the rest; taking core.* core.sys.* and core.sys.<platform>.*.

Right?

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Thu, 06 Mar 2014 11:40:55 -0000, Kagamin <spam@here.lot> wrote:

> It can be a module pragma:
>
> pragma(restrictImportTo,"core.sys.posix.ucontext")
> module ports.linux.ucontext;

Good idea, then the platform specific modules can only define the platform specific things.

But, it means when maintaining them you inherently have to consider posix, making the burden a little higher.  Which runs counter to Walter's goal I think.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On 6 March 2014 14:37, Regan Heath <regan@netmail.co.nz> wrote:
> On Thu, 06 Mar 2014 11:17:36 -0000, Kagamin <spam@here.lot> wrote:
>
>> On Wednesday, 5 March 2014 at 17:16:34 UTC, Regan Heath wrote:
>>>
>>> It seems this will satisfy Walter without impacting Sean..
>>
>>
>> As I understand, the idea is that Sean get little trying to fix posix standard: the only way to check if the code works on some platform is to compile and test it on that platform and posix standard doesn't change that. So various platforms ended up adding new functions to posix headers. Having straightforward translations of headers takes less thinking and probably helps migrate from C and doesn't change posix compliance of the headers - it remains conventional.
>
>
> Sure.
>
> The core.sys.<platform>.* modules are/will be straight translations.
>
> Walter wants additional core.* and core.sys.* modules which map to core.sys.<platform>.* as appropriate.
>
> Sean wants/uses core.sys.posix.* modules, which are maintained by someone and only contain posix definitions for all platforms.
>
> Iain wants to be able to split a single platform easily from the rest; taking core.* core.sys.* and core.sys.<platform>.*.
>
> Right?
>


Correct on my part. :)

On 3/5/2014 9:16 AM, Regan Heath wrote:
> 1. Walter wants the C include to map directly to a D import.
> 2. Sean wants to be able to ensure he does not import and use a platform
> specific function/definiton in a cross platform application.
>
> Is that about right?

Yes.

> To clarify some points..
>
> @Walter are you asking for ALL includes even #include <windows.h> to map?

Yes. Of course, if you're on linux and attempt to import core.windows, you should expect a compilation failure, just as you would in C with:

    #include <windows.h>

> For example, <sys/ioctl.h> is not a windows header and would not be considered
> "cross platform".

I'd expect:

    import core.sys.ioctl;

to work on linux systems and fail to compile on windows systems. Just as one would expect in C with:

    #include <sys/ioctl.h>


> I have the following include folders in Visual Studio 2008:
> C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include        - posix,
> c[++] std library headers
> C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\include - ATL/MFC
> headers
> C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include          - windows
> specific headers
>
> would you only expect to map headers from the first of those, and not the rest?

The first, yes, ATL and MFC are not usable with D, and windows, yes.


> That first folder contains 184 files which correlate to posix, and c[++]
> standard library headers.

We wouldn't need the posix or C++ ones.


> It seems this will satisfy Walter without impacting Sean.. other than being
> loads of "unnecessary" modules from your perspective.

Any install on Linux should be able to delete any freebsd.d, osx, windows files with impunity, etc.

On Thursday, 6 March 2014 at 21:35:34 UTC, Walter Bright wrote:
>> To clarify some points..
>>
>> @Walter are you asking for ALL includes even #include <windows.h> to map?
>
> Yes. Of course, if you're on linux and attempt to import core.windows, you should expect a compilation failure, just as you would in C with:
>
>     #include <windows.h>

I'm not sure about this.

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.

Consider, for example, the D module "core.time". POSIX has the header <time.h>. You have a collision right there.

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.

The conversation began with Iain talking about how to improve
things from a maintenance perspective and was kind of sidetracked
by my and Walter's discussion.  I agree that something should be
done to address Iain's issue and think his suggestions sound
pretty good.  But concerning the rest...

Druntime has always been intended to contain the runtime code,
public interfaces to that runtime, plus core functionality that
could be considered essential or intrinsic to the language, a bit
like java.lang.

Having C headers there at all has always been more a matter of
necessity than design, since Druntime needs them for its own use.
  To my knowledge, it's always been a goal to minimize or at least
gently discourage direct use of C routines.  So the declarations
are there when needed, but tucked away in identifiable packages
so their use in an application can be easily determined via grep.
  This also serves an an indicator of where D might be lacking
from a functional perspective, as I don't think we want to
provide a standard library where users feel the need to lean on
another language's standard library.  Thus using libc as a
resource for the implementation of Druntime is more an artifact
of the age of the language than by design, though I'll grant that
it's nearly impossible to get away from using at least kernel
calls in many cases (I think we could absolutely do away with all
use of standard C routines).

My primary concern with Walter's proposal is that it violates the
principal I outlined above by placing the C headers front and
center in core.  It would effectively turn Druntime into a C
interface library, which is vastly different than its original
design goals.  If this is the intent, I propose creating a new
project on github for this purpose.  Otherwise, perhaps some
location beneath the root core package could be chosen for these
to live?  Perhaps just publish everything to core.sys, since that
package already exists?  I admit to completely not understanding
the claim that declarations are hard to find.  But then I
designed the current layout so it clearly makes sense to me.

As far as maintenance is concerned, while I do appreciate that it
becomes untenable to hold the declarations for every platform in
a single module as we have now, say, in core.stdc, I question the
claim that direct conversion of a platform's header files is
somehow less work than cherry-picking declarations according to
some standard.  As I've said before, I believe that automatic
conversion of headers may be considered a copyright violation (by
my reading of the license discussion on the Boost website), and
so manual conversion is our only option.  Given this, and having
all of the work creating and maintaining core.stdc and
core.sys.posix until a few years ago, I would have lost my mind
if I'd had to convert entire headers as-is rather than
cherry-picking declarations.  These headers are so big and so
filled with preprocessor macros and such that replicating the
entirety of what they contained in D code would have been a
nightmare.  But perhaps someone has a good answer for this that I
missed.  I certainly have no desire to maintain these headers in
any manner.  The current approach was simply the one I found that
required the least work.  If there's a way to do it with even
less then I'm all for it.

So I apologize for my part in derailing Iain's discussion.  I
suspect that there's a straightforward solution that's simply
been overlooked from Walter and me talking at cross-purposes.

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.

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.

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.

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 :-)

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.