core.stdcpp
Mike via Digitalmars-d-announce
digitalmars-d-announce at puremagic.com
Fri Aug 29 17:01:49 PDT 2014
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
More information about the Digitalmars-d-announce
mailing list