On 8/26/2014 5:32 PM, Mike wrote:
> We currently have std.c and core.stdc.  I believe core.stdc should be
> migrated to std.c, not the other way around.  And before we make the same
> mistake with core.stdcpp, we should set a new precedent with std.cpp instead.

The irony is D1 has std.c, and for D2 it was migrated to core.stdc.

Moving it back in an endless search for taxonomical perfection just jerks the users around. We've done a lot of renaming in the runtime library, and an awful lot of ink has been spilled on the subject in these forums.

But I'm not aware of a single user gained by these changes, and I suspect we've lost a few, not because they didn't like the newer names, but because they disliked the constant disruption of their code base.

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

> The question of dupplication may be addressed now better, since the newly fixed bug about hierarchical packaging.

I don't see how.

> _only that_ should be the runtime. And the sole part that one needs to port in order to claim having a full port of the D language (that is, the compiler). These are the tires of the cars, the things that touch the ground. Everything else is optional. (Pirelli had a nice advertisemnt with this line)

Well, I agree it absolutely has to be in druntime.

> And, to go further, only c/OS bindings required for this are to be embedded at this level.

Requiring full c/OS bindings in druntime is so useful, and it costs us so little.  Besides a warm fuzzy feeling, not requiring them seems to only benefit D implementations for theoretical platforms that probably don't exist.

> Phobos shall be 100% optional, otherwise you don't have a language, but a framework. This is the separation line: the runtime is a must for the language, the standard library is not. If in doubt wether one piece belongs, cut here.

Call it what you want.  Phobos is supposed to be 100% optional but it currently is not.

We get to decide where the line goes, and with D it is almost always decided on usefulness, not correctness.  Requiring c bindings is useful. 

On Wednesday, 27 August 2014 at 07:52:18 UTC, Daniel Murphy wrote:
> "eles"  wrote in message news:ybcxmuwwpsiyupwerzsa@forum.dlang.org...

> Requiring full c/OS bindings in druntime is so useful, and it costs us so little.

But the request is simply to split the current druntime in a language-runtime and a phobos-runtime. The namespace and so on might even remain the same and the existing code would run unmodified. What is really important is that a clear separation exists between the two *inside* the implementation. The users of D are not concerned about that, the compiler designers are. Have, as now, the language-runtime + the phobos-runtime calles as druntime. Why does bother you a re-modularization of druntime?

> Besides a warm fuzzy feeling, not requiring them seems to only benefit D implementations for theoretical platforms that probably don't exist.

One such platform exists and is the embedded system, others are the linux kernel and the like, and even others are writing D compiler back-ends and, yes, druntimes (well, exactly the part that it is called phobos-runtime above).

If you make porting harder, then you can safely bet that those ports won't ever exist. But is this truly what we want?

On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote:
> On 8/26/2014 5:32 PM, Mike wrote:

> Moving it back in an endless search for taxonomical perfection

Well, keeping things in limbo for such many years (@property, anyone?) is not going to help neither.

I agree it is a fine balance between changing for better consistency and conserve for compatibility.

Still, some changes are small and would solve problems for the many years to come. I still cannot forget that decision to keep the flawed std.uni name instead of a std.unicode name. It wasn't even costly. But, well...

And one day from now you will write "The paradox is that at one moment we decided to keep the std.uni name because of taxonomical compatibility etc. etc. etc."

On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote:
> On 8/26/2014 5:32 PM, Mike wrote:
>> We currently have std.c and core.stdc.  I believe core.stdc should be
>> migrated to std.c, not the other way around.  And before we make the same
>> mistake with core.stdcpp, we should set a new precedent with std.cpp instead.
>
> The irony is D1 has std.c, and for D2 it was migrated to core.stdc.

...and design takes the backseat to convenience.

>
> Moving it back in an endless search for taxonomical perfection just jerks the users around. We've done a lot of renaming in the runtime library, and an awful lot of ink has been spilled on the subject in these forums.
>
> But I'm not aware of a single user gained by these changes, and I suspect we've lost a few, not because they didn't like the newer names, but because they disliked the constant disruption of their code base.

I completely understand and sympathize. This is most unfortunate.

On Wednesday, 27 August 2014 at 02:17:39 UTC, Dicebot wrote:
> On Wednesday, 27 August 2014 at 01:57:38 UTC, Mike wrote:
>>> What do you think about following compromise:
>>>
>>> 1) C bindings are defined in spec to be optional
>>> 2) They are still kept in druntime repo but declared an implementation detail
>>> 3) C bindings are defined to be mandatory in Phobos - if Phobos is used with druntime that does not provide C bindings, it must expose ones of its own.
>>>
>>> It effectively keeps existing layout but moves from a specification to implementation detail making binding-free druntime 100% legal D implementation.
>>
>> By "C bindings" do you really mean "C/C++ bindings" given the context of this thread?
>
> Yeah, "any external / OS bindings" is probably more appropriate wording.

It's a step in the right direction, but ultimately just a formality.  Maybe that's the best I can hope for.

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

> But the request is simply to split the current druntime in a language-runtime and a phobos-runtime. The namespace and so on might even remain the same and the existing code would run unmodified. What is really important is that a clear separation exists between the two *inside* the implementation. The users of D are not concerned about that, the compiler designers are. Have, as now, the language-runtime + the phobos-runtime calles as druntime. Why does bother you a re-modularization of druntime?

I disagree that it's important, or even useful.

> One such platform exists and is the embedded system, others are the linux kernel and the like, and even others are writing D compiler back-ends and, yes, druntimes (well, exactly the part that it is called phobos-runtime above).

An embedded system that can support all of D but doesn't have a cruntime?  I don't believe it.  If it has a cruntime then providing bindings is a non-issue, and if it can't support all of D then supporting only a subset (and then being free to exclude core.stdc) is inevitable.

> If you make porting harder, then you can safely bet that those ports won't ever exist. But is this truly what we want?

I think it's more likely that those ports won't exist because those platforms don't exist. 

On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote:
> On 8/26/2014 5:32 PM, Mike wrote:
>> We currently have std.c and core.stdc.  I believe core.stdc should be
>> migrated to std.c, not the other way around.  And before we make the same
>> mistake with core.stdcpp, we should set a new precedent with std.cpp instead.
>
> The irony is D1 has std.c, and for D2 it was migrated to core.stdc.
>
> Moving it back in an endless search for taxonomical perfection just jerks the users around. We've done a lot of renaming in the runtime library, and an awful lot of ink has been spilled on the subject in these forums.
>

I don't think the problem here is about naming. Both std.c and core.stdc are good.

The problem is that you don't always want to bring libc and libstdc++ with you with every single project you write.

Thus it shouldn't be in the runtime (except the very bit you can't get rid of). It can still be core.stdc .

On Wednesday, 27 August 2014 at 04:23:28 UTC, Mike wrote:
> On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote:
>>
>> I'm asking this community to consider setting a new precedent for druntime:  reduce the scope to just the language implementation, encapsulate and isolate the platform specific logic (e.g. the ports - see 11666), and deport the artificial dependencies to phobos or other libraries.
>>
>
> Please understand that I'm not suggesting we start refactoring druntime for 2.067.  All I'm asking for is that we recognize that C/C++ library and OS bindings don't belong in druntime as public modules, and we gradually work towards migrating them to phobos or some other library in the years to come.

The reason these are in Druntime at all is because code in
Druntime depends on them.  So if they were split into a separate
library then it would be a required library.  And even if we
completely eliminate any dependency on standard C functions, I
don't see any way to avoid depending on platform-specific calls.
Now I would be fine with including just a subset of declarations
in Druntime (which is really what we have right now anyway), but
if the remainder were split into a standalone library then things
start to get weird.  Please let me know if you have a solution to
this problem.

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.

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.

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.

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?