On Friday, 29 August 2014 at 16:54:18 UTC, Sean Kelly wrote:
On Wednesday, 27 August 2014 at 09:43:03 UTC, Mike wrote:
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright
wrote:
The irony is D1 has std.c, and for D2 it was migrated to
core.stdc.
...and design takes the backseat to convenience.
This was a necessary part of the separation of the runtime
components of the standard library from the extraneous stuff.
Consider Druntime to be roughly equivalent to the java.lang
package. It contains code and interfaces that pertain to the
language definition, plus certain related low-level
functionality.
I don't believe it was necessary. D is quite capable of
implementing the same logic that libc has. However, if for
convenience, expediency, time-tested-reliance, optimization, or
some other reason, one wishes to use libc, they can encapsulate
it in the platform-specific logic, because that's what it is.
It will always be a judgement call for where to draw the line.
For example, should Range be in Druntime since it's something
the
compiler is aware of? What about basic math routines that the
compiler might replace with an intrinsic call? So far, we've
actually erred on the side of having less in Druntime rather
than
more. It currently contains user-visible code that's actually
required for every D application: the GC, threads, bit
operations, and atomics, plus some additional code and
declarations that are required to implement these features. And
that's it.
If D is defined as a garbage-collected language, then it makes
sense for the GC to be in druntime. If D is defined as a
language the intrinsically supports threads, then that belongs in
druntime, etc...
But D is not defined as a superset of libc, or a standard
operating system API, so there is no reason to publicly expose
these.
My argument can be limited to core.stdc/stdcpp for now.
* Only a very limited subset of libc is needed by druntime
* These can be eliminated by implementing them in D, or by using
what the platform provides (kernel libs, etc...). It may not be
convenient/expedient to do so, and will take significant effort
and testing, but I'm not saying it needs to be done right now,
just that it should be a goal.
* If it is decided to keep them for convenience/expediency or
another reason, they can be encapsulated by the ports that need
them rather than publicly exposed.
D could be so much more than what it currently is. What I
eventually would like to see is the following ports:
Architecture (bare metal) ports:
-------------------------------
X86
X86_64
ARM9
ARM7M
MIPS
etc..
OS Ports
--------
Windows
Posix
Linux
MacOS
etc...
I believe that list shows what a narrow focus D currently has.
While a libc exists for all of these, and it might be convenient
to use it, it is not necessary given D's capabilities. D could
do it all, and I think that would set D apart from many other
languages if it did.
That being said, it certainly would be convenient to make use of
libc for many of these ports, so let's use it. Just encapsulate
it so if, in the future, someone like me wants to submit pull
requests to gradually remove the dependency on libc, they can do
so without breaking the API and causing controversy.
You might argue that Druntime shouldn't exist as a separate
library at all, and at times I've wondered this myself, but some
of the reasons for this have really borne out in practice, such
as the forced elimination of unnecessary dependencies. If you
look at D1 you'll find that the better part of the standard
library is linked with every D application because some stuff
that's always included (the GC code and what's in dmain, for
example) uses high-level code which in turn depends on
everything
else. And while it's possible to avoid this with proper
discipline, this is much easier to accomplish if the code simply
isn't available in the first place.
I think it is good design to separate the implementation of the
language spec and compiler intrinsics from library functions that
implement domain-specific logic or commonly used utility
functions even if they are considered "low-level".
If one thinks of druntime as a low-level library, there's no
reason to separate it from phobos. But if it's thought of as the
language implementation, as I do, then the reason to separate the
two is quite apparent, and the boundary between the two is quite
stark.
When making these arguments, please try thinking about the
library from the perspective of a library designer and not an
end
user. Does the standard C interface truly belong in Phobos? In
Druntime? Elsewhere? Why? And what factors might influence
your decision? Are any of these factors currently present?
Some
of the reasons for the current design are historic and
unnecessary and others are not. And anything can be changed if
someone comes up with a better idea and is willing to do the
work
to make it so. It sounds like maybe you have a better idea so
why not submit a pull request demonstrating the solution?
I do have what I believe to be a better solution, and I believe I
have articulated it, but it needs community support to go
anywhere.
I must have a different view of druntime than the rest of this
community. I believe it should be an implementation of the
language spec, compiler intrinsics, and encapsulated/isolated
platform-specific logic. I don't see it as a low-level library.
Low-level libraries are just another namespace in phobos. I
don't see how one can even define a "low-level library" and that
is probably why the line between phobos and druntime looks so
blurry to some.
In this thread, I'm simply trying to avoid having core.stdcpp
thrown in the druntime when I'm trying to move core.stdc to std.c.
It is wise to first use these forums to check for support first,
before much time and energy is spent on work that will just be
rejected. Take a look at all the work that went into DIP62 and
how that worked out for the author.
I'm judging by both the responses in this thread and the lack of
responses in this thread that there isn't support, so I'm fine to
go my own way with my ideas if that's what's preferred.
Mike
