On Tuesday, 26 August 2014 at 18:33:07 UTC, Daniel Murphy wrote:
"Mike" wrote in message
news:[email protected]...
> 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".
