Re: core.stdcpp

2014-08-30 Thread eles via Digitalmars-d-announce

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.


Re: core.stdcpp

2014-08-30 Thread via Digitalmars-d-announce

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


Re: core.stdcpp

2014-08-30 Thread Jacob Carlborg via Digitalmars-d-announce

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


Re: core.stdcpp

2014-08-30 Thread Mike via Digitalmars-d-announce

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


Re: core.stdcpp

2014-08-29 Thread Sean Kelly via Digitalmars-d-announce

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.


Re: core.stdcpp

2014-08-29 Thread Sean Kelly via Digitalmars-d-announce

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.


Re: core.stdcpp

2014-08-29 Thread Sean Kelly via Digitalmars-d-announce

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


Re: core.stdcpp

2014-08-29 Thread Walter Bright via Digitalmars-d-announce

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.




Re: core.stdcpp

2014-08-29 Thread Andrei Alexandrescu via Digitalmars-d-announce

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



Re: core.stdcpp

2014-08-29 Thread simendsjo via Digitalmars-d-announce
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:rixtiaiokrukvqjsf...@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


Re: core.stdcpp

2014-08-29 Thread Mike via Digitalmars-d-announce

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 

Re: core.stdcpp

2014-08-27 Thread Walter Bright via Digitalmars-d-announce

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.




Re: core.stdcpp

2014-08-27 Thread Daniel Murphy via Digitalmars-d-announce

eles  wrote in message news:ybcxmuwwpsiyupwer...@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. 



Re: core.stdcpp

2014-08-27 Thread eles via Digitalmars-d-announce

On Wednesday, 27 August 2014 at 07:52:18 UTC, Daniel Murphy wrote:
eles  wrote in message 
news:ybcxmuwwpsiyupwer...@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?


Re: core.stdcpp

2014-08-27 Thread eles via Digitalmars-d-announce

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.


Re: core.stdcpp

2014-08-27 Thread Mike via Digitalmars-d-announce

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.


Re: core.stdcpp

2014-08-27 Thread Mike via Digitalmars-d-announce

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.


Re: core.stdcpp

2014-08-27 Thread Daniel Murphy via Digitalmars-d-announce

eles  wrote in message news:rixtiaiokrukvqjsf...@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. 



Re: core.stdcpp

2014-08-27 Thread deadalnix via Digitalmars-d-announce

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 .


Re: core.stdcpp

2014-08-26 Thread Walter Bright via Digitalmars-d-announce

On 8/25/2014 11:12 PM, Mike wrote:

The C standard library and C++ standard library are not part of D-the-language.
D would even be better served by putting these features in phobos as std.stdc
and std.stdcpp.  This would make them just as conveniently available to users,
and reduce the coupling between the language and the platform.


It's beginning to look more and more like an stdcpp is achievable.

The implementation of it, however, is going to be ugly and very specific to each 
C++ compiler. The user shouldn't need to have to see that ugliness, though.


It also means that implementing stdcpp is going to require someone who is very 
willing to go spelunking around the underbelly of C++ ::std:: and understand it, 
which is a tall order.


Re: core.stdcpp

2014-08-26 Thread Ola Fosheim Gr via Digitalmars-d-announce

On Tuesday, 26 August 2014 at 06:35:18 UTC, Walter Bright wrote:
The implementation of it, however, is going to be ugly and very 
specific to each C++ compiler. The user shouldn't need to have 
to see that ugliness, though.


Sounds easier to write your own ::std:: on the c++ side...


Re: core.stdcpp

2014-08-26 Thread eles via Digitalmars-d-announce

On Tuesday, 26 August 2014 at 06:12:54 UTC, Mike wrote:

On Tuesday, 26 August 2014 at 05:03:01 UTC, Daniel Murphy wrote:
Mike  wrote in message 
news:sdrjfagsayomsngme...@forum.dlang.org...


line between the language and the platform.  Make it a more of 
a language, and less of a framework.


Apparently, all things have this tendency to get bloated. One of 
the main reasons for C's still unbelievable success is its 
slimness.


Re: core.stdcpp

2014-08-26 Thread via Digitalmars-d-announce

On Tuesday, 26 August 2014 at 07:06:57 UTC, eles wrote:
Apparently, all things have this tendency to get bloated. One 
of the main reasons for C's still unbelievable success is its 
slimness.


Yeah, I think C's success is directly linked to having a clear 
use scenario and avoiding being a general purpose language and 
having minimal runtime as the basic philosophy. With a strong 
focus on OS development it was locked to it's roots.


C++ was always perceived as more of an application level 
language, but was sometimes used as a C replacement because of 
convenient inlining and operator overloading. So people use it 
without RTTI, exceptions and ::std:: bloat…


I bet D would have been slimmer if it had been part of a OS 
project, but my gut feeling is that it is more work to slim down 
D than C++.  I think D would greatly benefit from a high level IR 
that  various D dialects could compile to. Then analyse the 
high level IR to determine what the runtime requirements are.


Re: core.stdcpp

2014-08-26 Thread via Digitalmars-d-announce

On Tuesday, 26 August 2014 at 06:12:54 UTC, Mike wrote:
The C standard library and C++ standard library are not part of 
D-the-language.  D would even be better served by putting these 
features in phobos as std.stdc and std.stdcpp.  This would make 
them just as conveniently available to users, and reduce the 
coupling between the language and the platform.


But stdc is its own subpackage in druntime, it's already very 
modular. It should be easy to remove if you want to create a 
minimal druntime. For stdcpp, this will be even more true.


Up until now, Phobos consists of mostly high-level modules, while 
those closer to the OS, and the compiler-dependent parts, reside 
in druntime. I think this is a good division.


Re: core.stdcpp

2014-08-26 Thread Jonathan M Davis via Digitalmars-d-announce
On Tue, 26 Aug 2014 07:00:26 +
Ola Fosheim Gr via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:

 On Tuesday, 26 August 2014 at 06:35:18 UTC, Walter Bright wrote:
  The implementation of it, however, is going to be ugly and very
  specific to each C++ compiler. The user shouldn't need to have
  to see that ugliness, though.

 Sounds easier to write your own ::std:: on the c++ side...

Quite possibly, but then it wouldn't integrate with existing C++ libraries
built with the system's C++ compiler, which would be the point.

- Jonathan M Davis


Re: core.stdcpp

2014-08-26 Thread via Digitalmars-d-announce
On Tuesday, 26 August 2014 at 08:25:58 UTC, Jonathan M Davis via 
Digitalmars-d-announce wrote:
Quite possibly, but then it wouldn't integrate with existing 
C++ libraries

built with the system's C++ compiler, which would be the point.


I know, but the vendor provided C++ libraries could trigger 
compiler-magic in the optimizer, so it might not be enough to 
look at the source code in the general case…


Re: core.stdcpp

2014-08-26 Thread Mike via Digitalmars-d-announce

On Tuesday, 26 August 2014 at 08:15:07 UTC, Marc Schütz wrote:

On Tuesday, 26 August 2014 at 06:12:54 UTC, Mike wrote:
The C standard library and C++ standard library are not part 
of D-the-language.  D would even be better served by putting 
these features in phobos as std.stdc and std.stdcpp.  This 
would make them just as conveniently available to users, and 
reduce the coupling between the language and the platform.


But stdc is its own subpackage in druntime, it's already very 
modular. It should be easy to remove if you want to create a 
minimal druntime. For stdcpp, this will be even more true.


Up until now, Phobos consists of mostly high-level modules, 
while those closer to the OS, and the compiler-dependent parts, 
reside in druntime. I think this is a good division.


My argument isn't about making my own hobby D Runtime.  It's 
about THE D Runtime and more importantly D-the-language (not 
library routines and OS bindings).


There's quite a bit in the D Runtime that's not relevant to the 
language.  I'm guessing it's there because it was convenient at 
the time.  Take a look at the controversy 11666 caused.  It had 
nothing to do with the language or it's portability, and 
everything to do with how to expose the Linux kernel headers.


Just as it is right to separate Phobos from druntime, it is right 
to separate the language from the platform.  It will ensure D's 
longevity and our return on investment for learning and 
contributing to this language.  (You will likely not be 
programming the platform you're currently programming in 5 years)


I'm not interested in Go, Rust, and other application and server 
programming languages.  I want an alternative to C/C++ (and I'm 
not talking about libc, libm, and libcpp, I'm talking about the 
language).


D has a lot of potential beyond it's current use.  Please take 
this opportunity to reflect on what's been done, take a look 
ahead, and see if we can set a better precedent for the future.


Mike


Re: core.stdcpp

2014-08-26 Thread Mike via Digitalmars-d-announce

On Tuesday, 26 August 2014 at 06:35:18 UTC, Walter Bright wrote:

On 8/25/2014 11:12 PM, Mike wrote:
The C standard library and C++ standard library are not part 
of D-the-language.
D would even be better served by putting these features in 
phobos as std.stdc
and std.stdcpp.  This would make them just as conveniently 
available to users,

and reduce the coupling between the language and the platform.


It's beginning to look more and more like an stdcpp is 
achievable.


The implementation of it, however, is going to be ugly and very 
specific to each C++ compiler. The user shouldn't need to have 
to see that ugliness, though.


It also means that implementing stdcpp is going to require 
someone who is very willing to go spelunking around the 
underbelly of C++ ::std:: and understand it, which is a tall 
order.


You must have stopped reading after my first paragraph :)

I seem to have that effect :(


Re: core.stdcpp

2014-08-26 Thread Mike via Digitalmars-d-announce
On Tuesday, 26 August 2014 at 07:56:45 UTC, Ola Fosheim Grøstad 
wrote:

On Tuesday, 26 August 2014 at 07:06:57 UTC, eles wrote:
Yeah, I think C's success is directly linked to having a clear 
use scenario and avoiding being a general purpose language


What? C is THE quintessential general purpose programming 
language.  It can be used to program anything.




Re: core.stdcpp

2014-08-26 Thread via Digitalmars-d-announce

On Tuesday, 26 August 2014 at 10:44:03 UTC, Mike wrote:
On Tuesday, 26 August 2014 at 07:56:45 UTC, Ola Fosheim Grøstad 
wrote:

On Tuesday, 26 August 2014 at 07:06:57 UTC, eles wrote:
Yeah, I think C's success is directly linked to having a clear 
use scenario and avoiding being a general purpose language


What? C is THE quintessential general purpose programming 
language.  It can be used to program anything.


Notice the quotes? :)

C can be used to program anything, but it isn't suitable to 
program everything.




Re: core.stdcpp

2014-08-26 Thread eles via Digitalmars-d-announce
On Tuesday, 26 August 2014 at 07:56:45 UTC, Ola Fosheim Grøstad 
wrote:

On Tuesday, 26 August 2014 at 07:06:57 UTC, eles wrote:



convenient inlining and operator overloading. So people use it


For me, what it would be really nice to have in C from C++ would 
be templates.

And from D, that scope().

I bet D would have been slimmer if it had been part of a OS 
project, but my gut feeling is that it is more work to slim 
down D than C++.  I think D would greatly benefit from a high 
level IR that  various D dialects could compile to. Then 
analyse the high level IR to determine what the runtime 
requirements are.


The problem with starting designing (and implementing) frameworks 
instead of languages is that you have to keep up with everything 
and to never cease expanding. New needs will appear, new 
paradigms (platforms, distributed systems and so on) and you will 
have to play the game.


It is OK to provide extensive standard library, but not put too 
much into the language (and, for me, the druntime shall be seen 
as part of the language, not of the framework).


But, still. Even Java and C# have a separation between the 
language and the framework, more than, for example, Go has.


Re: core.stdcpp

2014-08-26 Thread via Digitalmars-d-announce

On Tuesday, 26 August 2014 at 10:57:10 UTC, eles wrote:
For me, what it would be really nice to have in C from C++ 
would be templates.

And from D, that scope().


When I think about it, I think one of the reasons for going from 
C to C++ in visualization/games was that 3D operations in C are 
unreadable. With operator overloading it got better.


Of course, the C compiler could just have been extended with 
basic arithmetic operators on fixed size arrays… and added SIMDy 
alignment.


I think C was a little late with adding needed features, that 
gave C++ room for marketing itself.


The problem with starting designing (and implementing) 
frameworks instead of languages is that you have to keep up 
with everything and to never cease expanding. New needs will 
appear, new paradigms (platforms, distributed systems and so 
on) and you will have to play the game.


Yep, that is true.

It is OK to provide extensive standard library, but not put too 
much into the language (and, for me, the druntime shall be seen 
as part of the language, not of the framework).


The problem is that once you go for RTTI and GC then the runtime 
is already quite big, so adding one piece to it does not seem 
like a big deal…


I think a language like D is best suited for things that can be 
resolved at compile time than the more dynamic stuff.


I'd rather see whole program analysis and as much static features 
as possible than all the dynamic aspects and the runtime 
requirements that come with it…


That would give the project more focus and make it more suitable 
for real system level programming.


But, still. Even Java and C# have a separation between the 
language and the framework, more than, for example, Go has.


Yes, they compile to a medium level IR.


Re: core.stdcpp

2014-08-26 Thread Daniel Murphy via Digitalmars-d-announce
Ola Fosheim Grøstad  wrote in message 
news:pbfaphgiugafrhach...@forum.dlang.org...


I know, but the vendor provided C++ libraries could trigger compiler-magic 
in the optimizer, so it might not be enough to look at the source code in 
the general case…


I would be very surprised to find a C++ compiler that does this over public 
function boundaries, as it would prevent mixing optimized and unoptimized 
code. 



Re: core.stdcpp

2014-08-26 Thread Daniel Murphy via Digitalmars-d-announce

Mike  wrote in message news:zjscnxerhbxnopvay...@forum.dlang.org...

The C standard library and C++ standard library are not part of 
D-the-language.  D would even be better served by putting these features 
in phobos as std.stdc and std.stdcpp.  This would make them just as 
conveniently available to users, and reduce the coupling between the 
language and the platform.


I really don't see a practical problem with having them in druntime, only a 
philosophical one.  They should still be available when not using phobos, 
and they are used in druntime internally.


I think this is what makes issue 11666[1] so difficult and controversial. 
The features of the C std lib that are needed by the D runtime are not 
many, and could be re-implemented in D. The OS bindings needed to 
implement the D runtime could be internal and moved to a separate folder 
as proposed in the spirit of 11666.  Public OS bindings could be put in 
std.linux, std.windows, etc... along with std.stdc and std.stdcpp.


11666 is contentious because everybody has a different opinion on the 
layout.  This is about personal preferences, and has nothing to do with OS 
bindings being in druntime.  The same exact discussion would happen if they 
were in phobos.


It might be expeditious to just wrap and link, but I argue that D would be 
more appealing as a language (rather than a framework) if this wasn't the 
case.


I get that you're saying this, but why?  How will it make any difference to 
anything ever?  libc is ubiquitous, and the parts that are used internally 
could trivially be reimplemented on a platform where it was missing.  (or 
more likely, it could just be ported)


I concede this is true for the vast majority of systems out there, but it 
makes D an applications programming framework, not a systems programming 
language.


???  If you want to / need to, you can write a libc implementation 
in D.  The fact that the major D platforms all choose to link against the 
system libc instead of rolling their own has no bearing on the language 
class of D.  The fact that druntime includes a prototype for memcpy or fopen 
does not change anything either.  It just makes D more convenient for 
porting C code.


I politely ask those pursuing core.stdcpp to reconsider and look further 
in the future.  Please think beyond desktop and server application 
programming.  Consider what D could be used for, not just what it is 
currently used for, and darken the line between the language and the 
platform.  Make it a more of a language, and less of a framework.


It could be my failing, but I really don't see the point.  What are the 
potential consequences of maintaining and extending the C, C++ and OS 
bindings in druntime? 



Re: core.stdcpp

2014-08-26 Thread via Digitalmars-d-announce

On Tuesday, 26 August 2014 at 12:23:18 UTC, Daniel Murphy wrote:
I would be very surprised to find a C++ compiler that does this 
over public function boundaries, as it would prevent mixing 
optimized and unoptimized code.


Probably, at least without whole-program optimization turned on.

But you still have to track compiler version changelogs and then 
deal with possibly multiple D implementations just fro one 
compiler. I guess it can work out if you limit yourselves to just 
std::vector and std::string…


This idea would have a more merit if DMD was 100% LLVM based and 
focused on one architecture… Doing this for many compilers on 
many architectures sounds like versioning hell.


Re: core.stdcpp

2014-08-26 Thread Daniel Murphy via Digitalmars-d-announce
Ola Fosheim Grøstad  wrote in message 
news:mclztlymyjydwhcxs...@forum.dlang.org...



Probably, at least without whole-program optimization turned on.


Linking with D is not a concern for whole-program-optimized C++ programs.

But you still have to track compiler version changelogs and then deal with 
possibly multiple D implementations just fro one compiler. I guess it can 
work out if you limit yourselves to just std::vector and std::string…


Yes, it's a pain.  I've done it with one templated struct inside DDMD, and 
that was a pain.  I don't know if it will work sufficiently for mapping to 
stl, but it's worth a try.


It's usually easier to test with multiple versions and manually determine 
differences when problems arise.  Changelogs often do not cover anything 
more than API changes, especially with some vendors.


This idea would have a more merit if DMD was 100% LLVM based and focused 
on one architecture… Doing this for many compilers on many architectures 
sounds like versioning hell.


It would be easier, but I don't think it changes the merit of the idea. 
Matching calling conventions is a much more difficult problem (in dmd's 
backend at least) and yet interoperability is so useful that it's 
worthwhile. 



Re: core.stdcpp

2014-08-26 Thread Mike via Digitalmars-d-announce
On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei Alexandrescu 
wrote:

On 8/26/14, 3:06 AM, Mike wrote:
D has a lot of potential beyond it's current use.  Please take 
this
opportunity to reflect on what's been done, take a look ahead, 
and see

if we can set a better precedent for the future.


C++ interoperability is very important for D's future. -- Andrei


I know it is and I fully support it.  I'm not arguing against it. 
 Please add all C++ interoperability support you want to the 
compiler and to druntime.  I look forward to making use of it.


But libstdc++ is not part of C++-the-language, and libc is not 
part of C-the-language.  C and C++ can be used without them; I do 
every day.


If core.stdcpp is intended to be the language bindings to 
libstdc++, I don't think it should belong it D's language 
implementation, druntime, any more the language bindings to Cairo 
or GTK should.


The same goes for core.stdc and core.sys.linux and friends, as 
these are not part of D's language implementation.


Mike


Re: core.stdcpp

2014-08-26 Thread eles via Digitalmars-d-announce

On Tuesday, 26 August 2014 at 15:30:35 UTC, Mike wrote:
On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei Alexandrescu 
wrote:

On 8/26/14, 3:06 AM, Mike wrote:


The same goes for core.stdc and core.sys.linux and friends, as 
these are not part of D's language implementation.


Am I correct to define the language as:

begin file---
//no imports here

//any code here
-

?

If you import, then is the library.



Re: core.stdcpp

2014-08-26 Thread Mike via Digitalmars-d-announce

On Tuesday, 26 August 2014 at 12:54:49 UTC, Daniel Murphy wrote:

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.



They should still be available when not using phobos,


Then they can be put in their own library instead of phobos.  
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.



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.


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.


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)


11666 is contentious because everybody has a different opinion 
on the layout.  This is about personal preferences, and has 
nothing to do with OS bindings being in druntime.  The same 
exact discussion would happen if they were in phobos.


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.


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.


I get that you're saying this, but why?  How will it make any 
difference to anything ever?  libc is ubiquitous, and the parts 
that are used internally could trivially be reimplemented on a 
platform where it was missing.  (or more likely, it could just 
be ported)


Or those features in libc could be implemented in D, removing the 
artificial dependency on libc.


???  If you want to / need to, you can write a libc 
implementation in D.  The fact that the major D platforms all 
choose to link against the system libc instead of rolling their 
own has no bearing on the language class of D.  The fact that 
druntime includes a prototype for memcpy or fopen does not 
change anything either.  It just makes D more convenient for 
porting C code.


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.


It could be my failing, but I really don't see the point.  What 
are the potential consequences of maintaining and extending the 
C, C++ and OS bindings in druntime?


* It conflates the language with the platform.  druntime should 
be solely the implementation of the language, not an OS API.
* It conflates the implementation of the language with bindings 
for external libraries. Again, druntime is the language 
implementation, not 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.
* 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.
* It gets in the way of porting the language to more platforms 
and complicates maintenance of the runtime. Case in point: the 
11666 debate.
* It makes D unportable to some platforms without creating their 
own dialect of the language or their own D runtime implementation


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.


Mike


Re: core.stdcpp

2014-08-26 Thread Mike via Digitalmars-d-announce

On Tuesday, 26 August 2014 at 15:44:31 UTC, eles wrote:

On Tuesday, 26 August 2014 at 15:30:35 UTC, Mike wrote:
On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei 
Alexandrescu wrote:

On 8/26/14, 3:06 AM, Mike wrote:


The same goes for core.stdc and core.sys.linux and friends, as 
these are not part of D's language implementation.


Am I correct to define the language as:

begin file---
//no imports here

//any code here
-

?

If you import, then is the library.


That may be an oversimplification, but basically, Yes.


Re: core.stdcpp

2014-08-26 Thread eles via Digitalmars-d-announce

On Tuesday, 26 August 2014 at 18:13:01 UTC, eles wrote:

On Tuesday, 26 August 2014 at 17:09:58 UTC, Walter Bright wrote:

On 8/26/2014 8:30 AM, Mike wrote:


wow. I remember the hot debate about the name o the standard 
library back then.


well, namesace name


Re: core.stdcpp

2014-08-26 Thread eles via Digitalmars-d-announce

On Tuesday, 26 August 2014 at 17:09:58 UTC, Walter Bright wrote:

On 8/26/2014 8:30 AM, Mike wrote:


Regardless of where stdcpp goes, one issue is that the stuff in 
it goes into the namespace std, which conflicts with Phobos' 
std higher level package name.


wow. I remember the hot debate about the name o the standard 
library back then.


Remember proposition dsl (D standard library) anyone?

and your (sad) comment: Nobody likes phobos :)


Re: core.stdcpp

2014-08-26 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 8/26/14, 8:30 AM, Mike wrote:

On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei Alexandrescu wrote:

On 8/26/14, 3:06 AM, Mike wrote:

D has a lot of potential beyond it's current use.  Please take this
opportunity to reflect on what's been done, take a look ahead, and see
if we can set a better precedent for the future.


C++ interoperability is very important for D's future. -- Andrei


I know it is and I fully support it.  I'm not arguing against it.
  Please add all C++ interoperability support you want to the compiler
and to druntime.  I look forward to making use of it.


Great.


But libstdc++ is not part of C++-the-language, and libc is not part of
C-the-language.  C and C++ can be used without them; I do every day.

If core.stdcpp is intended to be the language bindings to libstdc++, I
don't think it should belong it D's language implementation, druntime,
any more the language bindings to Cairo or GTK should.

The same goes for core.stdc and core.sys.linux and friends, as these are
not part of D's language implementation.


I don't understand the objection. Are you arguing that we shouldn't make 
core.stdc and core.stdcpp available, and instead let anyone who wants to 
use libc and libc++ write their own declarations?



Andrei




Re: core.stdcpp

2014-08-26 Thread Daniel Murphy via Digitalmars-d-announce

Mike  wrote in message news:bkkdiikafdsraqssj...@forum.dlang.org...

 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 

Re: core.stdcpp

2014-08-26 Thread eles via Digitalmars-d-announce

On Tuesday, 26 August 2014 at 17:09:58 UTC, Walter Bright wrote:

On 8/26/2014 8:30 AM, Mike wrote:


There's never going to be a clear distinction between druntime 
and phobos. The original reason for the split anyway was  
druntime would be a


Well, in C there is and I like that distinction: the runtime 
handles everything that doesn't need a #include, and that is:


- formatting and passing the arguments to main()
- replacing some constants (IIRC) at runtime, especially those 
with sizeof(array)


While the distinction between druntime and phobos is one thing 
(and you are right that it was about Tango vs Phobos, because 
otherwise Tango was reimplementing those parts in a 
Phobos-incompatible ways, which prevented programs to use both), 
now the discussion is more about (c-like) runtime vs (c-like) 
standard library.


Re: core.stdcpp

2014-08-26 Thread eles via Digitalmars-d-announce

On Tuesday, 26 August 2014 at 18:33:07 UTC, Daniel Murphy wrote:
Mike  wrote in message 
news:bkkdiikafdsraqssj...@forum.dlang.org...


 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 

Re: core.stdcpp

2014-08-26 Thread Daniel Murphy via Digitalmars-d-announce

eles  wrote in message news:qrfucjdbmydvoqgey...@forum.dlang.org...

While this might be acceptable, there is one more question: what use to 
have the druntime separated from phobos, in this case?


Apart from the fact that it's too late to change of course.

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.


Druntime and phobos both had c/OS bindings at some point (core.stdc + std.c) 
but duplication is bad, so they were/are being moved into druntime.


In druntime you have the true, hidden runtime code (startup, profiler, 
coverage, unittesting, AAs), plus core language stuff (GC, Thread 
(+core.time)).


Phobos is supposed to be 100% optional, although it isn't, quite.  If you 
don't want to use phobos, for example if you are automatically porting a 
large C++ application, it's nice to simply ban phobos and have that clear 
distinction. 



Re: core.stdcpp

2014-08-26 Thread eles via Digitalmars-d-announce

On Tuesday, 26 August 2014 at 19:22:22 UTC, Daniel Murphy wrote:
eles  wrote in message 
news:qrfucjdbmydvoqgey...@forum.dlang.org...



Apart from the fact that it's too late to change of course.


Well, that separation is just a detail of the implementation, not 
of the specification. You could simply say that phobos has 
several namespaces: std, etc, core.


Druntime and phobos both had c/OS bindings at some point 
(core.stdc + std.c) but duplication is bad, so they were/are 
being moved into druntime.


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


In druntime you have the true, hidden runtime code (startup, 
profiler, coverage, unittesting, AAs), plus core language stuff 
(GC, Thread (+core.time)).


_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)


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


Phobos is supposed to be 100% optional, although it isn't, 
quite.  If you don't want to use phobos, for example if you are 
automatically porting a large C++ application, it's nice to 
simply ban phobos and have that clear distinction.


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.


Re: core.stdcpp

2014-08-26 Thread Mike via Digitalmars-d-announce
On Tuesday, 26 August 2014 at 18:28:38 UTC, Andrei Alexandrescu 
wrote:


I don't understand the objection. Are you arguing that we 
shouldn't make core.stdc and core.stdcpp available, and instead 
let anyone who wants to use libc and libc++ write their own 
declarations?


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


Why?  D is not subset of C.  D is not defined in C.  It is its 
own autonomous language (at least I though it was).  Therefore, 
the dependencies on libc are artificial.  Let's not add another 
artificial dependency with core.stdcpp.  The OS bindings in 
core.sys are another artificial dependency, but let's not go 
there right now.


But druntime relies on libc?  Wrong! Some of the code needed to 
port druntime to certain platforms relies on libc (and actually 
doesn't need to).  This code should be encapsulated and isolated 
from other ports, not publicly exposed and conflated with the 
rest of the language implementation.  This is in the spirit of 
issue 11666.


I believe druntime's scope should be reduced to simply 
implementing the language, not creating an OS or library API.  
That's what phobos and DUB are for.


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.


Mike


Re: core.stdcpp

2014-08-26 Thread Mike via Digitalmars-d-announce

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.




... and start by creating std.cpp instead of core.stdcpp.



Re: core.stdcpp

2014-08-26 Thread Dicebot via Digitalmars-d-announce

On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote:
I believe druntime's scope should be reduced to simply 
implementing the language, not creating an OS or library API.  
That's what phobos and DUB are for.


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.


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.


Re: core.stdcpp

2014-08-26 Thread deadalnix via Digitalmars-d-announce

On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei Alexandrescu
wrote:

On 8/26/14, 3:06 AM, Mike wrote:
D has a lot of potential beyond it's current use.  Please take 
this
opportunity to reflect on what's been done, take a look ahead, 
and see

if we can set a better precedent for the future.


C++ interoperability is very important for D's future. -- Andrei


I think this cannot be understated. People have existing codebase
that they aren't going to rewrite from scratch.


Re: core.stdcpp

2014-08-26 Thread Mike via Digitalmars-d-announce

On Wednesday, 27 August 2014 at 01:05:19 UTC, Dicebot wrote:

On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote:
I believe druntime's scope should be reduced to simply 
implementing the language, not creating an OS or library API.  
That's what phobos and DUB are for.


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.


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?


Re: core.stdcpp

2014-08-26 Thread Dicebot via Digitalmars-d-announce

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.


Re: core.stdcpp

2014-08-26 Thread deadalnix via Digitalmars-d-announce

On Wednesday, 27 August 2014 at 01:21:59 UTC, deadalnix wrote:
I think this cannot be understated. People have existing 
codebase

that they aren't going to rewrite from scratch.


PS: This is the reason why SDC unwind C++'s exception properly
(but you obviously can't catch them).


Re: core.stdcpp

2014-08-26 Thread Mike via Digitalmars-d-announce

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.


Since C++ language bindings are a new addition, let's not 
exacerbate the problem by putting it in druntime as core.stdcpp, 
but set a new precedent by putting them in std.cpp (or 
core.stdcpp in phobos, or whatever else you have in mind).


Mike


Re: core.stdcpp

2014-08-26 Thread eles via Digitalmars-d-announce

On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote:
On Tuesday, 26 August 2014 at 18:28:38 UTC, Andrei Alexandrescu 
wrote:



No. We currently have std.c and core.stdc.


Let's not even say this is confusing.