On Tuesday, 26 August 2014 at 12:54:49 UTC, Daniel Murphy wrote:

> I really don't see a practical problem with having them in druntime, only a philosophical one.

It give the impression that D requires the C standard library, the C++ standard library, and an full-featured desktop OS in order to function.  If I create a port without core.stdc, it can be argued that my port is incomplete.  Well I argue that my port is a complete implementation of the language and core.stdc is not part of the D language.

> They should still be available when not using phobos,

Then they can be put in their own library instead of phobos.  That's even better as far as I'm concerned.  GTKD isn't part of phobos or druntime.  I don't see libc as being any different (in principle) than GTKD.

> and they are used in druntime internally.

For a practical implementation, those ports that have a libc can make use of it, but it should be internal, and isolated from the language implementation and the other ports, as is the spirit of 11666.

But you could take it a step further for the principled approach.  Implement those few features of libc that are needed by the druntime in D, and earn some bragging rights.

Why create DDMD?  We already have an implementation in C++, right.  What a waste of time... (of course I'm being facetious.  Forgive me, but I think it's a great example of why we should do something in D even though a C/C++ implementation exists.  No offense intended)

> 11666 is contentious because everybody has a different opinion on the layout.  This is about personal preferences, and has nothing to do with OS bindings being in druntime.  The same exact discussion would happen if they were in phobos.

That's exactly my point.  The debate that ensued with 11666 had nothing to do with the spirit of 11666.  If those OS bindings weren't in druntime, 11666 would already be implemented without controversy.  And we'd likely already have a few more ports of D to other platforms.  The 11666 debate belongs in a std.linux debate or a liblinux debate or some other OS API port debate.

Publicly exposing core.stdc and the OS bindings in druntime is getting in the way of bringing D to more platforms, and the 11666 debate demonstrates that.

> I get that you're saying this, but why?  How will it make any difference to anything ever?  libc is ubiquitous, and the parts that are used internally could trivially be reimplemented on a platform where it was missing.  (or more likely, it could just be ported)

Or those features in libc could be implemented in D, removing the artificial dependency on libc.

> ???????????  If you want to / need to, you can write a libc implementation in D.  The fact that the major D platforms all choose to link against the system libc instead of rolling their own has no bearing on the language class of D.  The fact that druntime includes a prototype for memcpy or fopen does not change anything either.  It just makes D more convenient for porting C code.

Only the *port* should have bindings to libc.  The language implementation should not.  Again those bindings should be encapsulated in the port, not publicly exposed as part of the D language.

> It could be my failing, but I really don't see the point.  What are the potential consequences of maintaining and extending the C, C++ and OS bindings in druntime?

* It conflates the language with the platform.  druntime should be solely the implementation of the language, not an OS API.
* It conflates the implementation of the language with bindings for external libraries. Again, druntime is the language implementation, not an application programming framework.
* It sets the wrong precedent for a systems programming language.  IMO a true systems programming language should be self-reliant.  That is, it should be a language that can be used to build the first layer of hardware abstraction.
* It creates artificial dependencies when there's no real dependency.  C++ being a superset of C is an example of a real dependency.  That is not D.
* It gets in the way of porting the language to more platforms and complicates maintenance of the runtime. Case in point: the 11666 debate.
* It makes D unportable to some platforms without creating their own dialect of the language or their own D runtime implementation

In summary, I believe libc, libstd++, and the OS bindings should be encapsulated and isolated by the ports that need them, not publicly exposed as part of the D language implementation.  Having bindings to these these libraries is super important, and I'm glad they exists.  I just don't think they belong in the D language implementation, except as encapsulated, isolated artifacts of ports that need them.

Mike

On Tuesday, 26 August 2014 at 15:44:31 UTC, eles wrote:
> On Tuesday, 26 August 2014 at 15:30:35 UTC, Mike wrote:
>> On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei Alexandrescu wrote:
>>> On 8/26/14, 3:06 AM, Mike wrote:
>
>> The same goes for core.stdc and core.sys.linux and friends, as these are not part of D's language implementation.
>
> Am I correct to define the language as:
>
> --------begin file---------------
> //no imports here
>
> //any code here
> ---------------------------------
>
> ?
>
> If you import, then is the library.

That may be an oversimplification, but basically, "Yes".

On 8/26/2014 8:30 AM, Mike wrote:
> If core.stdcpp is intended to be the language bindings to libstdc++, I don't
> think it should belong it D's language implementation, druntime, any more the
> language bindings to Cairo or GTK should.
>
> The same goes for core.stdc and core.sys.linux and friends, as these are not
> part of D's language implementation.

Regardless of where stdcpp goes, one issue is that the stuff in it goes into the namespace "std", which conflicts with Phobos' "std" higher level package name. So it has to be in a separate hierarchy.

There's never going to be a clear distinction between druntime and phobos. The original reason for the split anyway was that druntime would be a common core between Tango and Phobos. That reason has faded away.

I suggested core.stdcpp because given the existence of core.stdc, it's where people will expect to find it.

On Tuesday, 26 August 2014 at 17:09:58 UTC, Walter Bright wrote:
> On 8/26/2014 8:30 AM, Mike wrote:

> Regardless of where stdcpp goes, one issue is that the stuff in it goes into the namespace "std", which conflicts with Phobos' "std" higher level package name.

wow. I remember the hot debate about the name o the standard library back then.

Remember proposition dsl (D standard library) anyone?

and your (sad) comment: "Nobody likes phobos" :)

On Tuesday, 26 August 2014 at 18:13:01 UTC, eles wrote:
> On Tuesday, 26 August 2014 at 17:09:58 UTC, Walter Bright wrote:
>> On 8/26/2014 8:30 AM, Mike wrote:

> wow. I remember the hot debate about the name o the standard library back then.

well, namesace name

On 8/26/14, 8:30 AM, Mike wrote:
> On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei Alexandrescu wrote:
>> On 8/26/14, 3:06 AM, Mike wrote:
>>> D has a lot of potential beyond it's current use.  Please take this
>>> opportunity to reflect on what's been done, take a look ahead, and see
>>> if we can set a better precedent for the future.
>>
>> C++ interoperability is very important for D's future. -- Andrei
>
> I know it is and I fully support it.  I'm not arguing against it.
>   Please add all C++ interoperability support you want to the compiler
> and to druntime.  I look forward to making use of it.

Great.

> But libstdc++ is not part of C++-the-language, and libc is not part of
> C-the-language.  C and C++ can be used without them; I do every day.
>
> If core.stdcpp is intended to be the language bindings to libstdc++, I
> don't think it should belong it D's language implementation, druntime,
> any more the language bindings to Cairo or GTK should.
>
> The same goes for core.stdc and core.sys.linux and friends, as these are
> not part of D's language implementation.

I don't understand the objection. Are you arguing that we shouldn't make core.stdc and core.stdcpp available, and instead let anyone who wants to use libc and libc++ write their own declarations?


Andrei

"Mike"  wrote in message news:bkkdiikafdsraqssjndv@forum.dlang.org...

> > I really don't see a practical problem with having them in druntime, only a philosophical one.
>
> It give the impression that D requires the C standard library, the C++ standard library, and an full-featured desktop OS in order to function. If I create a port without core.stdc, it can be argued that my port is incomplete.  Well I argue that my port is a complete implementation of the language and core.stdc is not part of the D language.

What platform supports threads and GC but doesn't have a C lib available?  I certainly would argue that this hypothetical port is incomplete, not because druntime including bindings to libc declares it part of the language, but because I can't see a good reason not to include them.

> Then they can be put in their own library instead of phobos.

Yes, they could.  IMO the downsides of having to maintain a third library outweighs the 'correctness' advantage, or even having a different root package for this stuff.  And there is no way it's ever going to change at this point.

> That's even better as far as I'm concerned.  GTKD isn't part of phobos or druntime.  I don't see libc as being any different (in principle) than GTKD.

Druntime doesn't use GTK, so it is different.  The inclusion of C/OS bindings is historical, and not worth changing.

> > and they are used in druntime internally.
>
> For a practical implementation, those ports that have a libc can make use of it, but it should be internal, and isolated from the language implementation and the other ports, as is the spirit of 11666.

There is no point as the bindings are already in druntime and there is very little chance that is going to change.

> But you could take it a step further for the principled approach. Implement those few features of libc that are needed by the druntime in D, and earn some bragging rights.

You could, but it has very little practical value.  I personally wouldn't waste my time bragging to someone who thinks druntime depending on libc is an argument against D.

> Why create DDMD?  We already have an implementation in C++, right.  What a waste of time... (of course I'm being facetious.  Forgive me, but I think it's a great example of why we should do something in D even though a C/C++ implementation exists.  No offense intended)

It's possible you missed the point of DDMD.  DMD is an actively developed codebase which can benefit from many of the features D offers.  Well, that was my motivation anyway.  I know other people got excited by the idea for other reasons.

There is no practical advantage (to the project) from converting a fully debugged, optimized application or library to another language, unless the language barrier is preventing interop.  A libc written in D would not give us anything of practical value.

> That's exactly my point.  The debate that ensued with 11666 had nothing to do with the spirit of 11666.  If those OS bindings weren't in druntime, 11666 would already be implemented without controversy.  And we'd likely already have a few more ports of D to other platforms.  The 11666 debate belongs in a std.linux debate or a liblinux debate or some other OS API port debate.

No, the exact same thing would have happened if they were in a different package/repository.  A different root package would not change the contributors or contribution process.

> Publicly exposing core.stdc and the OS bindings in druntime is getting in the way of bringing D to more platforms, and the 11666 debate demonstrates that.

This is just nonsense.  Changing the root package changes nothing.

> Or those features in libc could be implemented in D, removing the artificial dependency on libc.

Re-implementing debugged and optimized code is a waste of time.

> Only the *port* should have bindings to libc.  The language implementation should not.  Again those bindings should be encapsulated in the port, not publicly exposed as part of the D language.

1) Being part of druntime does not automatically mean something HAS to be available on every platform.  eg the windows bindings are not available on non-windows
2) I don't see any point in not exposing the c lib from druntime, nor do I see any platform where that would be a problem that does not have much more serious issues with hosting D.

> * It conflates the language with the platform. druntime should be solely the implementation of the language, not an OS API.

I disagree, having the OS API in druntime is great and not a problem.

> * It conflates the implementation of the language with bindings for external libraries.

C interop is part of D.  Low level (direct) access to operating system APIs is part of D.  Exposing them is useful.

> Again, druntime is the language implementation, not an application programming framework.

By this logic the C lib header files and windows.h files make an application programming framework.

> * It sets the wrong precedent for a systems programming language. IMO a true systems programming language should be self-reliant.  That is, it should be a language that can be used to build the first layer of hardware abstraction.

D can be used for that.  But realistically, this is a constrained environment which will use a custom druntime, and be restricted to a subset of D.

> * It creates artificial dependencies when there's no real dependency.  C++ being a superset of C is an example of a real dependency.  That is not D.

I don't consider this to be a problem worth worrying about.

> * It gets in the way of porting the language to more platforms and complicates maintenance of the runtime. Case in point: the 11666 debate.

No, it doesn't.  Even if these bindings weren't in druntime, they'd be in another official library.  Nothing would be different with respect to 11666.

> * It makes D unportable to some platforms without creating their own dialect of the language or their own D runtime implementation

I expect D is already unportable to these platforms without doing these things.  Removing libc bindings would not change this.

> In summary, I believe libc, libstd++, and the OS bindings should be encapsulated and isolated by the ports that need them, not publicly exposed as part of the D language implementation.  Having bindings to these these libraries is super important, and I'm glad they exists.  I just don't think they belong in the D language implementation, except as encapsulated, isolated artifacts of ports that need them.

In an ideal world, the bindings would be more cleanly separated from other runtime stuff.  But they're not.  It would require a very compelling argument to move them now, and this really isn't it.

We could document that core.stdc is not a required part of a D implementation, but it should be trivial to provide on any platform that can support a complete the rest of D, so there doesn't seem to be any point. 

On Tuesday, 26 August 2014 at 17:09:58 UTC, Walter Bright wrote:
> On 8/26/2014 8:30 AM, Mike wrote:

> There's never going to be a clear distinction between druntime and phobos. The original reason for the split anyway was > druntime would be a

Well, in C there is and I like that distinction: the runtime handles everything that doesn't need a #include, and that is:

- formatting and passing the arguments to main()
- replacing some constants (IIRC) at runtime, especially those with sizeof(array)

While the distinction between druntime and phobos is one thing (and you are right that it was about Tango vs Phobos, because otherwise Tango was reimplementing those parts in a Phobos-incompatible ways, which prevented programs to use both), now the discussion is more about (c-like) runtime vs (c-like) standard library.

On Tuesday, 26 August 2014 at 18:33:07 UTC, Daniel Murphy wrote:
> "Mike"  wrote in message news:bkkdiikafdsraqssjndv@forum.dlang.org...
>
>> > I really don't see a practical problem with having them in druntime, only a philosophical one.
>>
>> It give the impression that D requires the C standard library, the C++ standard library, and an full-featured desktop OS in order to function. If I create a port without core.stdc, it can be argued that my port is incomplete.  Well I argue that my port is a complete implementation of the language and core.stdc is not part of the D language.
>
> What platform supports threads and GC but doesn't have a C lib available?  I certainly would argue that this hypothetical port is incomplete, not because druntime including bindings to libc declares it part of the language, but because I can't see a good reason not to include them.
>
>> Then they can be put in their own library instead of phobos.
>
> Yes, they could.  IMO the downsides of having to maintain a third library outweighs the 'correctness' advantage, or even having a different root package for this stuff.  And there is no way it's ever going to change at this point.
>
>> That's even better as far as I'm concerned.  GTKD isn't part of phobos or druntime.  I don't see libc as being any different (in principle) than GTKD.
>
> Druntime doesn't use GTK, so it is different.  The inclusion of C/OS bindings is historical, and not worth changing.
>
>> > and they are used in druntime internally.
>>
>> For a practical implementation, those ports that have a libc can make use of it, but it should be internal, and isolated from the language implementation and the other ports, as is the spirit of 11666.
>
> There is no point as the bindings are already in druntime and there is very little chance that is going to change.
>
>> But you could take it a step further for the principled approach. Implement those few features of libc that are needed by the druntime in D, and earn some bragging rights.
>
> You could, but it has very little practical value.  I personally wouldn't waste my time bragging to someone who thinks druntime depending on libc is an argument against D.
>
>> Why create DDMD?  We already have an implementation in C++, right.  What a waste of time... (of course I'm being facetious.  Forgive me, but I think it's a great example of why we should do something in D even though a C/C++ implementation exists.  No offense intended)
>
> It's possible you missed the point of DDMD.  DMD is an actively developed codebase which can benefit from many of the features D offers.  Well, that was my motivation anyway.  I know other people got excited by the idea for other reasons.
>
> There is no practical advantage (to the project) from converting a fully debugged, optimized application or library to another language, unless the language barrier is preventing interop.  A libc written in D would not give us anything of practical value.
>
>> That's exactly my point.  The debate that ensued with 11666 had nothing to do with the spirit of 11666.  If those OS bindings weren't in druntime, 11666 would already be implemented without controversy.  And we'd likely already have a few more ports of D to other platforms.  The 11666 debate belongs in a std.linux debate or a liblinux debate or some other OS API port debate.
>
> No, the exact same thing would have happened if they were in a different package/repository.  A different root package would not change the contributors or contribution process.
>
>> Publicly exposing core.stdc and the OS bindings in druntime is getting in the way of bringing D to more platforms, and the 11666 debate demonstrates that.
>
> This is just nonsense.  Changing the root package changes nothing.
>
>> Or those features in libc could be implemented in D, removing the artificial dependency on libc.
>
> Re-implementing debugged and optimized code is a waste of time.
>
>> Only the *port* should have bindings to libc.  The language implementation should not.  Again those bindings should be encapsulated in the port, not publicly exposed as part of the D language.
>
> 1) Being part of druntime does not automatically mean something HAS to be available on every platform.  eg the windows bindings are not available on non-windows
> 2) I don't see any point in not exposing the c lib from druntime, nor do I see any platform where that would be a problem that does not have much more serious issues with hosting D.
>
>> * It conflates the language with the platform. druntime should be solely the implementation of the language, not an OS API.
>
> I disagree, having the OS API in druntime is great and not a problem.
>
>> * It conflates the implementation of the language with bindings for external libraries.
>
> C interop is part of D.  Low level (direct) access to operating system APIs is part of D.  Exposing them is useful.
>
>> Again, druntime is the language implementation, not an application programming framework.
>
> By this logic the C lib header files and windows.h files make an application programming framework.
>
>> * It sets the wrong precedent for a systems programming language. IMO a true systems programming language should be self-reliant.  That is, it should be a language that can be used to build the first layer of hardware abstraction.
>
> D can be used for that.  But realistically, this is a constrained environment which will use a custom druntime, and be restricted to a subset of D.
>
>> * It creates artificial dependencies when there's no real dependency.  C++ being a superset of C is an example of a real dependency.  That is not D.
>
> I don't consider this to be a problem worth worrying about.
>
>> * It gets in the way of porting the language to more platforms and complicates maintenance of the runtime. Case in point: the 11666 debate.
>
> No, it doesn't.  Even if these bindings weren't in druntime, they'd be in another official library.  Nothing would be different with respect to 11666.
>
>> * It makes D unportable to some platforms without creating their own dialect of the language or their own D runtime implementation
>
> I expect D is already unportable to these platforms without doing these things.  Removing libc bindings would not change this.
>
>> In summary, I believe libc, libstd++, and the OS bindings should be encapsulated and isolated by the ports that need them, not publicly exposed as part of the D language implementation.  Having bindings to these these libraries is super important, and I'm glad they exists.  I just don't think they belong in the D language implementation, except as encapsulated, isolated artifacts of ports that need them.
>
> In an ideal world, the bindings would be more cleanly separated from other runtime stuff.  But they're not.  It would require a very compelling argument to move them now, and this really isn't it.
>
> We could document that core.stdc is not a required part of a D implementation, but it should be trivial to provide on any platform that can support a complete the rest of D, so there doesn't seem to be any point.

While this might be acceptable, there is one more question: what use to have the druntime separated from phobos, in this case?

For me the druntime shall include only the runtime components that are required for a program to function and on which one could build the whole standard library. And that would be: handling the arguments, the GC, basically, the D program execution model. And by D here I mean "the language", not the "batteries included".

"eles"  wrote in message news:qrfucjdbmydvoqgeyybp@forum.dlang.org...

> While this might be acceptable, there is one more question: what use to have the druntime separated from phobos, in this case?

Apart from the fact that it's too late to change of course.

> For me the druntime shall include only the runtime components that are required for a program to function and on which one could build the whole standard library. And that would be: handling the arguments, the GC, basically, the D program execution model. And by D here I mean "the language", not the "batteries included".

Druntime and phobos both had c/OS bindings at some point (core.stdc + std.c) but duplication is bad, so they were/are being moved into druntime.

In druntime you have the true, hidden runtime code (startup, profiler, coverage, unittesting, AAs), plus core language stuff (GC, Thread (+core.time)).

Phobos is supposed to be 100% optional, although it isn't, quite.  If you don't want to use phobos, for example if you are automatically porting a large C++ application, it's nice to simply ban phobos and have that clear distinction.