On Wednesday, 27 August 2014 at 21:38:04 UTC, deadalnix wrote:
>
> 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 .

To be fair, the only part you bring with you are the dependencies
that Druntime itself has.  And nearly all of core.stdc is
declarations anyway, so the only code bloat is unused ModuleInfo
objects (notice that in places where Druntime uses C structs it
declares them as "=void" to avoid depending on default
initialization).

The remaining issue becomes one of maintenance.  If Druntime only
declares the functions it needs, then where does the other stuff
live?  If you want to use that other library to get everything,
does it publicly import core.stdc for the basics?  What if
Druntime needs a new call for some reason that's in this separate
library?  Do we declare it in core.stdc and cause collisions?
What if D is ported to a new platform?  That may require a whole
raft of new declarations, both in a common API like core.stdc and
in something more targeted like core.sys.linux.

Don't get me wrong, I hate having to maintain the modules in
core.stdc and core.sys.  It's the worst job ever.  I'm just not
aware of a better solution to this particular problem.

On Wednesday, 27 August 2014 at 18:06:00 UTC, Daniel Murphy wrote:
> "eles"  wrote in message news:rixtiaiokrukvqjsfrdh@forum.dlang.org...
>
>> 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.

There was a D runtime years ago created as a separate project
around the time that Druntime had its beginnings (as Ares) that
had no dependencies on standard C.  The creator went by Maide in
IRC, and she was doing some really cool stuff with it that made D
work kind of like ObjectiveC.  I don't think it's in development
any more, but it's probably possible to track it down with enough
googling.

On 8/27/2014 2:38 PM, deadalnix wrote:
> The problem is that you don't always want to bring libc and libstdc++ with you
> with every single project you write.

Remember that a library is not simply inserted bodily into the executable. A library is searched for modules that define unresolved symbols.

I.e. only if you use code that refers to libc or libstd++ will those bits be linked in.

On 8/29/14, 10:02 AM, Sean Kelly wrote:
> Don't get me wrong, I hate having to maintain the modules in
> core.stdc and core.sys.  It's the worst job ever.

It's also one of those jobs silently appreciated by many. -- Andrei

On 08/29/2014 07:07 PM, Sean Kelly wrote:
> On Wednesday, 27 August 2014 at 18:06:00 UTC, Daniel Murphy wrote:
>> "eles"  wrote in message news:rixtiaiokrukvqjsfrdh@forum.dlang.org...
>>
>>> 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.
> 
> There was a D runtime years ago created as a separate project around the time that Druntime had its beginnings (as Ares) that had no dependencies on standard C.  The creator went by Maide in IRC, and she was doing some really cool stuff with it that made D work kind of like ObjectiveC.  I don't think it's in development any more, but it's probably possible to track it down with enough googling.

It's still available at dsource: http://www.dsource.org/projects/ares

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

On Saturday, 30 August 2014 at 00:01:50 UTC, Mike wrote:
> 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:

> 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.

Actuall, I am very much in favor of this, but I admit we are a bit in minority. I fel it is not because people ara gainst it, but because they feel is not very important. Plus, they have the impression that this will involve renaming modules and will need modifying curent source code.

It is not about that. Names could remain just as they are, it is only about isolating that part of druntime that is really critical to run the language. As you defined very well, that part that corresponds to java.lang.

There is one thing that bothers me, still, and I did not find the appropriate solution to it: if the language defines threads and garbage collector, I agree the mechanism for those should go in the runtime, but what to do with the function required to handle those? For example, creating a thread is done with a function (not with a keyword!) and the same goes for the GC.disable(), for example.

So, this will kinda break the "runtime means no imports" mantra. Or, otherwise, how to do it? C++ fully accepted its dependency on stdlib when they wen with Threads, isn't?

I find it uneasy that one accesses the runtime through "import". Why we should need that? In C you never import/include something for the runtime, nor you have control over it from inside the program. It is through compiler params.

On Saturday, 30 August 2014 at 08:39:12 UTC, eles wrote:
> On Saturday, 30 August 2014 at 00:01:50 UTC, Mike wrote:
>> 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:
>
>> 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.
>
> Actuall, I am very much in favor of this, but I admit we are a bit in minority. I fel it is not because people ara gainst it, but because they feel is not very important.

For the record: This describes my stance, too. I acknowledge that it would be cleaner to separate the C bindings in a dedicated package outside of druntime (though druntime could then import this library instead of keeping its own copy of some bindings around). This package could then contain bindings to higher-level libraries, too. I just don't see it as a pressing issue, nor are there obvious disadvantages to the current situation, from what I can tell.

> Plus, they have the impression that this will involve renaming modules and will need modifying curent source code.
>
> It is not about that. Names could remain just as they are, it is only about isolating that part of druntime that is really critical to run the language. As you defined very well, that part that corresponds to java.lang.
>
> There is one thing that bothers me, still, and I did not find the appropriate solution to it: if the language defines threads and garbage collector, I agree the mechanism for those should go in the runtime, but what to do with the function required to handle those? For example, creating a thread is done with a function (not with a keyword!) and the same goes for the GC.disable(), for example.
>
> So, this will kinda break the "runtime means no imports" mantra. Or, otherwise, how to do it? C++ fully accepted its dependency on stdlib when they wen with Threads, isn't?

I don't agree with this mantra, however. It makes sense for internally used functions like _d_throw, but it is fully acceptable IMO to treat some modules under core.* as part of the language that have to be imported when required.

>
> I find it uneasy that one accesses the runtime through "import". Why we should need that? In C you never import/include something for the runtime, nor you have control over it from inside the program. It is through compiler params.

There are some very low-level things for which you have to include header files. varargs for one, setjmp/longjmp, exit()... I would argue that these are parts of the language that happen to be implemented in the standard library (I don't know how exactly the specification treats them, however).

On 2014-08-29 23:00, simendsjo wrote:

> It's still available at dsource: http://www.dsource.org/projects/ares

I don't think he's referring to Ares, he's referring to some other D runtime.

-- 
/Jacob Carlborg

On Friday, 29 August 2014 at 16:37:12 UTC, Sean Kelly wrote:
> 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.

I'm not suggesting we eliminate libc and platform-specific bindings, just encapsulate and isolate them.

To make D work on any platform, druntime must be ported to that platform.  To do the port, of course we have to make platform-specific calls.  That's no problem.  But they should be internally encapsulated in that port's logic, not publicly exposed.  And if we implement 11666 we should isolate each port to its own folder so the abstraction between language and platform is clear.

For example (what druntime may look like many years from now):
If a port chooses to use libc, no problem.  Just encapsulate the bindings in its own file/folder. Don't make it publicly available. If D programmers want bindings to libc in their programs, they should use std.c in phobos (or we could simply move core.stdc to phobos).

This means that we may have duplicate bindings in druntime and std.c for the few features of libc that are required to implement the port.  This isn't really a duplication of code as it should just be type declarations and function signatures - just information for the linker.

Some time in the future, many years from now, it would be nice if gradually those C bindings were replaced with D implementations to throw out the middle-man and put the port directly on the platform.  There's absolutely no hurry, and if it's never done, so be it.

Now what about the stuff in core.sys.whateverOS?  It's the same thing.  Certainly these are needed to port druntime to a given platform, but they are an implementation detail of the port, not the language.  Again they should be encapsulated and isolated.  If users want to make calls to whateverOS libs, than we can either move core.sys.whateverOS to phobos, or create a new namespace std.whateverOS or whatever namespace name you want, and users can use that.  Just get it out of the way of the language implementation.

But NONE of this needs to be done right now, or even this year, or even next year.  All I'm asking for with this thread is that instead of making it harder to move away from the current structure by adding core.stdcpp to druntime, we simply choose to put the C++ standard library bindings in std.cpp in phobos.  Or you could choose to keep it as core.stdcpp, but just put it in phobos instead of druntime.

The C++ standard library bindings don't exist yet.  There's nothing to change.  It's just a design decision.  What do you want druntime to look like in 10 years?  Let's make sure we're pointed in that direction with the C++ standard library bindings.

Mike