www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D as A Better C?

reply Walter Bright <newshound2 digitalmars.com> writes:
I've toyed with this idea for a while, and wondered what the interest there is 
in something like this.

The idea is to be able to use a subset of D that does not require any of 
druntime or phobos - it can be linked merely with the C standard library. To 
that end, there'd be a compiler switch (-betterC) which would enforce the
subset.

(First off, I hate the name "better C", any suggestions?)

The subset would disallow use of any features that rely on:

1. moduleinfo
2. exception handling
3. gc
4. Object

I've used such a subset before when bringing D up on a new platform, as the new 
platform didn't have a working phobos.

What do you think?
Feb 11 2014
next sibling parent "Meta" <jared771 gmail.com> writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 I've toyed with this idea for a while, and wondered what the 
 interest there is in something like this.

 The idea is to be able to use a subset of D that does not 
 require any of druntime or phobos - it can be linked merely 
 with the C standard library. To that end, there'd be a compiler 
 switch (-betterC) which would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new 
 platform, as the new platform didn't have a working phobos.

 What do you think?

It'd probably be good for embedded programming, but this looks almost like a different language to me... I don't know if such fragmentation is a good idea (though I suppose we do already have the -betterC switch).
Feb 11 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 11 Feb 2014 14:43:02 -0500, Walter Bright  
<newshound2 digitalmars.com> wrote:

 I've toyed with this idea for a while, and wondered what the interest  
 there is in something like this.

 The idea is to be able to use a subset of D that does not require any of  
 druntime or phobos - it can be linked merely with the C standard  
 library. To that end, there'd be a compiler switch (-betterC) which  
 would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

-cruntime
 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new platform, as  
 the new platform didn't have a working phobos.

 What do you think?

I think it is a very good idea. I think an allocator that wraps malloc would be appropriate at least, since malloc calls are so clunky and verbose. -Steve
Feb 11 2014
prev sibling next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 What do you think?

I think it would have little benefit and would just lead to pointless fragmentation and maintenance for the compiler devs.
Feb 11 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/11/2014 12:53 PM, Steven Schveighoffer wrote:
 I think you overestimate the size of this project.

I agree it's not a big deal. It's just implementing a switch that disables a list of features. The switch even already exists, though it is incomplete. The payoff is the embedded market is huge, and this can greatly expand D's presence in the marketplace.
Feb 11 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/14, 1:10 PM, Walter Bright wrote:
 On 2/11/2014 12:53 PM, Steven Schveighoffer wrote:
 I think you overestimate the size of this project.

I agree it's not a big deal. It's just implementing a switch that disables a list of features. The switch even already exists, though it is incomplete. The payoff is the embedded market is huge, and this can greatly expand D's presence in the marketplace.

It's yet another opportunity to waste focus. (But then it goes to prove that everybody does what they want...) Andrei
Feb 11 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/11/2014 1:13 PM, Peter Alexander wrote:
 And how do people find out about this language? Won't it need to be documented
 on the website? Where does that come from?

It'll be documented on the website.
 Will this be a separate project,

No. It's nothing more than a switch to the compiler. No separate project.
 If it's the same project, who fixes
 the bugs when a runtime hook is accidentally introduced by a dev that forgot
 better C existed?

A bugzilla entry, just as now. No change in procedure.
 Who manages the releases of better C?

No difference, it would not be separately released.
 Remember, D1 was just D2 without a bunch of features and we had to discontinue
 that because it was taking too much time to maintain. How will this be
different?

It won't be a separate project or a separate codebase.
Feb 11 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/11/2014 1:28 PM, Peter Alexander wrote:
 Is it really worth taking effort away from D2 when so much is left to do there?

The "worth it" issue is does it expand the user base of D relative to the effort? I'd say yes.
Feb 11 2014
prev sibling parent 1100110 <0b1100110 gmail.com> writes:
On 2/11/14, 15:44, Vladimir Panteleev wrote:
 On Tuesday, 11 February 2014 at 21:28:15 UTC, Peter Alexander wrote:
 On Tuesday, 11 February 2014 at 21:22:40 UTC, Walter Bright wrote:
 snip

Thank you, so this project would need to be maintained alongside D2 development, just like D1 was. Is it really worth taking effort away from D2 when so much is left to do there?

A few if() blocks and some code to parse a command-line option is hardly a "project" that needs to be "maintained alongside D2 development". However, I agree that there are better things the core compiler maintainers could do with their time. I think such a switch would be easy enough to implement and maintain by whoever needs it.

It does overlap with another suggestion however, the no gc crowd and -nogc. I'd think if you can disable gc through -betterC, then it would be trivial to satisfy the no gc crowd as well. Bu then again I don't really know.
Feb 12 2014
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/14, 12:47 PM, Peter Alexander wrote:
 On Tuesday, 11 February 2014 at 20:02:37 UTC, Frustrated wrote:
 On Tuesday, 11 February 2014 at 19:56:11 UTC, Peter Alexander
 wrote:
 On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 What do you think?

I think it would have little benefit and would just lead to pointless fragmentation and maintenance for the compiler devs.

Do you program on embedded systems? If not then do you think you are qualified to say it would have little benefit or not?

I do program on embedded systems. I'll elaborate more on why I think this is a bad idea. First, we are struggling immensely as it is to get D2 into a complete state. Many parts of the language are still poorly defined and even more poorly implemented. The standard library is still lacking in critical areas and there are still thousands of non-trivial bugs in the database. The language itself is still evolving rapidly. Speaking optimistically, I think we are still a few years away from resolving the existing language issues, based on the current pace of things. We're heading in the right direction now and even accelerating, but I think it would be incredibly unwise to embark on a new side-project, which would just consume dev time, pulling effort away from D2 development. D1 was discontinued to spend more time on D2, not to start new projects of debatable benefit. Please let's finish this language before we start on another.

I agree. Walter, let's put that on the backburner. Thanks. Andrei
Feb 11 2014
prev sibling next sibling parent reply "Frustrated" <c1514843 drdrb.com> writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 I've toyed with this idea for a while, and wondered what the 
 interest there is in something like this.

 The idea is to be able to use a subset of D that does not 
 require any of druntime or phobos - it can be linked merely 
 with the C standard library. To that end, there'd be a compiler 
 switch (-betterC) which would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new 
 platform, as the new platform didn't have a working phobos.

 What do you think?

I think the concept is great but a bit limiting if not properly done. First: D should have a core language subset that is essentially what you describe above. This allows it to be used at a lower level. Call it embedded D if you want. Other names: D core, D*, D lite, D-, Dm, D, D^c(D with a c superscript = D core), etc... Then the D we have now will be the "Closure" of the core. Basically add in all the "cool stuff". All the static compiler features(Templates, mixins, unit tests, etc...) should be included in both because those are partly what make D better than C and would actually be very cool to have on some embedded systems(and the fact that D supports asm makes it even cooler). The language spec should be divided into the Static(templates, etc...), Core, and "Closure"(since I don't have a better term). The GC, should be completely independent though and part of a memory management system that could be used in the core possibly(plug and play)... not really part of the language spec.
Feb 11 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/11/2014 12:56 PM, Brad Anderson wrote:
 How'd you overlook D--? :P

From a positioning perspective, having a "less" implication is not good.
Feb 11 2014
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/14, 12:56 PM, Brad Anderson wrote:
 On Tuesday, 11 February 2014 at 19:59:26 UTC, Frustrated wrote:
 D should have a core language subset that is essentially what you
 describe above. This allows it to be used at a lower level. Call
 it embedded D if you want. Other names:

 D core, D*, D lite, D-, Dm,  D, D^c(D with a c superscript = D
 core), etc...

How'd you overlook D--? :P

No new name please. It would be among the worst things to do right now. Andrei
Feb 11 2014
prev sibling next sibling parent "Frustrated" <c1514843 drdrb.com> writes:
On Tuesday, 11 February 2014 at 19:56:11 UTC, Peter Alexander
wrote:
 On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright 
 wrote:
 What do you think?

I think it would have little benefit and would just lead to pointless fragmentation and maintenance for the compiler devs.

Do you program on embedded systems? If not then do you think you are qualified to say it would have little benefit or not? Obviously if all you ever drink is milk then water, coffee, coke, etc.. have little benefit for you. It clearly does not mean all those other things are useless to everyone else. If done properly it would actually enhance D development by partitioning it into sections while also providing a foundation for D while expanding it's user base.
Feb 11 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Tue, 11 Feb 2014 11:43:02 -0800, Walter Bright  
<newshound2 digitalmars.com> wrote:

 I've toyed with this idea for a while, and wondered what the interest  
 there is in something like this.

 The idea is to be able to use a subset of D that does not require any of  
 druntime or phobos - it can be linked merely with the C standard  
 library. To that end, there'd be a compiler switch (-betterC) which  
 would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new platform, as  
 the new platform didn't have a working phobos.

 What do you think?

I see this as a very good idea. It would make bootstrapping the language to new architectures or compiler backends much simpler. It would make the embedded/real-time folks happy. Then we could use that subset to create a Phobos-Core subset that worked on D-Core and could be trivially ported onto any new platform that has the C standard library. I don't see the complexity argument as relevant. If properly designed such that the Core has absolutely no requirement on higher level features then all you're doing is building the higher level features on the "library" of Core features. We all do this kind of thing every day. :-) -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Feb 11 2014
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11-Feb-2014 23:43, Walter Bright пишет:
 I've toyed with this idea for a while, and wondered what the interest
 there is in something like this.

 The idea is to be able to use a subset of D that does not require any of
 druntime or phobos - it can be linked merely with the C standard
 library. To that end, there'd be a compiler switch (-betterC) which
 would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new platform, as
 the new platform didn't have a working phobos.

 What do you think?

I kind of like it. What about TLS? Would make a nice subset for embedded programming. Obviously needs its own library (friendlier memory allocation etc.), preferably later on integrated as a subset of Phobos. -- Dmitry Olshansky
Feb 11 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/11/2014 12:37 PM, Dmitry Olshansky wrote:
 I kind of like it. What about TLS?

TLS would be dependent on whether the target system supported it for C or not.
 Would make a nice subset for embedded programming. Obviously needs its own
 library (friendlier memory allocation etc.), preferably later on integrated as
a
 subset of Phobos.

The idea is it would not require any library other than the C runtime.
Feb 11 2014
prev sibling parent "Steve Teale" <steve.teale britseyeview.com> writes:
On Tuesday, 11 February 2014 at 21:13:56 UTC, Walter Bright wrote:
 On 2/11/2014 12:37 PM, Dmitry Olshansky wrote:

 The idea is it would not require any library other than the C 
 runtime.

This somehow reminds me of the first C++ compiler, which generated C. I quite like the idea. Steve
Feb 12 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 (First off, I hate the name "better C", any suggestions?)

A different name is needed.
 What do you think?

It must produce very small binaries. If you import anything from Phobos it will not work in most cases, even if the feature you are importing does not require GC, druntime, etc, because in most cases other parts of the Phobos module use them. Is this going to cause a fragmentation of Phobos? What to do with dynamic array literals? In many cases they allocate. A partial solution is to use the [...]s syntax for fixed size array literals. Constant associative arrays at global scope don't need the GC, but they need the druntime, so I guess they too need to be disallowed. Bye, bearophile
Feb 11 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Manu" <turkeyman gmail.com> wrote in message 
news:mailman.20.1392172483.6445.digitalmars-d puremagic.com...
On 12 February 2014 09:06, Mike <none none.com> wrote:

On Tuesday, 11 February 2014 at 20:42:26 UTC, bearophile wrote:
Walter Bright:

(First off, I hate the name "better C", any suggestions?)

A different name is needed.

 I don't think a different name is needed, nor do I think it would be a 
 good idea.  All
 that's needed are a few compiler switches to enable/disable features so 
 D can be
 used on more platforms.  GNU g++ does this without giving it a new name 
 (e.g. -fno-
 exceptions, -fno-rtti, etc...)  D can do the same without giving it a 
 new name.

+1, I support this approach. C/C++ programmers are familiar with it, and I can imagine situations where I might want some features, but not others.

Having one switch does not prevent having finer-grained switches too.
Feb 11 2014
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Tuesday, 11 February 2014 at 20:02:37 UTC, Frustrated wrote:
 On Tuesday, 11 February 2014 at 19:56:11 UTC, Peter Alexander
 wrote:
 On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright 
 wrote:
 What do you think?

I think it would have little benefit and would just lead to pointless fragmentation and maintenance for the compiler devs.

Do you program on embedded systems? If not then do you think you are qualified to say it would have little benefit or not?

I do program on embedded systems. I'll elaborate more on why I think this is a bad idea. First, we are struggling immensely as it is to get D2 into a complete state. Many parts of the language are still poorly defined and even more poorly implemented. The standard library is still lacking in critical areas and there are still thousands of non-trivial bugs in the database. The language itself is still evolving rapidly. Speaking optimistically, I think we are still a few years away from resolving the existing language issues, based on the current pace of things. We're heading in the right direction now and even accelerating, but I think it would be incredibly unwise to embark on a new side-project, which would just consume dev time, pulling effort away from D2 development. D1 was discontinued to spend more time on D2, not to start new projects of debatable benefit. Please let's finish this language before we start on another.
Feb 11 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 11 Feb 2014 15:47:12 -0500, Peter Alexander  
<peter.alexander.au gmail.com> wrote:

 I do program on embedded systems.

 I'll elaborate more on why I think this is a bad idea.

 First, we are struggling immensely as it is to get D2 into a complete  
 state. Many parts of the language are still poorly defined and even more  
 poorly implemented. The standard library is still lacking in critical  
 areas and there are still thousands of non-trivial bugs in the database.  
 The language itself is still evolving rapidly. Speaking optimistically,  
 I think we are still a few years away from resolving the existing  
 language issues, based on the current pace of things.

But the feature would be very simple to implement. You just avoid outputting any runtime type info, and avoid any compiler hooks into the runtime. There is no requirement to do anything else. The language is finished. C's standard library becomes the standard library.
 We're heading in the right direction now and even accelerating, but I  
 think it would be incredibly unwise to embark on a new side-project,  
 which would just consume dev time, pulling effort away from D2  
 development. D1 was discontinued to spend more time on D2, not to start  
 new projects of debatable benefit.

 Please let's finish this language before we start on another.

I think you overestimate the size of this project. -Steve
Feb 11 2014
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 11.02.2014 20:43, schrieb Walter Bright:
 I've toyed with this idea for a while, and wondered what the interest
 there is in something like this.

 The idea is to be able to use a subset of D that does not require any of
 druntime or phobos - it can be linked merely with the C standard
 library. To that end, there'd be a compiler switch (-betterC) which
 would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new platform, as
 the new platform didn't have a working phobos.

 What do you think?

That looks a nice idea. Yeah, "better C" is already owned by C++. :) -- Paulo
Feb 11 2014
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 11 February 2014 at 19:59:26 UTC, Frustrated wrote:
 D should have a core language subset that is essentially what 
 you
 describe above. This allows it to be used at a lower level. Call
 it embedded D if you want. Other names:

 D core, D*, D lite, D-, Dm,  D, D^c(D with a c superscript = D
 core), etc...

How'd you overlook D--? :P
Feb 11 2014
prev sibling next sibling parent reply "Brian Rogoff" <brogoff gmail.com> writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 I've toyed with this idea for a while, and wondered what the 
 interest there is in something like this.

 The idea is to be able to use a subset of D that does not 
 require any of druntime or phobos - it can be linked merely 
 with the C standard library. To that end, there'd be a compiler 
 switch (-betterC) which would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new 
 platform, as the new platform didn't have a working phobos.

 What do you think?

Which D metaprogramming (templates, mixins, ctfe, ..) features would be in this D subset? Would the non-gc'ed functional programming features (downward funargs) be in the subset? If the answers are "all and yes" I'd be very interested, if "none and no" then much less interested. Please say more about which features you expect to make the cut. D-lite, while already used, is the natural name choiec. As others point out, there's some risk of fragmentation, but there's precedent even in unsubsettable languages like Ada (SPARK) so I don't think the risk is so great. -- Brian
Feb 11 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/11/2014 1:00 PM, Brian Rogoff wrote:
 Which D metaprogramming (templates, mixins, ctfe, ..) features would be in this
 D subset?

All of them.
 Would the non-gc'ed functional programming features (downward funargs) be in
the
 subset?

All of them.
 If the answers are "all and yes" I'd be very interested, if "none and no" then
 much less interested. Please say more about which features you expect to make
 the cut.

Associative arrays would not, as they rely on the GC. It would require support for COMDATs from the linker, while C does not. Fortunately, C++ adoption has pretty much driven COMDAT support into all the linkers that matter.
 D-lite, while already used, is the natural name choiec.

Cute names are amusing for a few seconds, but they get old real fast.
 As others point out, there's some risk of fragmentation, but there's precedent
 even in unsubsettable languages like Ada (SPARK) so I don't think the risk is
so
 great.

There's also precedent in C itself, as the C Standard codifies the notion of a "freestanding" implementation of C, although that's not quite what we're talking about here. Freestanding means no C runtime library, either.
Feb 11 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Nicolas Sicard"  wrote in message 
news:pvmgtktejwykqpibzvjc forum.dlang.org...
 Which D metaprogramming (templates, mixins, ctfe, ..) features would be 
 in this
 D subset?

All of them.

And would all of D features be available at compile time? CTFE/string mixins seem to be rather limited if features relying on the GC are excluded.

Yes. The limits would only apply to things used at runtime.
Feb 12 2014
prev sibling next sibling parent "Tove" <tove fransson.se> writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 I've toyed with this idea for a while, and wondered what the 
 interest there is in something like this.

 The idea is to be able to use a subset of D that does not 
 require any of druntime or phobos - it can be linked merely 
 with the C standard library. To that end, there'd be a compiler 
 switch (-betterC) which would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new 
 platform, as the new platform didn't have a working phobos.

 What do you think?

It's a Delightful(dlite?) idea, I long considered doing something like this as it would facilitate using D at work.
Feb 11 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/11/2014 11:43 AM, Walter Bright wrote:
 (First off, I hate the name "better C", any suggestions?)

How about "EmbeddedD", though that wouldn't be entirely accurate?
Feb 11 2014
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 11 Feb 2014 16:11:19 -0500, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 2/11/2014 11:43 AM, Walter Bright wrote:
 (First off, I hate the name "better C", any suggestions?)

How about "EmbeddedD", though that wouldn't be entirely accurate?

Sorry, WAAAY too many D's :) -Steve
Feb 11 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/11/2014 1:53 PM, Steven Schveighoffer wrote:
 On Tue, 11 Feb 2014 16:11:19 -0500, Walter Bright <newshound2 digitalmars.com>
 How about "EmbeddedD", though that wouldn't be entirely accurate?

Sorry, WAAAY too many D's :)

That's a Good Thing (tm), isn't it?
Feb 11 2014
prev sibling next sibling parent "Francesco Cattoglio" <francesco.cattoglio gmail.com> writes:
On Tuesday, 11 February 2014 at 21:53:42 UTC, Steven 
Schveighoffer wrote:
 On Tue, 11 Feb 2014 16:11:19 -0500, Walter Bright 
 <newshound2 digitalmars.com> wrote:

 On 2/11/2014 11:43 AM, Walter Bright wrote:
 (First off, I hate the name "better C", any suggestions?)

How about "EmbeddedD", though that wouldn't be entirely accurate?

Sorry, WAAAY too many D's :) -Steve

Feb 11 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 11 Feb 2014 16:54:56 -0500, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 2/11/2014 1:53 PM, Steven Schveighoffer wrote:
 On Tue, 11 Feb 2014 16:11:19 -0500, Walter Bright  
 <newshound2 digitalmars.com>
 How about "EmbeddedD", though that wouldn't be entirely accurate?

Sorry, WAAAY too many D's :)

That's a Good Thing (tm), isn't it?

Not sure. That last D looks like a typo... -Steve
Feb 11 2014
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Tuesday, 11 February 2014 at 21:11:15 UTC, Walter Bright wrote:
 On 2/11/2014 11:43 AM, Walter Bright wrote:
 (First off, I hate the name "better C", any suggestions?)

How about "EmbeddedD", though that wouldn't be entirely accurate?

-metal
Feb 11 2014
prev sibling next sibling parent reply "Mike" <none none.com> writes:
On Tuesday, 11 February 2014 at 21:11:15 UTC, Walter Bright wrote:
 On 2/11/2014 11:43 AM, Walter Bright wrote:
 (First off, I hate the name "better C", any suggestions?)

How about "EmbeddedD", though that wouldn't be entirely accurate?

I program ONLY embedded systems in D and I very much dislike the idea of introducing a new name. There should be only one D , but there's no reason features couldn't be enabled/disabled with compiler switches (-fno-exceptions, -fno-rtti) There's no reason to aggregate compiler switches into a single name. I f users want no exceptions, no gc, no objects, etc... then they should add -fno-exceptions, -fno-gc, -fno-objects, etc... to their compiler flags. Please, I beg you! No new names. Please don't fragment the language. Just make it a little more modular. Mike
Feb 11 2014
parent 1100110 <0b1100110 gmail.com> writes:
On 2/11/14, 17:15, Mike wrote:
 On Tuesday, 11 February 2014 at 21:11:15 UTC, Walter Bright wrote:
 On 2/11/2014 11:43 AM, Walter Bright wrote:
 (First off, I hate the name "better C", any suggestions?)

How about "EmbeddedD", though that wouldn't be entirely accurate?

I program ONLY embedded systems in D and I very much dislike the idea of introducing a new name. There should be only one D , but there's no reason features couldn't be enabled/disabled with compiler switches (-fno-exceptions, -fno-rtti) There's no reason to aggregate compiler switches into a single name. I f users want no exceptions, no gc, no objects, etc... then they should add -fno-exceptions, -fno-gc, -fno-objects, etc... to their compiler flags. Please, I beg you! No new names. Please don't fragment the language. Just make it a little more modular. Mike

I agree, if this is strictly restricting the language to a core subset, then I cant see it having any effect. If you don't like it don't use it.
Feb 12 2014
prev sibling next sibling parent "Mike" <none none.com> writes:
On Tuesday, 11 February 2014 at 22:11:30 UTC, eles wrote:
 On Tuesday, 11 February 2014 at 21:11:15 UTC, Walter Bright 
 wrote:
 On 2/11/2014 11:43 AM, Walter Bright wrote:
 (First off, I hate the name "better C", any suggestions?)

How about "EmbeddedD", though that wouldn't be entirely accurate?

-metal

cool, but no!
Feb 11 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 11 Feb 2014 16:11:19 -0500, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 2/11/2014 11:43 AM, Walter Bright wrote:
 (First off, I hate the name "better C", any suggestions?)

How about "EmbeddedD", though that wouldn't be entirely accurate?

What about BareD? -Steve
Feb 11 2014
prev sibling next sibling parent "Mike" <none none.com> writes:
On Wednesday, 12 February 2014 at 02:18:09 UTC, Manu wrote:

 I prefer the idea already mentioned of making a more 
 well-defined
 separation of D-core (static stuff), and then the rest as a 
 higher layer.
 Ie, rather than 'EmbeddeD' which suggests a _removal_ of stuff, 
 if D
 existed as 2 layers, then rather than removing the top layer, 
 you're simply
 not adding the top layer. If that makes sense.

An Excellent Idea!
Feb 11 2014
prev sibling next sibling parent "Frustrated" <c1514843 drdrb.com> writes:
On Thursday, 13 February 2014 at 06:51:37 UTC, 1100110 wrote:
 On 2/11/14, 17:15, Mike wrote:
 On Tuesday, 11 February 2014 at 21:11:15 UTC, Walter Bright 
 wrote:
 On 2/11/2014 11:43 AM, Walter Bright wrote:
 (First off, I hate the name "better C", any suggestions?)

How about "EmbeddedD", though that wouldn't be entirely accurate?

I program ONLY embedded systems in D and I very much dislike the idea of introducing a new name. There should be only one D , but there's no reason features couldn't be enabled/disabled with compiler switches (-fno-exceptions, -fno-rtti) There's no reason to aggregate compiler switches into a single name. I f users want no exceptions, no gc, no objects, etc... then they should add -fno-exceptions, -fno-gc, -fno-objects, etc... to their compiler flags. Please, I beg you! No new names. Please don't fragment the language. Just make it a little more modular. Mike

I agree, if this is strictly restricting the language to a core subset, then I cant see it having any effect. If you don't like it don't use it.

And this is the crux of the problem. For some, any change is bad because they are happy and do not care about the rest. Simply drawing a imaginary boundary inside d and labeling it "the core" isn't much of a change... unless you hate change. (we can talk about what to do with the core all day long but it is irrelevant if we can't even draw the boundary because it freaks people out and give them hemorrhoids and hard palpitations)
Feb 13 2014
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Tuesday, 11 February 2014 at 21:55:49 UTC, Francesco Cattoglio
wrote:
 If you hate too many Ds, then the best name is by far "D flat": 
 D♭

Or rather D minor. Or what about AC ? Cuz AC is D C. Or Washington (D C). EmbeD wasn't too bad. It allows "In bed with EmbeD".
Feb 16 2014
prev sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Thursday, 13 February 2014 at 06:51:37 UTC, 1100110 wrote:
 Please, I beg you! No new names. Please don't fragment the 
 language.
 Just make it a little more modular.

 Mike

I agree, if this is strictly restricting the language to a core subset, then I cant see it having any effect. If you don't like it don't use it.

But you can't use Phobos. Practically, that would mean rewriting a lot of Phobos, or another standard library.
Feb 16 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:

 I think you overestimate the size of this project.

The "project" is very small as long as people don't start creating (or modifying) library modules for such language subset. Bye, bearophile
Feb 11 2014
prev sibling next sibling parent "Frank Bauer" <y z.com> writes:
Excellent idea. All the cries (including mine) for a non-GC D
would stop at once. Instead, we could focus on gradually bringing
all the remaining features of D-Full into D-Core over the next
years. Walter would have to judge on that, but to an outsider it
looks doable without too much resources.

And, as I firmly believe, this could make the difference between
D getting accepted by the C++ crowd on one side and D
disappearing from the scene as just another C# / Java clone
(untrue, but I talk about public perception).
Feb 11 2014
prev sibling next sibling parent reply "Xinok" <xinok live.com> writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 What do you think?

I don't do embedded programming, so take my opinion with a grain of salt... Rather than making this a compiler switch, I think it would be more beneficial to branch this off as a new project, essentially building a new compiler. Similarly, it would contain that subset of features which are practical for embedded programming and strip out the rest. Then likewise to VisualD, make it an "official" repository on GitHub. The benefit of having a separate project dedicated to embedded programming is the ability to retain a standard library without convoluting the rest of the D ecosystem. A slim standard library could be developed, mimicking (or even branched from) Phobos, but optimized for embedded systems. As DMD is updated, the changes would be merged into "embedded D", but otherwise the two would be maintained independently of one another. It wouldn't be too dissimilar to other projects like it. There are projects which add non-official extensions to other languages, such as adding a garbage collector to C/C++.
Feb 11 2014
parent Mike Parker <aldacron gmail.com> writes:
On 2/12/2014 6:13 AM, Xinok wrote:
 On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 What do you think?

I don't do embedded programming, so take my opinion with a grain of salt... Rather than making this a compiler switch, I think it would be more beneficial to branch this off as a new project, essentially building a new compiler. Similarly, it would contain that subset of features which are practical for embedded programming and strip out the rest. Then likewise to VisualD, make it an "official" repository on GitHub. The benefit of having a separate project dedicated to embedded programming is the ability to retain a standard library without convoluting the rest of the D ecosystem. A slim standard library could be developed, mimicking (or even branched from) Phobos, but optimized for embedded systems. As DMD is updated, the changes would be merged into "embedded D", but otherwise the two would be maintained independently of one another.

One of the points is to avoid the need of a standard library. Besides, making a separate compiler adds more maintenance overhead and is a sure way to encourage fragmentation.
Feb 11 2014
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Tuesday, 11 February 2014 at 20:53:06 UTC, Steven 
Schveighoffer wrote:
 But the feature would be very simple to implement. You just 
 avoid outputting any runtime type info, and avoid any compiler 
 hooks into the runtime.

 There is no requirement to do anything else. The language is 
 finished. C's standard library becomes the standard library.

And how do people find out about this language? Won't it need to be documented on the website? Where does that come from? Will this be a separate project, or just the DMD compiler with BETTER_C defines to mask out runtime hooks? If it's a separate project, who's doing all the bug fix integrations from D2 proper to better C? If it's the same project, who fixes the bugs when a runtime hook is accidentally introduced by a dev that forgot better C existed? Who manages the releases of better C? If this proves to be popular, do you really think there will be no feature requests? (and if it's not popular, why do it in the first place?) Remember, D1 was just D2 without a bunch of features and we had to discontinue that because it was taking too much time to maintain. How will this be different?
Feb 11 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 I've toyed with this idea for a while, and wondered what the 
 interest there is in something like this.

 The idea is to be able to use a subset of D that does not 
 require any of druntime or phobos - it can be linked merely 
 with the C standard library. To that end, there'd be a compiler 
 switch (-betterC) which would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new 
 platform, as the new platform didn't have a working phobos.

 What do you think?

I have been asking for it since long time ago :) It will essentially just turn linker errors into compiler errors when you try to hack barebone stuff which is considerably nicer. Calling it "embedded D" would have been a bit overly abmitious as there will still be some issues to be resolved but it will provider more convenient starting ground for those willing to experiment.
Feb 11 2014
prev sibling next sibling parent "Xinok" <xinok live.com> writes:
On Tuesday, 11 February 2014 at 21:13:58 UTC, Peter Alexander 
wrote:
 On Tuesday, 11 February 2014 at 20:53:06 UTC, Steven 
 Schveighoffer wrote:
 But the feature would be very simple to implement. You just 
 avoid outputting any runtime type info, and avoid any compiler 
 hooks into the runtime.

 There is no requirement to do anything else. The language is 
 finished. C's standard library becomes the standard library.

Who manages the releases of better C?

If there is indeed a market for it, then new talent will join the community and contribute to the project. If not, then it will become a poorly maintained and unsupported feature which is eventually stripped from the compiler due to lack of use. An interesting statistic on the Linux kernel: An analysis of the Linux kernel showed 75 percent of the code from December 2008 to January 2010 was developed by programmers working for corporations, leaving about 18 percent to volunteers and 7% unclassified. https://en.wikipedia.org/wiki/Linux#Community I don't know of many people who do embedded programming for personal reasons. The majority of interest stems from corporations, not individuals. And that's where we'll find maintainers for this project.
Feb 11 2014
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Tuesday, 11 February 2014 at 21:22:40 UTC, Walter Bright wrote:
 snip

Thank you, so this project would need to be maintained alongside D2 development, just like D1 was. Is it really worth taking effort away from D2 when so much is left to do there?
Feb 11 2014
prev sibling next sibling parent reply "Francesco Cattoglio" <francesco.cattoglio gmail.com> writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 The idea is to be able to use a subset of D that does not 
 require any of druntime or phobos - it can be linked merely 
 with the C standard library.

 What do you think?

I don't do embedded, so my opinion is just an opinion. I don't see any big issue with having some extra work. Do you think it would be easier to create this after having switched to "DDMD"?
Feb 11 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/11/2014 1:34 PM, Francesco Cattoglio wrote:
 Do you think it would be easier to create this after having switched to "DDMD"?

That wouldn't make it either harder or easier.
Feb 11 2014
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tuesday, 11 February 2014 at 21:28:15 UTC, Peter Alexander 
wrote:
 On Tuesday, 11 February 2014 at 21:22:40 UTC, Walter Bright 
 wrote:
 snip

Thank you, so this project would need to be maintained alongside D2 development, just like D1 was. Is it really worth taking effort away from D2 when so much is left to do there?

A few if() blocks and some code to parse a command-line option is hardly a "project" that needs to be "maintained alongside D2 development". However, I agree that there are better things the core compiler maintainers could do with their time. I think such a switch would be easy enough to implement and maintain by whoever needs it.
Feb 11 2014
prev sibling next sibling parent "Frustrated" <c1514843 drdrb.com> writes:
On Tuesday, 11 February 2014 at 21:39:19 UTC, Andrei Alexandrescu
wrote:
 On 2/11/14, 12:47 PM, Peter Alexander wrote:
 On Tuesday, 11 February 2014 at 20:02:37 UTC, Frustrated wrote:
 On Tuesday, 11 February 2014 at 19:56:11 UTC, Peter Alexander
 wrote:
 On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright 
 wrote:
 What do you think?

I think it would have little benefit and would just lead to pointless fragmentation and maintenance for the compiler devs.

Do you program on embedded systems? If not then do you think you are qualified to say it would have little benefit or not?

I do program on embedded systems. I'll elaborate more on why I think this is a bad idea. First, we are struggling immensely as it is to get D2 into a complete state. Many parts of the language are still poorly defined and even more poorly implemented. The standard library is still lacking in critical areas and there are still thousands of non-trivial bugs in the database. The language itself is still evolving rapidly. Speaking optimistically, I think we are still a few years away from resolving the existing language issues, based on the current pace of things. We're heading in the right direction now and even accelerating, but I think it would be incredibly unwise to embark on a new side-project, which would just consume dev time, pulling effort away from D2 development. D1 was discontinued to spend more time on D2, not to start new projects of debatable benefit. Please let's finish this language before we start on another.

I agree. Walter, let's put that on the backburner. Thanks. Andrei

I believe this is the wrong way to think about it. It is not creating a new language, creating new features, or anything. It is simply partitioning the language feature set into two parts, one that works on more systems, is easier to implement by others, easier on the compiler, debuggers, and whole tool chain and requires virtually nothing but a little time going over the d language spec and saying "This goes goes in this bin, that goes in that bin" then have it reviewed. This is really at this point just saying what the core part of the spec is. Which is a subset of the language spec, nothing new, very little work to be done, opens up the floodgates for people to get it moving. It's actually counterproductive to hold it off as you are putting the breaks on D becoming used by more people. If you create an embedded systems level core(which is just saying that it works well in embedded systems, which generally require lower overhead) now then people can get it moving now. You don't even need a compiler for it at this point. Just create the subset language spec(easy peasy), put it out there, get some interest on it, then let others write it for you(by forking the compiler, making the changes that are require(which is removing code rather than adding in most cases)). If you wait 5 years for this then that puts D 5 years behind in the embedded systems and 5 years that people could have been working on it.
Feb 11 2014
prev sibling next sibling parent "Chris Williams" <yoreanon-chrisw yahoo.co.jp> writes:
I'd say that "D as a Better C++" would have merit. Those would 
wanted to avoid classes could do so, so you'd have already 
achieved "D as a Better C" by doing it, without having to product 
a different language reference. Point in fact, there shouldn't be 
any difference in the language references other than that in the 
GC-less variant, you have to call "delete" to free memory, do 
some extra magic to work with ranges, and Phobos isn't included.
Feb 11 2014
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 2/11/14, 3:41 PM, Andrei Alexandrescu wrote:
 On 2/11/14, 1:10 PM, Walter Bright wrote:
 On 2/11/2014 12:53 PM, Steven Schveighoffer wrote:
 I think you overestimate the size of this project.

I agree it's not a big deal. It's just implementing a switch that disables a list of features. The switch even already exists, though it is incomplete. The payoff is the embedded market is huge, and this can greatly expand D's presence in the marketplace.

It's yet another opportunity to waste focus. (But then it goes to prove that everybody does what they want...) Andrei

It's analogous to estimating the cost of any other new feature. It's far more than the cost of just the implementation. I don't disagree with doing it, not at all, but also have a concern with under estimating the costs.
Feb 11 2014
prev sibling next sibling parent reply "ed" <growlercab gmail.com> writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 I've toyed with this idea for a while, and wondered what the 
 interest there is in something like this.

 The idea is to be able to use a subset of D that does not 
 require any of druntime or phobos - it can be linked merely 
 with the C standard library. To that end, there'd be a compiler 
 switch (-betterC) which would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new 
 platform, as the new platform didn't have a working phobos.

 What do you think?

I think a D subset language would be great. We currently used D in a similar manner at work. Myself and a colleague often use D to prototype C/C++ code and then manually ported it across. The manual port imposes very tight constraints on what we can use from D but it is still better than C. Even with the manual porting effort it speeds up development. The D compiler catches subtle bugs that creep into C code when deadlines are tight and the porting itself is great as a review process. Cheers, ed
Feb 11 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 11.02.2014 23:01, schrieb bearophile:
 ed:

 The D compiler catches subtle bugs that creep into C code when
 deadlines are tight and the porting itself is great as a review process.

Isn't using something Clang (plus eventually a static analyzer) an even better strategy? Bye, bearophile

I also would consider it a better approach. Even me with my C bashing, think that clang + warnings as errors + static analyzer == C with Pascal like safety -- Paulo
Feb 11 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
ed:

 The D compiler catches subtle bugs that creep into C code when 
 deadlines are tight and the porting itself is great as a review 
 process.

Isn't using something Clang (plus eventually a static analyzer) an even better strategy? Bye, bearophile
Feb 11 2014
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 2/11/14, 3:54 PM, Frustrated wrote:
 I believe this is the wrong way to think about it. It is not
 creating a new language, creating new features, or anything. It
 is simply partitioning the language feature set into two parts,
 one that works on more systems, is easier to implement by others,
 easier on the compiler, debuggers, and whole tool chain and
 requires virtually nothing but a little time going over the d
 language spec and saying "This goes goes in this bin, that goes
 in that bin" then have it reviewed.

 This is really at this point just saying what the core part of
 the spec is. Which is a subset of the language spec, nothing new,
 very little work to be done, opens up the floodgates for people
 to get it moving. It's actually counterproductive to hold it off
 as you are putting the breaks on D becoming used by more people.

 If you create an embedded systems level core(which is just saying
 that it works well in embedded systems, which generally require
 lower overhead) now then people can get it moving now.

 You don't even need a compiler for it at this point. Just create
 the subset language spec(easy peasy), put it out there, get some
 interest on it, then let others write it for you(by forking the
 compiler, making the changes that are require(which is removing
 code rather than adding in most cases)).


 If you wait 5 years for this then that puts D 5 years behind in
 the embedded systems and 5 years that people could have been
 working on it.

That's a very incomplete view of the work required. If it's a formal part of the design of the language, then it requires far more than just a tiny bit of compiler work. It requires a rework of the docs, and not just a tiny rework. If all we do is a surface level execution, we'll have only muddied up the spec and the language even further, not clarified and simplified anything. This is a recurring problem with almost every change to D. It's maybe half executed on. And this would be conceptually a very large split, even if small at the compiler level.
Feb 11 2014
prev sibling next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 I've toyed with this idea for a while, and wondered what the 
 interest there is in something like this.

 The idea is to be able to use a subset of D that does not 
 require any of druntime or phobos - it can be linked merely 
 with the C standard library. To that end, there'd be a compiler 
 switch (-betterC) which would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new 
 platform, as the new platform didn't have a working phobos.

 What do you think?

What will this language's niche be? What job is it targeted at? Why would somebody use better C rather than just plain C?
Feb 11 2014
prev sibling next sibling parent "ed" <growlercab gmail.com> writes:
On Tuesday, 11 February 2014 at 22:01:01 UTC, bearophile wrote:
 ed:

 The D compiler catches subtle bugs that creep into C code when 
 deadlines are tight and the porting itself is great as a 
 review process.

Isn't using something Clang (plus eventually a static analyzer) an even better strategy? Bye, bearophile

Absolutely :D Our main focus has been to introduced D into our workplace. We've been converting a number of old die hard C programmers by showing them how much better the language is, even if one is just writing "C" in D. The bug catching was, however, a pleasant side-effect. I think the transition to D in the embedded world would be quicker if it were possible to obtain a minimal D language that produces the smallest binaries possible. Perhaps a good place to start would be with a formal grammar that defines what is the kernel of D and what is the D language proper. Cheers, ed
Feb 11 2014
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Tuesday, 11 February 2014 at 22:19:13 UTC, Gary Willoughby 
wrote:
 On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright 
 wrote:

 What will this language's niche be? What job is it targeted at?

My job (realtime embedded Linux).
 Why would somebody use better C rather than just plain C?

If you send me to a C compiler, why bother to evangelize me D? I have C# and Java for all the other uses that are not embedded. Please, stop telling about "alternatives". It is like taking aways D's very reason of existence. If is just an application language, it loses. There are better and better-supported out there on the market. But there is no better systems programming language. System programming language means being able to write the druntime in it. Without relying on, well, druntime. If you keep telling "you could use C for that", then, well, I could use C instead of D everywhere, just plain and simple, just as I already do today. In that case, sorry, neither me neither my boss, we are not interested in a Java clone. We don't have space for the virtual machine (oh, call it runtime...). And, as you say, we could just use C. Or that embedded subset of C++. Speaking about subsets, by the way...
Feb 11 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

I think this would kill the usefulness. I've written little D runtimes (doesn't even use the C runtime!) to build working programs that use this stuff and it didn't take a lot of code. I'd prefer it if the switch ONLY suppressed generation of typeinfo or moduleinfo... and I think there was something else, we have a betterC bugzilla entry that summarized the last discussion. But still, I'd say it would be better to just not generate some of these things and let the user deal with it. They might manually opt-in to certain things and might not... and I'd say go ahead and leave it as linker errors too. If we want other stuff to help, do it with the whole D language, for example nogc has been discussed and might be useful here, while also being useful with the regular druntime.
Feb 11 2014
prev sibling next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Tuesday, 11 February 2014 at 21:41:22 UTC, Andrei Alexandrescu 
wrote:
 It's yet another opportunity to waste focus.

+1
Feb 11 2014
prev sibling next sibling parent Justin Whear <justin economicmodeling.com> writes:
On Tue, 11 Feb 2014 22:19:12 +0000, Gary Willoughby wrote:

 On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 I've toyed with this idea for a while, and wondered what the interest
 there is in something like this.

 The idea is to be able to use a subset of D that does not require any
 of druntime or phobos - it can be linked merely with the C standard
 library. To that end, there'd be a compiler switch (-betterC) which
 would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

 The subset would disallow use of any features that rely on:

 1. moduleinfo 2. exception handling 3. gc 4. Object

 I've used such a subset before when bringing D up on a new platform, as
 the new platform didn't have a working phobos.

 What do you think?

What will this language's niche be? What job is it targeted at? Why would somebody use better C rather than just plain C?

Here are the reasons I use D even when writing very C-style code: - Symbolic imports - Static asserts, conditional compilation, etc. that doesn't depend on a macro language which I've never been entirely comfortable with. - Templates. Also, templates. Seriously, templates. - Sane type names (I'm biased on this, but I don't like "unsigned long long" or the fact the '*' binds to the right. - Array types which carry length. - I also like to use exceptions, which I understand would not be supported by this proposal.
Feb 11 2014
prev sibling next sibling parent "Mike" <none none.com> writes:
On Tuesday, 11 February 2014 at 20:42:26 UTC, bearophile wrote:
 Walter Bright:

 (First off, I hate the name "better C", any suggestions?)

A different name is needed.

I don't think a different name is needed, nor do I think it would be a good idea. All that's needed are a few compiler switches to enable/disable features so D can be used on more platforms. GNU g++ does this without giving it a new name (e.g. -fno-exceptions, -fno-rtti, etc...) D can do the same without giving it a new name.
 What do you think?

It must produce very small binaries. If you import anything from Phobos it will not work in most cases, even if the feature you are importing does not require GC, druntime, etc, because in most cases other parts of the Phobos module use them. Is this going to cause a fragmentation of Phobos? What to do with dynamic array literals? In many cases they allocate. A partial solution is to use the [...]s syntax for fixed size array literals. Constant associative arrays at global scope don't need the GC, but they need the druntime, so I guess they too need to be disallowed. Bye, bearophile

I don't consider Phobos part of thE D language, just part of the D ecosystem. If one disables features on which phobos depends, and phobos doesn't work, that's what they deserve. In time, however, phobos could be ported to more limited systems that don't have certain D features, but that's such a long term goal right now. I wouldn't even worry about it until the runtime is brought to those platforms first. Mike
Feb 11 2014
prev sibling next sibling parent reply Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 11/02/2014 20:43, Walter Bright a écrit :
 I've toyed with this idea for a while, and wondered what the interest
 there is in something like this.

 The idea is to be able to use a subset of D that does not require any of
 druntime or phobos - it can be linked merely with the C standard
 library. To that end, there'd be a compiler switch (-betterC) which
 would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new platform, as
 the new platform didn't have a working phobos.

 What do you think?

If I correctly understand class will stay usable? So IMO it's just like if you said : "I want do a fork of D2 without GC". If you are going to this way some people will certainly fork this D2-BetterC version and add it a new standard library more like QtCore. In this case why not simply improve the D modularity and put features you want remove as options? The main issue is about how phobos have to manage memory, with or without GC, maybe both? If you want go to the modularity, it's really nice, but maybe it will simpler to remove only GC and reboot phobos. Maybe it can help D contributors to be focused on system aspects of language instead of full-featured that can be reached only with a big community or commercial patterns.
Feb 11 2014
next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Tue, 11 Feb 2014 15:10:13 -0800, Xavier Bigand  =

<flamaros.xavier gmail.com> wrote:

 Le 11/02/2014 20:43, Walter Bright a =E9crit :
 I've toyed with this idea for a while, and wondered what the interest=


 there is in something like this.

 The idea is to be able to use a subset of D that does not require any=


 druntime or phobos - it can be linked merely with the C standard
 library. To that end, there'd be a compiler switch (-betterC) which
 would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new platform, =


 the new platform didn't have a working phobos.

 What do you think?

If I correctly understand class will stay usable? So IMO it's just like if you said : "I want do a fork of D2 without GC=

 If you are going to this way some people will certainly fork this  =

 D2-BetterC version and add it a new standard library more like QtCore.=

 In this case why not simply improve the D modularity and put features =

 you want remove as options? The main issue is about how phobos have to=

 manage memory, with or without GC, maybe both?

 If you want go to the modularity, it's really nice, but maybe it will =

 simpler to remove only GC and reboot phobos. Maybe it can help D  =

 contributors to be focused on system aspects of language instead of  =

 full-featured that can be reached only with a big community or  =

 commercial patterns.

Classes rely on Object. It's better C, not C++. You'll still have struct= s. -- = Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Feb 11 2014
parent reply Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 12/02/2014 00:12, Adam Wilson a crit :
 On Tue, 11 Feb 2014 15:10:13 -0800, Xavier Bigand
 <flamaros.xavier gmail.com> wrote:

 Le 11/02/2014 20:43, Walter Bright a crit :
 I've toyed with this idea for a while, and wondered what the interest
 there is in something like this.

 The idea is to be able to use a subset of D that does not require any of
 druntime or phobos - it can be linked merely with the C standard
 library. To that end, there'd be a compiler switch (-betterC) which
 would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new platform, as
 the new platform didn't have a working phobos.

 What do you think?

If I correctly understand class will stay usable? So IMO it's just like if you said : "I want do a fork of D2 without GC". If you are going to this way some people will certainly fork this D2-BetterC version and add it a new standard library more like QtCore. In this case why not simply improve the D modularity and put features you want remove as options? The main issue is about how phobos have to manage memory, with or without GC, maybe both? If you want go to the modularity, it's really nice, but maybe it will simpler to remove only GC and reboot phobos. Maybe it can help D contributors to be focused on system aspects of language instead of full-featured that can be reached only with a big community or commercial patterns.

Classes rely on Object. It's better C, not C++. You'll still have structs.

classes?
Feb 11 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Adam Wilson"  wrote in message news:op.xa44tcvr707hn8 invictus.hra.local...

 IIRC every class, if it inherits from nothing else, inherits from Object. 
 The compiler expects Object on all classes. Beyond that I can't speak to 
 how dependent the compiler is on the inheritance to make classes work.

extern(C++) classes do not depend on object/Object or anything else.
Feb 11 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Adam Wilson"  wrote in message news:op.xa5d17y1707hn8 invictus.hra.local...

 Awesome, I didn't know that. Does that mean we could add a switch for 
 default linkage? That's good to know for reasons related to a couple of my 
 D projects.

It could be done, although I'm not sure it's a good idea.
Feb 11 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Adam Wilson"  wrote in message news:op.xa5eelqr707hn8 invictus.hra.local...

 Why?

 Well, I was asking for the D-Core folks, if they could default the linkage 
 to C++ then they could use classes without Object. And setting the default 
 linkage might be useful for bindings.

Problems with overloading, separate compilation, some types can't be used with extern(C++) functions etc. Just putting extern(C++): at the top of the file does a similar thing within the current system.
Feb 11 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Tue, 11 Feb 2014 15:25:23 -0800, Xavier Bigand  =

<flamaros.xavier gmail.com> wrote:

 Le 12/02/2014 00:12, Adam Wilson a =E9crit :
 On Tue, 11 Feb 2014 15:10:13 -0800, Xavier Bigand
 <flamaros.xavier gmail.com> wrote:

 Le 11/02/2014 20:43, Walter Bright a =E9crit :
 I've toyed with this idea for a while, and wondered what the intere=




 there is in something like this.

 The idea is to be able to use a subset of D that does not require a=




 of
 druntime or phobos - it can be linked merely with the C standard
 library. To that end, there'd be a compiler switch (-betterC) which=




 would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new platform=




 as
 the new platform didn't have a working phobos.

 What do you think?

If I correctly understand class will stay usable? So IMO it's just like if you said : "I want do a fork of D2 without GC". If you are going to this way some people will certainly fork th=



 D2-BetterC version and add it a new standard library more like QtCor=



 In this case why not simply improve the D modularity and put feature=



 you want remove as options? The main issue is about how phobos have =



 manage memory, with or without GC, maybe both?

 If you want go to the modularity, it's really nice, but maybe it wil=



 simpler to remove only GC and reboot phobos. Maybe it can help D
 contributors to be focused on system aspects of language instead of
 full-featured that can be reached only with a big community or
 commercial patterns.

Classes rely on Object. It's better C, not C++. You'll still have =


 structs.


 classes?

IIRC every class, if it inherits from nothing else, inherits from Object= . = The compiler expects Object on all classes. Beyond that I can't speak to= = how dependent the compiler is on the inheritance to make classes work. -- = Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Feb 11 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Tue, 11 Feb 2014 18:40:08 -0800, Daniel Murphy  
<yebbliesnospam gmail.com> wrote:

 "Adam Wilson"  wrote in message  
 news:op.xa44tcvr707hn8 invictus.hra.local...

 IIRC every class, if it inherits from nothing else, inherits from  
 Object. The compiler expects Object on all classes. Beyond that I can't  
 speak to how dependent the compiler is on the inheritance to make  
 classes work.

extern(C++) classes do not depend on object/Object or anything else.

Awesome, I didn't know that. Does that mean we could add a switch for default linkage? That's good to know for reasons related to a couple of my D projects. -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Feb 11 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Tue, 11 Feb 2014 18:50:57 -0800, Daniel Murphy  
<yebbliesnospam gmail.com> wrote:

 "Adam Wilson"  wrote in message  
 news:op.xa5d17y1707hn8 invictus.hra.local...

 Awesome, I didn't know that. Does that mean we could add a switch for  
 default linkage? That's good to know for reasons related to a couple of  
 my D projects.

It could be done, although I'm not sure it's a good idea.

Why? Well, I was asking for the D-Core folks, if they could default the linkage to C++ then they could use classes without Object. And setting the default linkage might be useful for bindings. -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Feb 11 2014
prev sibling parent Manu <turkeyman gmail.com> writes:
--089e01227f50caa0f904f22d1b45
Content-Type: text/plain; charset=UTF-8

On 12 February 2014 12:55, Adam Wilson <flyboynw gmail.com> wrote:

 On Tue, 11 Feb 2014 18:50:57 -0800, Daniel Murphy <
 yebbliesnospam gmail.com> wrote:

  "Adam Wilson"  wrote in message news:op.xa5d17y1707hn8 
 invictus.hra.local...

  Awesome, I didn't know that. Does that mean we could add a switch for
 default linkage? That's good to know for reasons related to a couple of my
 D projects.

It could be done, although I'm not sure it's a good idea.

Why? Well, I was asking for the D-Core folks, if they could default the linkage to C++ then they could use classes without Object. And setting the default linkage might be useful for bindings.

It'll create linking problems if different modules refer to eachother, but happen to be compiled with different flags. It would be better to use 'extern(C):' at the top of your module, then modules importing your module know what to expect. extern(C++) classes are still GC allocated, so it's still not so simple. You'd need to start using emplace with manual allocation. --089e01227f50caa0f904f22d1b45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 2 February 2014 12:55, Adam Wilson <span dir=3D"ltr">&lt;<a href=3D"mailto:= flyboynw gmail.com" target=3D"_blank">flyboynw gmail.com</a>&gt;</span> wro= te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-= left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On Tue, 11 Feb 2014 18:50:57 -0800,= Daniel Murphy &lt;<a href=3D"mailto:yebbliesnospam gmail.com" target=3D"_b= lank">yebbliesnospam gmail.com</a>&gt; wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> &quot;Adam Wilson&quot; =C2=A0wrote in message news:op.xa5d17y1707hn8 <u></= u>invictus.hra.local...<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Awesome, I didn&#39;t know that. Does that mean we could add a switch for d= efault linkage? That&#39;s good to know for reasons related to a couple of = my D projects.<br> </blockquote> <br> It could be done, although I&#39;m not sure it&#39;s a good idea.<br> </blockquote> <br></div></div> Why?<br> <br> Well, I was asking for the D-Core folks, if they could default the linkage = to C++ then they could use classes without Object. And setting the default = linkage might be useful for bindings.</blockquote><div><br></div><div> It&#39;ll create linking problems if different modules refer to eachother, = but happen to be compiled with different flags.</div><div>It would be bette= r to use &#39;extern(C):&#39; at the top of your module, then modules impor= ting your module know what to expect.<br> </div><div><br></div><div>extern(C++) classes are still GC allocated, so it= &#39;s still not so simple. You&#39;d need to start using emplace with manu= al allocation.</div></div></div></div> --089e01227f50caa0f904f22d1b45--
Feb 11 2014
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 11/02/14 20:43, Walter Bright wrote:
 (First off, I hate the name "better C", any suggestions?)

In no particular order: -minimal -minimal-language -lite -light -lightweight FWIW I'm not sure I agree with the concerns about lost focus. It should be a small change in and of itself, and it shouldn't be disruptive to anyone's current projects. What it could do however is open up (or at least publicize) opportunities for people whose use-cases aren't currently perceived as well-supported.
Feb 11 2014
prev sibling next sibling parent "Mike" <none none.com> writes:
On Tuesday, 11 February 2014 at 22:21:32 UTC, ed wrote:

 Perhaps a good place to start would be with a formal grammar 
 that defines what is the kernel of D and what is the D language 
 proper.

Yes, and I think this is far more important task than the OP's proposal. Mike
Feb 11 2014
prev sibling next sibling parent "Mike" <none none.com> writes:
On Tuesday, 11 February 2014 at 22:25:01 UTC, eles wrote:
 Why would somebody use better C rather than just plain C?

If you send me to a C compiler, why bother to evangelize me D? I have C# and Java for all the other uses that are not embedded. Please, stop telling about "alternatives". It is like taking aways D's very reason of existence. If is just an application language, it loses. There are better and better-supported out there on the market. But there is no better systems programming language.

I very much agree here, but we don't need new name to make D suitable for systems programming. A small set of compiler switches will suffice. Mike
Feb 11 2014
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 11/02/14 22:12, Frank Bauer wrote:
 Excellent idea. All the cries (including mine) for a non-GC D
 would stop at once.

I hope so, but I doubt it. Instead the criticisms will start focusing on the lack of library functionality and the potential for a Phobos/Tango style split between regular D and the minimal non-GC D. That's not however a reason to not go forward with this.
Feb 11 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 11 Feb 2014 18:39:53 -0500, Joseph Rushton Wakeling  
<joseph.wakeling webdrake.net> wrote:

 On 11/02/14 22:12, Frank Bauer wrote:
 Excellent idea. All the cries (including mine) for a non-GC D
 would stop at once.

I hope so, but I doubt it. Instead the criticisms will start focusing on the lack of library functionality and the potential for a Phobos/Tango style split between regular D and the minimal non-GC D.

I don't think so. Any valid minimal D is valid D. Tango vs. Phobos was a completely different incompatible runtime, and then later, a difference between D1 and D2. -Steve
Feb 11 2014
prev sibling next sibling parent "ed" <growlercab gmail.com> writes:
On Tuesday, 11 February 2014 at 21:13:58 UTC, Peter Alexander 
wrote:
[snip]
 Remember, D1 was just D2 without a bunch of features and we had 
 to discontinue that because it was taking too much time to 
 maintain. How will this be different?

It is different because this D-core is the one D-core of D2 used in D-runtime and Phobobs. It is simply a subset of the D2 core language and not a mini-D developed in parallel. I think it would be useful in the embedded world especially. It may also help shrink Phobos down to be as small as possible and avoid the GC where it is important. Anyway, that's my take on the proposal. Cheers, ed
Feb 11 2014
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 12/02/14 00:44, Steven Schveighoffer wrote:
 I don't think so. Any valid minimal D is valid D. Tango vs. Phobos was a
 completely different incompatible runtime, and then later, a difference between
 D1 and D2.

I'm not saying it'd be _fair_ criticism. I'm just anticipating that it'll happen. :-)
Feb 11 2014
prev sibling next sibling parent "Mike" <none none.com> writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 I've toyed with this idea for a while, and wondered what the 
 interest there is in something like this.

 The idea is to be able to use a subset of D that does not 
 require any of druntime or phobos - it can be linked merely 
 with the C standard library. To that end, there'd be a compiler 
 switch (-betterC) which would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new 
 platform, as the new platform didn't have a working phobos.

 What do you think?

I began studying and programming in D primarily to do ARM bare metal programming in something other than C and C++. I'm in favor of adding compiler switches like -fno-rtti, -fno-moduleinfo, -fno-exceptions etc..., but I'm not in favor of aggregating them under a single name like "-betterC" or "-worseD". I use GDC with the -fno-emit-moduleinfo switch. In fact, it is necessary for what I'm trying to do. Right now I have to stub out the TypeInfo stuff[1] to get things to compile, so a -fno-rtti switch would be cool, but I still don't understand why the compiler doesn't just emit whatever TypeInfo stuff I supply, and nothing if I don't supply it. Discussion here[2] Automatic Memory Management should be decoupled from the language as much as possible. Ideally we should just be able to add -lgc, -larc, -lnone to our linker flags and the language would use a Garbage Collector, Automatic Reference Counting, or no memory management respectively. Or something along these lines. I don't know what the right solution is. Just make it transparent to the language and an option to the programmer. I realize this is easier said than done, though. BOTTOM LINE: I don't want a better C. I want a better D. [1] https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/blob/memory-mapped-io/source/object.d [2] http://forum.dlang.org/post/jynxfglpulguvqbivrms forum.dlang.org Mike
Feb 11 2014
prev sibling next sibling parent "Mike" <none none.com> writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 I've toyed with this idea for a while, and wondered what the 
 interest there is in something like this.

 The idea is to be able to use a subset of D that does not 
 require any of druntime or phobos - it can be linked merely 
 with the C standard library. To that end, there'd be a compiler 
 switch (-betterC) which would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new 
 platform, as the new platform didn't have a working phobos.

 What do you think?

I began studying and programming in D primarily to do ARM bare metal programming in something other than C and C++, and I want to comment separately on the something others have brought up on this thread: Priorities. DMD doesn't support ARM or any other embedded platform, so I don't know what use this would be to DMD. If it were a front-end feature for GDC or LDC, yes, that would be alright, but I'm doing fine without it so far, and there are many other annoyances in D that I'd rather have fixed first. 1. There are pull requests waiting for action from people at the time. Here's my own personal pet peeve https://github.com/D-Programming-Language/dlang.org/pull/200 Andrej Mitrovic posted another list here: http://forum.dlang.org/post/mailman.71.1391878139.21734.digitalmars-d puremagic.com ... and I've heard so far on these is crickets. What's the holdup here? 2. The official language reference is out of date with what's happened in the language. These documents should be updated. Tutorials, How-To's, etc can be made by the community, but the core language reference should be updated an properly maintained by the core contributors. 3. There were 2 separate proposals on improving the garbage collector for at DConf 2013, but it doesn't appear that that knowledge was capitalized on (as far as I know anyway). 4. What's going on with std.allocators? etc... In summary: 1. I'm not in favor of creating a subset of D. There should be only one D, but it should be feature-modular. 2. I think there are some blocking obstacles in the way that are preventing others from getting closure and moving forward. Those should be tackled first. Mike
Feb 11 2014
prev sibling next sibling parent "Mike" <none none.com> writes:
On Wednesday, 12 February 2014 at 01:07:04 UTC, Mike wrote:
 I'm in favor of adding compiler switches like -fno-rtti, 
 -fno-moduleinfo, -fno-exceptions etc...,

One other switch which would be useful would be -fsingle-threaded. This would mean TLS variables could be treated as __gshared automatically. Mike
Feb 11 2014
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c2903cb0230904f22c1550
Content-Type: text/plain; charset=UTF-8

On 12 February 2014 05:43, Walter Bright <newshound2 digitalmars.com> wrote:

 I've toyed with this idea for a while, and wondered what the interest
 there is in something like this.

 The idea is to be able to use a subset of D that does not require any of
 druntime or phobos - it can be linked merely with the C standard library.
 To that end, there'd be a compiler switch (-betterC) which would enforce
 the subset.

 (First off, I hate the name "better C", any suggestions?)

D-- ;) The subset would disallow use of any features that rely on:
 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new platform, as
 the new platform didn't have a working phobos.

 What do you think?

It's only of interest to me in the sense that D might be able to infiltrate existing C codebases. And in practical reality, I just don't see that happening regardless. Most C codebases I have come in contact with are still C codebases because they require access to an immense number of target platforms/compilers, and D-- would never be able to integrate with all those targets, which means use of D-- alongside C would interfere with the portability of the original code. Personally, I don't want D--, I want D. I may use D-- on a microprocessor or something, it could find a good home there. But wouldn't it be better to just focus on the ability for D to link-strip any code relating to those features you list above if it turns out that they aren't referenced at all by the app? D should be able to properly eliminate everything that's not actually used by the app. I guess the flag is still useful to catch errors where a user attempting to avoid those items hits one by mistake. --001a11c2903cb0230904f22c1550 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 2 February 2014 05:43, Walter Bright <span dir=3D"ltr">&lt;<a href=3D"mailt= o:newshound2 digitalmars.com" target=3D"_blank">newshound2 digitalmars.com<= /a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">I&#39;ve toyed with this idea for a while, a= nd wondered what the interest there is in something like this.<br> <br> The idea is to be able to use a subset of D that does not require any of dr= untime or phobos - it can be linked merely with the C standard library. To = that end, there&#39;d be a compiler switch (-betterC) which would enforce t= he subset.<br> <br> (First off, I hate the name &quot;better C&quot;, any suggestions?)<br></bl= ockquote><div><br></div><div>D-- ;)</div><div><br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"> The subset would disallow use of any features that rely on:<br> <br> 1. moduleinfo<br> 2. exception handling<br> 3. gc<br> 4. Object<br> <br> I&#39;ve used such a subset before when bringing D up on a new platform, as= the new platform didn&#39;t have a working phobos.<br> <br> What do you think?<br> </blockquote></div><br></div><div class=3D"gmail_extra">It&#39;s only of in= terest to me in the sense that D might be able to infiltrate existing C cod= ebases. And in practical reality, I just don&#39;t see that happening regar= dless.</div> <div class=3D"gmail_extra">Most C codebases I have come in contact with are= still C codebases because they require access to an immense number of targ= et platforms/compilers, and D-- would never be able to integrate with all t= hose targets, which means use of D-- alongside C would interfere with the p= ortability of the original code.</div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Personally,= I don&#39;t want D--, I want D.</div><div class=3D"gmail_extra">I may use = D-- on a microprocessor or something, it could find a good home there. But = wouldn&#39;t it be better to just focus on the ability for D to link-strip = any code relating to those features you list above if it turns out that the= y aren&#39;t referenced at all by the app? D should be able to properly eli= minate everything that&#39;s not actually used by the app.</div> <div class=3D"gmail_extra">I guess the flag is still useful to catch errors= where a user attempting to avoid those items hits one by mistake.</div></d= iv> --001a11c2903cb0230904f22c1550--
Feb 11 2014
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7b5d90b57e6e3a04f22c2e34
Content-Type: text/plain; charset=UTF-8

On 12 February 2014 07:11, Walter Bright <newshound2 digitalmars.com> wrote:

 On 2/11/2014 11:43 AM, Walter Bright wrote:

 (First off, I hate the name "better C", any suggestions?)

How about "EmbeddedD", though that wouldn't be entirely accurate?

I prefer the idea already mentioned of making a more well-defined separation of D-core (static stuff), and then the rest as a higher layer. Ie, rather than 'EmbeddeD' which suggests a _removal_ of stuff, if D existed as 2 layers, then rather than removing the top layer, you're simply not adding the top layer. If that makes sense. --047d7b5d90b57e6e3a04f22c2e34 Content-Type: text/html; charset=UTF-8 <div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 12 February 2014 07:11, Walter Bright <span dir="ltr">&lt;<a href="mailto:newshound2 digitalmars.com" target="_blank">newshound2 digitalmars.com</a>&gt;</span> wrote:<br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa ding-left:1ex"><div class="">On 2/11/2014 11:43 AM, Walter Bright wrote:<br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> (First off, I hate the name &quot;better C&quot;, any suggestions?)<br> </blockquote> <br></div> How about &quot;EmbeddedD&quot;, though that wouldn&#39;t be entirely accurate?<br> </blockquote></div><br></div><div class="gmail_extra">I prefer the idea already mentioned of making a more well-defined separation of D-core (static stuff), and then the rest as a higher layer.<br></div><div class="gmail_extra"> Ie, rather than &#39;EmbeddeD&#39; which suggests a _removal_ of stuff, if D existed as 2 layers, then rather than removing the top layer, you&#39;re simply not adding the top layer. If that makes sense.</div></div> --047d7b5d90b57e6e3a04f22c2e34--
Feb 11 2014
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--e89a8f503bb2f9890204f22c3f42
Content-Type: text/plain; charset=UTF-8

On 12 February 2014 07:12, Frank Bauer <y z.com> wrote:

 Excellent idea. All the cries (including mine) for a non-GC D
 would stop at once.

No they wouldn't. This is not what I'm asking for in any of my posts. This is almost exclusively useful in tiny-embedded environments (ie, microcontrollers). Instead, we could focus on gradually bringing
 all the remaining features of D-Full into D-Core over the next
 years. Walter would have to judge on that, but to an outsider it
 looks doable without too much resources.

 And, as I firmly believe, this could make the difference between
 D getting accepted by the C++ crowd on one side and D
 disappearing from the scene as just another C# / Java clone
 (untrue, but I talk about public perception).

I don't actually think this is what the 'no GC' crowd want. C++ programmers will not be satisfied with this. They'll see it as a step backwards towards C, not forwards. --e89a8f503bb2f9890204f22c3f42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 2 February 2014 07:12, Frank Bauer <span dir=3D"ltr">&lt;<a href=3D"mailto:= y z.com" target=3D"_blank">y z.com</a>&gt;</span> wrote:<br><blockquote cla= ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa= dding-left:1ex"> Excellent idea. All the cries (including mine) for a non-GC D<br> would stop at once.</blockquote><div><br></div><div>No they wouldn&#39;t. T= his is not what I&#39;m asking for in any of my posts.</div><div>This is al= most exclusively useful in tiny-embedded environments (ie, microcontrollers= ).</div> <div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Instead, we c= ould focus on gradually bringing<br> all the remaining features of D-Full into D-Core over the next<br> years. Walter would have to judge on that, but to an outsider it<br> looks doable without too much resources.<br> <br> And, as I firmly believe, this could make the difference between<br> D getting accepted by the C++ crowd on one side and D<br> disappearing from the scene as just another C# / Java clone<br> (untrue, but I talk about public perception).<br> </blockquote></div><br></div><div class=3D"gmail_extra">I don&#39;t actuall= y think this is what the &#39;no GC&#39; crowd want. C++ programmers will n= ot be satisfied with this. They&#39;ll see it as a step backwards towards C= , not forwards.</div> </div> --e89a8f503bb2f9890204f22c3f42--
Feb 11 2014
prev sibling next sibling parent "Mike" <none none.com> writes:
On Wednesday, 12 February 2014 at 02:23:04 UTC, Manu wrote:
 On 12 February 2014 07:12, Frank Bauer <y z.com> wrote:

 Excellent idea. All the cries (including mine) for a non-GC D
 would stop at once.

No they wouldn't. This is not what I'm asking for in any of my posts. This is almost exclusively useful in tiny-embedded environments (ie, microcontrollers). Instead, we could focus on gradually bringing
 all the remaining features of D-Full into D-Core over the next
 years. Walter would have to judge on that, but to an outsider 
 it
 looks doable without too much resources.

 And, as I firmly believe, this could make the difference 
 between
 D getting accepted by the C++ crowd on one side and D
 disappearing from the scene as just another C# / Java clone
 (untrue, but I talk about public perception).

I don't actually think this is what the 'no GC' crowd want. C++ programmers will not be satisfied with this. They'll see it as a step backwards towards C, not forwards.

Seconded!
Feb 11 2014
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--089e015365e697782a04f22c694f
Content-Type: text/plain; charset=UTF-8

On 12 February 2014 09:06, Mike <none none.com> wrote:

 On Tuesday, 11 February 2014 at 20:42:26 UTC, bearophile wrote:

 Walter Bright:

  (First off, I hate the name "better C", any suggestions?)

A different name is needed.

I don't think a different name is needed, nor do I think it would be a good idea. All that's needed are a few compiler switches to enable/disable features so D can be used on more platforms. GNU g++ does this without giving it a new name (e.g. -fno-exceptions, -fno-rtti, etc...) D can do the same without giving it a new name.

+1, I support this approach. C/C++ programmers are familiar with it, and I can imagine situations where I might want some features, but not others. --089e015365e697782a04f22c694f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 2 February 2014 09:06, Mike <span dir=3D"ltr">&lt;<a href=3D"mailto:none no= ne.com" target=3D"_blank">none none.com</a>&gt;</span> wrote:<br><blockquot= e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex"> <div class=3D"">On Tuesday, 11 February 2014 at 20:42:26 UTC, bearophile wr= ote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Walter Bright:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> (First off, I hate the name &quot;better C&quot;, any suggestions?)<br> </blockquote> <br> A different name is needed.<br> </blockquote> <br></div> I don&#39;t think a different name is needed, nor do I think it would be a = good idea. =C2=A0All that&#39;s needed are a few compiler switches to enabl= e/disable features so D can be used on more platforms. =C2=A0GNU g++ does t= his without giving it a new name (e.g. -fno-exceptions, -fno-rtti, etc...) = =C2=A0D can do the same without giving it a new name.</blockquote> <div><br></div><div>+1, I support this approach. C/C++ programmers are fami= liar with it, and I can imagine situations where I might want some features= , but not others.</div></div></div></div> --089e015365e697782a04f22c694f--
Feb 11 2014
prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Walter Bright"  wrote in message news:lddug4$jgv$1 digitalmars.com...

 I've toyed with this idea for a while, and wondered what the interest 
 there is in something like this.

 The idea is to be able to use a subset of D that does not require any of 
 druntime or phobos - it can be linked merely with the C standard library. 
 To that end, there'd be a compiler switch (-betterC) which would enforce 
 the subset.

Yeah, this has been on my todo list for a long time, last time it came up it resulting in this: https://github.com/yebblies/dmd/tree/microd I would love to use this at work, although of course dmd does not support any of the architectures I need. For all the people crying about forking the language, this will only fork the language as much as safe did (ie not at all).
Feb 11 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/14, 6:47 PM, Daniel Murphy wrote:
 "Walter Bright"  wrote in message news:lddug4$jgv$1 digitalmars.com...

 I've toyed with this idea for a while, and wondered what the interest
 there is in something like this.

 The idea is to be able to use a subset of D that does not require any
 of druntime or phobos - it can be linked merely with the C standard
 library. To that end, there'd be a compiler switch (-betterC) which
 would enforce the subset.

Yeah, this has been on my todo list for a long time, last time it came up it resulting in this: https://github.com/yebblies/dmd/tree/microd I would love to use this at work, although of course dmd does not support any of the architectures I need.

Well that should raise a question about the proper priorities.
 For all the people crying about forking the language, this will only
 fork the language as much as  safe did (ie not at all).

As I told Walter: there's this joke that goes as follows. A guy goes to the doctor and the doctor asks "How is your sex life?" and the guy goes, "Almost every day!" "How do you mean that?" "Almost on Monday, almost on Tuesday, almost on Wednesday..." We almost have a working safe, we almost have good reference counting, we almost have good copy construction, we almost have a working "shared" qualifier, we almost have a solution to NonNull, we almost have complete qualifier inference, and we almost have a self-hosting compiler. Last thing we want is to add an almost working "better C" thingamaroo to the list. Andrei
Feb 11 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/12/14, 12:34 AM, Daniel Murphy wrote:
 The thing is, we do almost have it, because it's not a huge thing to
 implement.  Low hanging fruit vs long-term priorities.

There's this thing in psychology - when confronted with too many unprioritized tasks, people will consistently choose the easiest ones. Andrei
Feb 12 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/12/14, 8:49 AM, Sean Kelly wrote:
 On Wednesday, 12 February 2014 at 16:16:10 UTC, Andrei Alexandrescu wrote:
 On 2/12/14, 12:34 AM, Daniel Murphy wrote:
 The thing is, we do almost have it, because it's not a huge thing to
 implement.  Low hanging fruit vs long-term priorities.

There's this thing in psychology - when confronted with too many unprioritized tasks, people will consistently choose the easiest ones.

Yep. When overwhelmed, it's particularly welcome to be making quantifiable progress on something. Anything. And in many cases it really is worth interspersing the easy tasks with the hard ones just to keep morale up, even if those easy tasks are really not terribly important from a priorities perspective. Of course, the flip-side of that is feature creep, when too much time is spent on the low-priority easy stuff. I think every programmer needs to learn this balance at some point, as an aid to avoiding burnout.

There's always answering email and posting to forums :o). Andrei
Feb 12 2014
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/12/14, 9:20 AM, Gary Willoughby wrote:
 On Wednesday, 12 February 2014 at 16:49:46 UTC, Sean Kelly wrote:
 Yep.  When overwhelmed, it's particularly welcome to be making
 quantifiable progress on something.  Anything.  And in many cases it
 really is worth interspersing the easy tasks with the hard ones just
 to keep morale up, even if those easy tasks are really not terribly
 important from a priorities perspective. Of course, the flip-side of
 that is feature creep, when too much time is spent on the low-priority
 easy stuff.  I think every programmer needs to learn this balance at
 some point, as an aid to avoiding burnout.

Yep we need to finish and polish what we have before adding anything new. There are so many long term important bugs still not fixed. https://d.puremagic.com/issues/show_bug.cgi?id=314

Hasn't Kenji fixed that? Andrei
Feb 12 2014
prev sibling next sibling parent Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 12/02/2014 04:51, Andrei Alexandrescu wrote:
 As I told Walter: there's this joke that goes as follows. A guy goes to
 the doctor and the doctor asks "How is your sex life?" and the guy goes,
 "Almost every day!" "How do you mean that?" "Almost on Monday, almost on
 Tuesday, almost on Wednesday..."

 We almost have a working  safe, we almost have good reference counting,
 we almost have good copy construction, we almost have a working "shared"
 qualifier, we almost have a solution to NonNull, we almost have complete
 qualifier inference, and we almost have a self-hosting compiler.

Hear, hear! -- Bruno Medeiros https://twitter.com/brunodomedeiros
Feb 19 2014
prev sibling parent Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 12/02/2014 04:51, Andrei Alexandrescu wrote:
 As I told Walter: there's this joke that goes as follows. A guy goes to
 the doctor and the doctor asks "How is your sex life?" and the guy goes,
 "Almost every day!" "How do you mean that?" "Almost on Monday, almost on
 Tuesday, almost on Wednesday..."

 We almost have a working  safe, we almost have good reference counting,
 we almost have good copy construction, we almost have a working "shared"
 qualifier, we almost have a solution to NonNull, we almost have complete
 qualifier inference, and we almost have a self-hosting compiler.

Hear, hear! -- Bruno Medeiros
Feb 19 2014
prev sibling next sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
On Wednesday, 12 February 2014 at 04:52:00 UTC, Andrei 
Alexandrescu wrote:
 Well that should raise a question about the proper priorities.

My hope would be this would trickle down to GDC and I can use that.
 For all the people crying about forking the language, this 
 will only
 fork the language as much as  safe did (ie not at all).

As I told Walter: there's this joke that goes as follows. A guy goes to the doctor and the doctor asks "How is your sex life?" and the guy goes, "Almost every day!" "How do you mean that?" "Almost on Monday, almost on Tuesday, almost on Wednesday..."

"I only try on Wednesday"
 We almost have a working  safe, we almost have good reference 
 counting, we almost have good copy construction, we almost have 
 a working "shared" qualifier, we almost have a solution to 
 NonNull, we almost have complete qualifier inference, and we 
 almost have a self-hosting compiler.

I'm not planning to stop working on the self-hosting compiler, just working on the same thing constantly gets a bit boring eventually, and half the time I'm blocked waiting for Walter to approve something anyway. (Not currently!) As for the others, I implemented most of safe, and I don't really care about the rest.
 Last thing we want is to add an almost working "better C" 
 thingamaroo to the list.


 Andrei

The thing is, we do almost have it, because it's not a huge thing to implement. Low hanging fruit vs long-term priorities.
Feb 12 2014
prev sibling next sibling parent "Sean Kelly" <sean invisibleduck.org> writes:
On Wednesday, 12 February 2014 at 16:16:10 UTC, Andrei 
Alexandrescu wrote:
 On 2/12/14, 12:34 AM, Daniel Murphy wrote:
 The thing is, we do almost have it, because it's not a huge 
 thing to
 implement.  Low hanging fruit vs long-term priorities.

There's this thing in psychology - when confronted with too many unprioritized tasks, people will consistently choose the easiest ones.

Yep. When overwhelmed, it's particularly welcome to be making quantifiable progress on something. Anything. And in many cases it really is worth interspersing the easy tasks with the hard ones just to keep morale up, even if those easy tasks are really not terribly important from a priorities perspective. Of course, the flip-side of that is feature creep, when too much time is spent on the low-priority easy stuff. I think every programmer needs to learn this balance at some point, as an aid to avoiding burnout.
Feb 12 2014
prev sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Wednesday, 12 February 2014 at 16:49:46 UTC, Sean Kelly wrote:
 Yep.  When overwhelmed, it's particularly welcome to be making 
 quantifiable progress on something.  Anything.  And in many 
 cases it really is worth interspersing the easy tasks with the 
 hard ones just to keep morale up, even if those easy tasks are 
 really not terribly important from a priorities perspective.  
 Of course, the flip-side of that is feature creep, when too 
 much time is spent on the low-priority easy stuff.  I think 
 every programmer needs to learn this balance at some point, as 
 an aid to avoiding burnout.

Yep we need to finish and polish what we have before adding anything new. There are so many long term important bugs still not fixed. https://d.puremagic.com/issues/show_bug.cgi?id=314
Feb 12 2014
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
--089e0149c506a3ab0504f22d2b2b
Content-Type: text/plain; charset=UTF-8

On 12 February 2014 12:11, Manu <turkeyman gmail.com> wrote:

 On 12 February 2014 05:43, Walter Bright <newshound2 digitalmars.com>wrote:

 I've toyed with this idea for a while, and wondered what the interest
 there is in something like this.

 The idea is to be able to use a subset of D that does not require any of
 druntime or phobos - it can be linked merely with the C standard library.
 To that end, there'd be a compiler switch (-betterC) which would enforce
 the subset.

 (First off, I hate the name "better C", any suggestions?)

D-- ;) The subset would disallow use of any features that rely on:
 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new platform, as
 the new platform didn't have a working phobos.

 What do you think?

It's only of interest to me in the sense that D might be able to infiltrate existing C codebases. And in practical reality, I just don't see that happening regardless. Most C codebases I have come in contact with are still C codebases because they require access to an immense number of target platforms/compilers, and D-- would never be able to integrate with all those targets, which means use of D-- alongside C would interfere with the portability of the original code. Personally, I don't want D--, I want D. I may use D-- on a microprocessor or something, it could find a good home there. But wouldn't it be better to just focus on the ability for D to link-strip any code relating to those features you list above if it turns out that they aren't referenced at all by the app? D should be able to properly eliminate everything that's not actually used by the app. I guess the flag is still useful to catch errors where a user attempting to avoid those items hits one by mistake.

I've changed my mind. Depending on a functional link-stripper sucks. I think it's definitely useful, although I think it should be implemented as a suite of flags, not just a single one. Sure, a convenience flag can be offered, but as an implementation detail, it should be a suite of flags. --089e0149c506a3ab0504f22d2b2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 2 February 2014 12:11, Manu <span dir=3D"ltr">&lt;<a href=3D"mailto:turkeym= an gmail.com" target=3D"_blank">turkeyman gmail.com</a>&gt;</span> wrote:<b= r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:= 1px #ccc solid;padding-left:1ex"> <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div= class=3D"">On 12 February 2014 05:43, Walter Bright <span dir=3D"ltr">&lt;= <a href=3D"mailto:newshound2 digitalmars.com" target=3D"_blank">newshound2 = digitalmars.com</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">I&#39;ve toyed with this idea for a while, a= nd wondered what the interest there is in something like this.<br> <br> The idea is to be able to use a subset of D that does not require any of dr= untime or phobos - it can be linked merely with the C standard library. To = that end, there&#39;d be a compiler switch (-betterC) which would enforce t= he subset.<br> <br> (First off, I hate the name &quot;better C&quot;, any suggestions?)<br></bl= ockquote><div><br></div></div><div>D-- ;)</div><div class=3D""><div><br></d= iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left= :1px #ccc solid;padding-left:1ex"> The subset would disallow use of any features that rely on:<br> <br> 1. moduleinfo<br> 2. exception handling<br> 3. gc<br> 4. Object<br> <br> I&#39;ve used such a subset before when bringing D up on a new platform, as= the new platform didn&#39;t have a working phobos.<br> <br> What do you think?<br> </blockquote></div></div><br></div><div class=3D"gmail_extra">It&#39;s only= of interest to me in the sense that D might be able to infiltrate existing= C codebases. And in practical reality, I just don&#39;t see that happening= regardless.</div> <div class=3D"gmail_extra">Most C codebases I have come in contact with are= still C codebases because they require access to an immense number of targ= et platforms/compilers, and D-- would never be able to integrate with all t= hose targets, which means use of D-- alongside C would interfere with the p= ortability of the original code.</div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Personally,= I don&#39;t want D--, I want D.</div><div class=3D"gmail_extra">I may use = D-- on a microprocessor or something, it could find a good home there. But = wouldn&#39;t it be better to just focus on the ability for D to link-strip = any code relating to those features you list above if it turns out that the= y aren&#39;t referenced at all by the app? D should be able to properly eli= minate everything that&#39;s not actually used by the app.</div> <div class=3D"gmail_extra">I guess the flag is still useful to catch errors= where a user attempting to avoid those items hits one by mistake.</div></d= iv> </blockquote></div><br></div><div class=3D"gmail_extra">I&#39;ve changed my= mind. Depending on a functional link-stripper sucks.</div><div class=3D"gm= ail_extra">I think it&#39;s definitely useful, although I think it should b= e implemented as a suite of flags, not just a single one. Sure, a convenien= ce flag can be offered, but as an implementation detail, it should be a sui= te of flags.</div> </div> --089e0149c506a3ab0504f22d2b2b--
Feb 11 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/12/14, 7:40 AM, Sean Kelly wrote:
 This would certainly be a useful feature to have when porting, and
 Walter clearly uses it himself.  Assuming this can be done with minimal
 work, I'd say make it a DMD thing rather than a D thing in general.
 Like -profile.  And add a switch to enable it in the front-end if
 possible.  Then DMD (and potentially the other compilers) will have the
 feature in case anyone finds it useful and we can move on.  Call it
 -minimal.

 I have a feeling we've already spent more time talking about this than
 Walter would have spent implementing it anyway, so it's already taking
 time away from other things.  Let's just give it a nod and move on.

I convinced Walter of my view on this, so he won't work on it. I trust that at least between the two of us we can focus on working on what matters most first. Andrei
Feb 12 2014
next sibling parent John J <john.joyus gmail.com> writes:
On 02/12/2014 11:30 AM, Andrei Alexandrescu wrote:
 I convinced Walter of my view on this, so he won't work on it. I trust
 that at least between the two of us we can focus on working on what
 matters most first.

Too busy to innovate! ;)
Feb 12 2014
prev sibling parent 1100110 <0b1100110 gmail.com> writes:
On 2/13/14, 11:21, Steven Schveighoffer wrote:
 On Wed, 12 Feb 2014 11:30:30 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 On 2/12/14, 7:40 AM, Sean Kelly wrote:
 This would certainly be a useful feature to have when porting, and
 Walter clearly uses it himself.  Assuming this can be done with minimal
 work, I'd say make it a DMD thing rather than a D thing in general.
 Like -profile.  And add a switch to enable it in the front-end if
 possible.  Then DMD (and potentially the other compilers) will have the
 feature in case anyone finds it useful and we can move on.  Call it
 -minimal.

 I have a feeling we've already spent more time talking about this than
 Walter would have spent implementing it anyway, so it's already taking
 time away from other things.  Let's just give it a nod and move on.

I convinced Walter of my view on this, so he won't work on it. I trust that at least between the two of us we can focus on working on what matters most first.

Anyone else wish to take this up? I think pull requests would be welcome. -Steve

I'm putting a $50 dollar bounty on it. Gotta work out the details, but there it is. It's on the announcements forum. Anyone wanna chip in? I really want something like this to be implemented.
Feb 13 2014
prev sibling next sibling parent "Mike" <none none.com> writes:
On Tuesday, 11 February 2014 at 22:21:32 UTC, ed wrote:
 On Tuesday, 11 February 2014 at 22:01:01 UTC, bearophile wrote:

 I think the transition to D in the embedded world would be 
 quicker if it were possible to obtain a minimal D language that 
 produces the smallest binaries possible.

How about a 56 byte hello world [1]. Small binaries are already possible with GDC (and maybe LDC too). If you want structs and static classes, you only need a 20 line object.d file for GDC [2]. This is proving to be quite a suitable replacement for C in my current experiments. Mike [1] https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/wiki/1.1---Hello,-World! [2] https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/blob/structs/source/object.d
Feb 11 2014
prev sibling next sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 The idea is to be able to use a subset of D that does not 
 require any of druntime or phobos - it can be linked merely 
 with the C standard library. To that end, there'd be a compiler 
 switch (-betterC) which would enforce the subset.

I think it should be something acceptable for mainline, but should be the pursuit of those who are going to use it to implement it (unless other things finished). I can not speak to the usefulness of this as I don't see myself as a user, but it sounds like something which will be desired by many (but I expect their to be other blockades preventing it from being a major growth to D).
Feb 11 2014
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Wednesday, 12 February 2014 at 03:28:57 UTC, Manu wrote:
 On 12 February 2014 12:11, Manu <turkeyman gmail.com> wrote:

 On 12 February 2014 05:43, Walter Bright 
 <newshound2 digitalmars.com>wrote:


 I've changed my mind. Depending on a functional link-stripper 
 sucks.
 I think it's definitely useful, although I think it should be 
 implemented
 as a suite of flags, not just a single one. Sure, a convenience 
 flag can be
 offered, but as an implementation detail, it should be a suite 
 of flags.

I like this and I also think providing compiler switches (ie. without naming the subset) as being acceptable. However, what if I would need those switches for just one particular module and the functions therein? How to compile only those modules with the switches? Only through manual compile/linking?
Feb 11 2014
prev sibling next sibling parent "Nicolas Sicard" <dransic gmail.com> writes:
On Tuesday, 11 February 2014 at 21:19:36 UTC, Walter Bright wrote:
 On 2/11/2014 1:00 PM, Brian Rogoff wrote:
 Which D metaprogramming (templates, mixins, ctfe, ..) features 
 would be in this
 D subset?

All of them.

And would all of D features be available at compile time? CTFE/string mixins seem to be rather limited if features relying on the GC are excluded.
Feb 12 2014
prev sibling next sibling parent "Mike" <none none.com> writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 I've used such a subset before when bringing D up on a new 
 platform, as the new platform didn't have a working phobos.

Why would a working phobos prevent bringing D to a new platform. Did you mean the "D Runtime"? Mike
Feb 12 2014
prev sibling next sibling parent Jordi Sayol <g.sayol yahoo.es> writes:
El 11/02/14 20:43, Walter Bright ha escrit:
 (First off, I hate the name "better C", any suggestions?)

DonC -- Jordi Sayol
Feb 12 2014
prev sibling next sibling parent "Dominikus Dittes Scherkl" writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 I've toyed with this idea for a while, and wondered what the 
 interest there is in something like this.

 The idea is to be able to use a subset of D that does not 
 require any of druntime or phobos - it can be linked merely 
 with the C standard library. To that end, there'd be a compiler 
 switch (-betterC) which would enforce the subset.

-noPhobos The language itself shouldn't use a different name, if you need to refer to it, I'd suggest to call it "d" (small D). I find the idea intriguing - it could be useful pretty much everywhere where still C is in use despite C++ exists for more than two decades, not to mention other languages.
Feb 12 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 I've toyed with this idea for a while, and wondered what the 
 interest there is in something like this.

 The idea is to be able to use a subset of D that does not 
 require any of druntime or phobos - it can be linked merely 
 with the C standard library. To that end, there'd be a compiler 
 switch (-betterC) which would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

-DinC (= D Inc.) -bareD -Dwalk (as opposed to D run(time)) ouch! (Disclaimer: I haven't read all comments, the names might already have been suggested)
 What do you think?

I like the idea.
Feb 12 2014
prev sibling next sibling parent "Andrea Fontana" <nospam example.com> writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 (First off, I hate the name "better C", any suggestions?)

Too bad C+ is already taken.
 What do you think?

Good idea, but I'm afraid that a new phobos-like library will born. We have a better C with a old-style stdc library? I don't think I'm going to use "C+" with printf(), fopen(), fclose() and their old code style and syntax and I'll finish writing some wrappers over them using the d-power. Probably that's good for platform like arduino where c std library is not used... Or maybe we should provide some basic wrappers over stdc library using d-style.
Feb 12 2014
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c1d7e06a8a2504f23635d4
Content-Type: text/plain; charset=UTF-8

On 12 February 2014 16:11, eles <eles eles.com> wrote:

 On Wednesday, 12 February 2014 at 03:28:57 UTC, Manu wrote:

 On 12 February 2014 12:11, Manu <turkeyman gmail.com> wrote:

  On 12 February 2014 05:43, Walter Bright <newshound2 digitalmars.com>
 wrote:


 I've changed my mind. Depending on a functional link-stripper sucks.
 I think it's definitely useful, although I think it should be implemented
 as a suite of flags, not just a single one. Sure, a convenience flag can
 be
 offered, but as an implementation detail, it should be a suite of flags.

I like this and I also think providing compiler switches (ie. without naming the subset) as being acceptable. However, what if I would need those switches for just one particular module and the functions therein? How to compile only those modules with the switches? Only through manual compile/linking?

Yes, exactly as with C++ today. It shouldn't be an unfamiliar problem to most. --001a11c1d7e06a8a2504f23635d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 2 February 2014 16:11, eles <span dir=3D"ltr">&lt;<a href=3D"mailto:eles el= es.com" target=3D"_blank">eles eles.com</a>&gt;</span> wrote:<br><blockquot= e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex"> <div class=3D"">On Wednesday, 12 February 2014 at 03:28:57 UTC, Manu wrote:= <br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D""> On 12 February 2014 12:11, Manu &lt;<a href=3D"mailto:turkeyman gmail.com" = target=3D"_blank">turkeyman gmail.com</a>&gt; wrote:<br> <br> </div><div class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0= 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 12 February 2014 05:43, Walter Bright &lt;<a href=3D"mailto:newshound2 d= igitalmars.com" target=3D"_blank">newshound2 digitalmars.com</a>&gt;<u></u>= wrote:<br> <br> </blockquote></div></blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br><div class=3D""> I&#39;ve changed my mind. Depending on a functional link-stripper sucks.<br=

ed<br> as a suite of flags, not just a single one. Sure, a convenience flag can be= <br> offered, but as an implementation detail, it should be a suite of flags.<br=

<br> I like this and I also think providing compiler switches (ie. without namin= g the subset) as being acceptable.<br> <br> However, what if I would need those switches for just one particular module= and the functions therein? How to compile only those modules with the swit= ches?<br> <br> Only through manual compile/linking?<br> </blockquote></div><br></div><div class=3D"gmail_extra">Yes, exactly as wit= h C++ today. It shouldn&#39;t be an unfamiliar problem to most.</div></div> --001a11c1d7e06a8a2504f23635d4--
Feb 12 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 12 February 2014 at 14:15:55 UTC, Manu wrote:
 On 12 February 2014 16:11, eles <eles eles.com> wrote:

 On Wednesday, 12 February 2014 at 03:28:57 UTC, Manu wrote:

 On 12 February 2014 12:11, Manu <turkeyman gmail.com> wrote:

  On 12 February 2014 05:43, Walter Bright 
 <newshound2 digitalmars.com>
 wrote:


 I've changed my mind. Depending on a functional link-stripper 
 sucks.
 I think it's definitely useful, although I think it should be 
 implemented
 as a suite of flags, not just a single one. Sure, a 
 convenience flag can
 be
 offered, but as an implementation detail, it should be a 
 suite of flags.

I like this and I also think providing compiler switches (ie. without naming the subset) as being acceptable. However, what if I would need those switches for just one particular module and the functions therein? How to compile only those modules with the switches? Only through manual compile/linking?

Yes, exactly as with C++ today. It shouldn't be an unfamiliar problem to most.

How does that work with templates across modules?
Feb 12 2014
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c1e676570e6e04f2367ef3
Content-Type: text/plain; charset=UTF-8

On 13 February 2014 00:25, John Colvin <john.loughran.colvin gmail.com>wrote:

 On Wednesday, 12 February 2014 at 14:15:55 UTC, Manu wrote:

 On 12 February 2014 16:11, eles <eles eles.com> wrote:

  On Wednesday, 12 February 2014 at 03:28:57 UTC, Manu wrote:
  On 12 February 2014 12:11, Manu <turkeyman gmail.com> wrote:
  On 12 February 2014 05:43, Walter Bright <newshound2 digitalmars.com>

 wrote:


 I think it's definitely useful, although I think it should be
 implemented
 as a suite of flags, not just a single one. Sure, a convenience flag can
 be
 offered, but as an implementation detail, it should be a suite of flags.

naming the subset) as being acceptable. However, what if I would need those switches for just one particular module and the functions therein? How to compile only those modules with the switches? Only through manual compile/linking?

most.

How does that work with templates across modules?

I'm not sure how that would affect anything? Only a couple of runtime things would be unavailable, and ideally individually unavailable on different flags. --001a11c1e676570e6e04f2367ef3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 3 February 2014 00:25, John Colvin <span dir=3D"ltr">&lt;<a href=3D"mailto:= john.loughran.colvin gmail.com" target=3D"_blank">john.loughran.colvin gmai= l.com</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">On Wednesday, 12 February 2014 at 14:15:55 U= TC, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 12 February 2014 16:11, eles &lt;<a href=3D"mailto:eles eles.com" target= =3D"_blank">eles eles.com</a>&gt; wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Wednesday, 12 February 2014 at 03:28:57 UTC, Manu wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 12 February 2014 12:11, Manu &lt;<a href=3D"mailto:turkeyman gmail.com" = target=3D"_blank">turkeyman gmail.com</a>&gt; wrote:<br> <br> =C2=A0On 12 February 2014 05:43, Walter Bright &lt;<a href=3D"mailto:newsho= und2 digitalmars.com" target=3D"_blank">newshound2 digitalmars.com</a>&gt;<= br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> wrote:<br> <br> <br> </blockquote></blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I&#39;ve changed my mind. Depending on a functional link-stripper sucks.<br=

ed<br> as a suite of flags, not just a single one. Sure, a convenience flag can<br=

offered, but as an implementation detail, it should be a suite of flags.<br=

</blockquote> <br> I like this and I also think providing compiler switches (ie. without<br> naming the subset) as being acceptable.<br> <br> However, what if I would need those switches for just one particular<br> module and the functions therein? How to compile only those modules with<br=

<br> Only through manual compile/linking?<br> <br> </blockquote> <br> Yes, exactly as with C++ today. It shouldn&#39;t be an unfamiliar problem t= o<br> most.<br> </blockquote> <br> How does that work with templates across modules?<br> </blockquote></div><br></div><div class=3D"gmail_extra">I&#39;m not sure ho= w that would affect anything? Only a couple of runtime things would be unav= ailable, and ideally individually unavailable on different flags.</div></di= v> --001a11c1e676570e6e04f2367ef3--
Feb 12 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 12 February 2014 at 14:36:21 UTC, Manu wrote:
 On 13 February 2014 00:25, John Colvin 
 <john.loughran.colvin gmail.com>wrote:

 On Wednesday, 12 February 2014 at 14:15:55 UTC, Manu wrote:

 On 12 February 2014 16:11, eles <eles eles.com> wrote:

  On Wednesday, 12 February 2014 at 03:28:57 UTC, Manu wrote:
  On 12 February 2014 12:11, Manu <turkeyman gmail.com> wrote:
  On 12 February 2014 05:43, Walter Bright 
 <newshound2 digitalmars.com>

 wrote:


link-stripper sucks.
 I think it's definitely useful, although I think it should 
 be
 implemented
 as a suite of flags, not just a single one. Sure, a 
 convenience flag can
 be
 offered, but as an implementation detail, it should be a 
 suite of flags.

(ie. without naming the subset) as being acceptable. However, what if I would need those switches for just one particular module and the functions therein? How to compile only those modules with the switches? Only through manual compile/linking?

problem to most.

How does that work with templates across modules?

I'm not sure how that would affect anything? Only a couple of runtime things would be unavailable, and ideally individually unavailable on different flags.

What I mean is: template in module A that needs one of these flags is instantiated from module B that needs to *not* have that flag.
Feb 12 2014
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Wed, 12 Feb 2014 14:37:53 +0000
schrieb "John Colvin" <john.loughran.colvin gmail.com>:

 
 What I mean is: template in module A that needs one of these 
 flags is instantiated from module B that needs to *not* have that 
 flag.

The template is emitted to the object file of module B, so only the flags used with B matter and as long as 'these flags' are a strict subset, it's always possible to use the same code in standard D. (It is kinda important that we produce the same code in both cases though - otherwise weird things can happen if the linker merges template instances)
Feb 12 2014
prev sibling next sibling parent "Sean Kelly" <sean invisibleduck.org> writes:
This would certainly be a useful feature to have when porting, 
and Walter clearly uses it himself.  Assuming this can be done 
with minimal work, I'd say make it a DMD thing rather than a D 
thing in general.  Like -profile.  And add a switch to enable it 
in the front-end if possible.  Then DMD (and potentially the 
other compilers) will have the feature in case anyone finds it 
useful and we can move on.  Call it -minimal.

I have a feeling we've already spent more time talking about this 
than Walter would have spent implementing it anyway, so it's 
already taking time away from other things.  Let's just give it a 
nod and move on.
Feb 12 2014
prev sibling next sibling parent "Brian Rogoff" <brogoff gmail.com> writes:
On Wednesday, 12 February 2014 at 15:40:54 UTC, Sean Kelly wrote:
 This would certainly be a useful feature to have when porting, 
 and Walter clearly uses it himself.  Assuming this can be done 
 with minimal work, I'd say make it a DMD thing rather than a D 
 thing in general.  Like -profile.  And add a switch to enable 
 it in the front-end if possible.  Then DMD (and potentially the 
 other compilers) will have the feature in case anyone finds it 
 useful and we can move on.  Call it -minimal.

Good compiler flag name choice.
 I have a feeling we've already spent more time talking about 
 this than Walter would have spent implementing it anyway, so 
 it's already taking time away from other things.  Let's just 
 give it a nod and move on.

By 'nod' you mean Bugzilla entry, right? The flag would have to be documented. While "better C" is descriptive, it's not very helpful. I like the idea a lot. If it's truly low hanging fruit, then yeah it should be done, but I get the concerns that others have about D and unfinished business. Tough decision!
Feb 12 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Wednesday, 12 February 2014 at 16:30:29 UTC, Andrei 
Alexandrescu wrote:
 On 2/12/14, 7:40 AM, Sean Kelly wrote:
 This would certainly be a useful feature to have when porting, 
 and
 Walter clearly uses it himself.  Assuming this can be done 
 with minimal
 work, I'd say make it a DMD thing rather than a D thing in 
 general.
 Like -profile.  And add a switch to enable it in the front-end 
 if
 possible.  Then DMD (and potentially the other compilers) will 
 have the
 feature in case anyone finds it useful and we can move on.  
 Call it
 -minimal.

 I have a feeling we've already spent more time talking about 
 this than
 Walter would have spent implementing it anyway, so it's 
 already taking
 time away from other things.  Let's just give it a nod and 
 move on.

I convinced Walter of my view on this, so he won't work on it. I trust that at least between the two of us we can focus on working on what matters most first. Andrei

But keep -minimal in mind. A good idea, both the concept and the flag name.
Feb 12 2014
prev sibling next sibling parent John J <john.joyus gmail.com> writes:
On 02/11/2014 02:43 PM, Walter Bright wrote:
 I've toyed with this idea for a while, and wondered what the interest
 there is in something like this.

 The idea is to be able to use a subset of D that does not require any of
 druntime or phobos - it can be linked merely with the C standard
 library. To that end, there'd be a compiler switch (-betterC) which
 would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

A new switch? -OnlyC A new language? CD
Feb 12 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 12 February 2014 at 16:30:29 UTC, Andrei 
Alexandrescu wrote:
 I convinced Walter of my view on this, so he won't work on it. 
 I trust that at least between the two of us we can focus on 
 working on what matters most first.

 Andrei

Cruel world :)
Feb 12 2014
prev sibling next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Wednesday, 12 February 2014 at 16:30:29 UTC, Andrei 
Alexandrescu wrote:
 I convinced Walter of my view on this, so he won't work on it. 
 I trust that at least between the two of us we can focus on 
 working on what matters most first.

 Andrei

Thank god! Splintering the community, causing confusion and diverting effort between these would of been a nightmare for the popularity and up-take of D, especially as real interest is starting to be shown from across the board. Plus, there's no real reason why after the allocator/arc/gc changes are made D will be able to fill this niche itself. I had nightmares of a new Phobos/Tango war being created for small D. :/
Feb 12 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-02-11 20:43, Walter Bright wrote:
 I've toyed with this idea for a while, and wondered what the interest
 there is in something like this.

 The idea is to be able to use a subset of D that does not require any of
 druntime or phobos - it can be linked merely with the C standard
 library. To that end, there'd be a compiler switch (-betterC) which
 would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

-no-runtime
 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new platform, as
 the new platform didn't have a working phobos.

 What do you think?

I don't mind it. Funny thing tough: complaining that warnings are not good because they would create a separate language. Then I see this proposal. -- /Jacob Carlborg
Feb 12 2014
parent "Tove" <tove fransson.se> writes:
On Wednesday, 12 February 2014 at 20:10:42 UTC, Jacob Carlborg 
wrote:
 (First off, I hate the name "better C", any suggestions?)

-no-runtime

good choice and even if Walter is blocked on higher prio issues, we can still make it happen as a community.
Feb 12 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 12 Feb 2014 11:30:30 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 2/12/14, 7:40 AM, Sean Kelly wrote:
 This would certainly be a useful feature to have when porting, and
 Walter clearly uses it himself.  Assuming this can be done with minimal
 work, I'd say make it a DMD thing rather than a D thing in general.
 Like -profile.  And add a switch to enable it in the front-end if
 possible.  Then DMD (and potentially the other compilers) will have the
 feature in case anyone finds it useful and we can move on.  Call it
 -minimal.

 I have a feeling we've already spent more time talking about this than
 Walter would have spent implementing it anyway, so it's already taking
 time away from other things.  Let's just give it a nod and move on.

I convinced Walter of my view on this, so he won't work on it. I trust that at least between the two of us we can focus on working on what matters most first.

Anyone else wish to take this up? I think pull requests would be welcome. -Steve
Feb 13 2014
prev sibling next sibling parent reply "inout" <inout gmail.com> writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 I've toyed with this idea for a while, and wondered what the 
 interest there is in something like this.

 The idea is to be able to use a subset of D that does not 
 require any of druntime or phobos - it can be linked merely 
 with the C standard library. To that end, there'd be a compiler 
 switch (-betterC) which would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new 
 platform, as the new platform didn't have a working phobos.

 What do you think?

-no-moduleinfo -no-exceptions -no-gc -no-object There is absolutely NO need to give any name to that beast. Otherwise, it's an excellent idea! You could still use classes e.g. with C++ linkage.
Feb 13 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 13.02.2014 19:06, schrieb inout:
 On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 I've toyed with this idea for a while, and wondered what the interest
 there is in something like this.

 The idea is to be able to use a subset of D that does not require any
 of druntime or phobos - it can be linked merely with the C standard
 library. To that end, there'd be a compiler switch (-betterC) which
 would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new platform,
 as the new platform didn't have a working phobos.

 What do you think?

-no-moduleinfo -no-exceptions -no-gc -no-object There is absolutely NO need to give any name to that beast. Otherwise, it's an excellent idea! You could still use classes e.g. with C++ linkage.

Can we also get a build tool that produces all combinations for libraries distributed in binary form? -- Paulo
Feb 13 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 13.02.2014 20:51, schrieb Dicebot:
 On Thursday, 13 February 2014 at 19:47:33 UTC, Paulo Pinto wrote:
 Can we also get a build tool that produces all combinations for
 libraries distributed in binary form?

distributing binary libraries for barebone? that sounds unusual.

Why so?
Feb 13 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 The subset would disallow use of any features that rely on:

I found it manageable to write bare metal code with stock LDC and no additional options. It doesn't require C runtime, malloc is only 6 lines and returns ubyte[] already. LDC actually had -noruntime option, which was only getting in the way. Some functions from druntime are useful, e.g. _d_array_cast_len, which allows simple casting between different types of buffers.
 1. moduleinfo

I use bounds checks, and they call _d_array_bounds, which takes ModuleInfo as a parameter. How it would work?
 2. exception handling

I think asserts are sort of useful.
 4. Object

I didn't try to use objects without GC, but don't see any particular issue.
 I've used such a subset before when bringing D up on a new 
 platform, as the new platform didn't have a working phobos.

 What do you think?

Not urgent: LDC already allows me to use D without druntime, phobos and C library.
Feb 13 2014
prev sibling next sibling parent "Rel" <relmail rambler.ru> writes:
On Thursday, 13 February 2014 at 18:07:00 UTC, inout wrote:
 -no-moduleinfo
 -no-exceptions
 -no-gc
 -no-object

 There is absolutely NO need to give any name to that beast.
 Otherwise, it's an excellent idea!
 You could still use classes e.g. with C++ linkage.

I've been waiting for these features in D for such a long time! I really hope that finally it will be possible to use D for osdev, embedded programming, drivers, kernel modules, high performant games and etc without struggling with druntime and phobos!
Feb 13 2014
prev sibling next sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 I've toyed with this idea for a while, and wondered what the 
 interest there is in something like this.

 The idea is to be able to use a subset of D that does not 
 require any of druntime or phobos - it can be linked merely 
 with the C standard library. To that end, there'd be a compiler 
 switch (-betterC) which would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new 
 platform, as the new platform didn't have a working phobos.

 What do you think?

I think this is a good idea, and I believe a good result can come up from some further brainstorming. A new, potential name for it: Diny (made from "D" and "tiny", pronounced similar to "deeny") I would, however, rather have a normal D compiler being able to completely disable GC, exception handling, etc. However, I think it may be good to have modules...
Feb 13 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 13 February 2014 at 18:38:20 UTC, Kagamin wrote:
 I use bounds checks, and they call _d_array_bounds, which takes 
 ModuleInfo as a parameter. How it would work?

I think it is a mistake for it to take ModuleInfo at all. Those arguments should be removed entirely.
Feb 13 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 13 February 2014 at 19:47:33 UTC, Paulo Pinto wrote:
 Can we also get a build tool that produces all combinations for 
 libraries distributed in binary form?

distributing binary libraries for barebone? that sounds unusual.
Feb 13 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 13 February 2014 at 20:12:36 UTC, Paulo Pinto wrote:
 distributing binary libraries for barebone? that sounds 
 unusual.

Why so?

untypical hardware + desire to get most of it makes hard to provide binary distributions that can be simply linked to. Only platform SDK's come to my mind but those don't need to support all possible options - instead they define only "right" ones to use. Well, at least that was small observation of C barebone world I have managed to tackle.
Feb 13 2014
prev sibling next sibling parent "Mike" <none none.com> writes:
On Thursday, 13 February 2014 at 20:34:50 UTC, Dicebot wrote:
 On Thursday, 13 February 2014 at 20:12:36 UTC, Paulo Pinto 
 wrote:
 distributing binary libraries for barebone? that sounds 
 unusual.

Why so?

untypical hardware + desire to get most of it makes hard to provide binary distributions that can be simply linked to. Only platform SDK's come to my mind but those don't need to support all possible options - instead they define only "right" ones to use. Well, at least that was small observation of C barebone world I have managed to tackle.

SDKs and BSPs are the norm in my industry, but some libraries are out there (http://www.segger.com/pricing.html)... and they are expensive. But I think they are usually source releases.
Feb 13 2014
prev sibling next sibling parent Jerry <jlquinn optonline.net> writes:
Manu <turkeyman gmail.com> writes:

 I don't actually think this is what the 'no GC' crowd want. C++ programmers
 will not be satisfied with this. They'll see it as a step backwards towards C,
 not forwards.

I have to agree with this. I was attracted to D by the better C++ possibilities. I still want that. And I would like to see the gc be as performant as possible, and be relatively easy to avoid in bottlenecks. I don't work on real time systems, but throughput and not hammering the memory bus matters a lot. Jerry
Feb 13 2014
prev sibling next sibling parent "inout" <inout gmail.com> writes:
On Thursday, 13 February 2014 at 19:47:33 UTC, Paulo Pinto wrote:
 Am 13.02.2014 19:06, schrieb inout:
 On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright 
 wrote:
 I've toyed with this idea for a while, and wondered what the 
 interest
 there is in something like this.

 The idea is to be able to use a subset of D that does not 
 require any
 of druntime or phobos - it can be linked merely with the C 
 standard
 library. To that end, there'd be a compiler switch (-betterC) 
 which
 would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new 
 platform,
 as the new platform didn't have a working phobos.

 What do you think?

-no-moduleinfo -no-exceptions -no-gc -no-object There is absolutely NO need to give any name to that beast. Otherwise, it's an excellent idea! You could still use classes e.g. with C++ linkage.

Can we also get a build tool that produces all combinations for libraries distributed in binary form? -- Paulo

These could be linker flags. If you distribute your library as a .lib, all of those could be present (and only stripped at link-time).
Feb 13 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Thursday, 13 February 2014 at 19:09:21 UTC, Adam D. Ruppe 
wrote:
 On Thursday, 13 February 2014 at 18:38:20 UTC, Kagamin wrote:
 I use bounds checks, and they call _d_array_bounds, which 
 takes ModuleInfo as a parameter. How it would work?

I think it is a mistake for it to take ModuleInfo at all. Those arguments should be removed entirely.

_d_array_bounds must report the location of error, so it should take ModuleInfo and line number to report, where it happened.
Feb 14 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 14 February 2014 at 17:21:09 UTC, Kagamin wrote:
 _d_array_bounds must report the location of error, so it should 
 take ModuleInfo and line number to report, where it happened.

It could simply take a string. That's all druntime does anyway: fetch m.name from moduleinfo then proceed normally.
Feb 14 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Friday, 14 February 2014 at 17:37:20 UTC, Adam D. Ruppe wrote:
 On Friday, 14 February 2014 at 17:21:09 UTC, Kagamin wrote:
 _d_array_bounds must report the location of error, so it 
 should take ModuleInfo and line number to report, where it 
 happened.

It could simply take a string. That's all druntime does anyway: fetch m.name from moduleinfo then proceed normally.

With single pointer the calling code is more minimal. Also it's more conceptual: D is module-oriented and with module name you don't need file name. What's problem with moduleinfo? It's only 8 bytes + module name.
Feb 15 2014
prev sibling next sibling parent "exord" <exord live.cn> writes:
Cool, this is what I have been seeking for several years.

I have to face C everyday totally because my work needs it.
But I hate it!

Actually, before I know D, I have written down a C#-style 
codegenerator to convert a subset of C# codes to C codes. That's 
convinient for me and I really don't need some advance features 
such as GC, runtime support and library support.I don't need a 
full framwork, I just needs a language.

When I first had a glance of D, I think it is what I need. I 
don't need to write down a separate include file and I have 
well-orged namespace, and most fantasict thing is it compiles to 
native binary!

But as I looked into more, I think D are becoming more and more 
complex. Even to learn it will take someone lots of time. If we 
can prvide several variants or subsets will be helpful, such for 
system developer/web developer, they will only need to learn the 
things releated their variant.



On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 I've toyed with this idea for a while, and wondered what the 
 interest there is in something like this.

 The idea is to be able to use a subset of D that does not 
 require any of druntime or phobos - it can be linked merely 
 with the C standard library. To that end, there'd be a compiler 
 switch (-betterC) which would enforce the subset.

 (First off, I hate the name "better C", any suggestions?)

 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new 
 platform, as the new platform didn't have a working phobos.

 What do you think?

Feb 16 2014
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Tue, 11 Feb 2014 11:43:02 -0800
schrieb Walter Bright <newshound2 digitalmars.com>:

 I've toyed with this idea for a while, and wondered what the interest there is 
 in something like this.
 
 The idea is to be able to use a subset of D that does not require any of 
 druntime or phobos - it can be linked merely with the C standard library. To 
 that end, there'd be a compiler switch (-betterC) which would enforce the
subset.
 
 (First off, I hate the name "better C", any suggestions?)
 
 The subset would disallow use of any features that rely on:
 
 1. moduleinfo
 2. exception handling
 3. gc
 4. Object
 
 I've used such a subset before when bringing D up on a new platform, as the
new 
 platform didn't have a working phobos.
 
 What do you think?

That sounds like it has use cases and doesn't create anything new, just restrict the feature set like safe. I expect that it is much easier to port D to all kinds of platforms where it is a lot of work or even impossible to implement all of D's features. Since objects and the GC are out, it means that D threads are also out. What about TLS? It has proven difficult on previous MacOS X versions already and might cause trouble on other platforms. This morning I talked with my father about the use of Python in controlling motors and sensors for the saws he is constructing at work. I don't know how Python works on such an embedded platform, but I could see "better C" there as well. Especially since Python did cause trouble when real time feedback was required. -- Marco
Feb 17 2014
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Tue, 11 Feb 2014 21:12:12 +0000
schrieb "bearophile" <bearophileHUGS lycos.com>:

 Steven Schveighoffer:
 
 I think you overestimate the size of this project.

The "project" is very small as long as people don't start creating (or modifying) library modules for such language subset. Bye, bearophile

Well, the idea was not to use druntime and Phobos, so no code has to be modified there other than to allow stripping down D. Any new library has to be written by the embedded guys :) It could serve to check the basic language features against the realities of the embedded market early on. </wild_guess> -- Marco
Feb 17 2014
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Wed, 12 Feb 2014 03:50:58 +0000
schrieb "Mike" <none none.com>:

 On Tuesday, 11 February 2014 at 22:21:32 UTC, ed wrote:
 On Tuesday, 11 February 2014 at 22:01:01 UTC, bearophile wrote:

 I think the transition to D in the embedded world would be 
 quicker if it were possible to obtain a minimal D language that 
 produces the smallest binaries possible.

How about a 56 byte hello world [1]. Small binaries are already possible with GDC (and maybe LDC too). If you want structs and static classes, you only need a 20 line object.d file for GDC [2]. This is proving to be quite a suitable replacement for C in my current experiments. Mike [1] https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/wiki/1.1---Hello,-World! [2] https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/blob/structs/source/object.d

That's an awesome proof of concept. -- Marco
Feb 17 2014
prev sibling next sibling parent "Rel" <relmail rambler.ru> writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new 
 platform, as the new platform didn't have a working phobos.

 What do you think?

lot of people were begging for it for a long time. Obviously I'd like to have this feature in D because it would finally allow game, embedded, system (and operating system) developers to use good, modern and beautiful language for their needs. As for me I've been waiting for this for a long time. Hacking on compiler and phobos in order to make it generate stdlib-indepentent code may be interesting from time to time, but keeping such kind of project up-to-date with each new version of the compiler can be quite hard. Supporting a subset of D language features suitable for system/embedded programming and porting seems to be the best decision in this case.
Feb 18 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 18 February 2014 at 12:20:52 UTC, Rel wrote:
 So may I ask, what is official decision on the subject? Quite a 
 lot of people were begging for it for a long time. Obviously 
 I'd like to have this feature in D because it would finally 
 allow game, embedded, system (and operating system) developers 
 to use good, modern and beautiful language for their needs.

Don't overexpect - it will make experiments easier in that direction but is not necessarily an enabler proposal. Its importance is rated too high in that regard. That said, official resolution seems to be "have good chance of being accepted if anything else implements it, but Walter won't spend time personally"
Feb 18 2014
prev sibling next sibling parent "Tim Krimm" <invalidEmail 123.com> writes:
On Tuesday, 18 February 2014 at 12:20:52 UTC, Rel wrote:
 On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright 
 wrote:
 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new 
 platform, as the new platform didn't have a working phobos.

 What do you think?

lot of people were begging for it for a long time. Obviously I'd like to have this feature in D because it would finally allow game, embedded, system (and operating system) developers to use good, modern and beautiful language for their needs. As for me I've been waiting for this for a long time. Hacking on compiler and phobos in order to make it generate stdlib-indepentent code may be interesting from time to time, but keeping such kind of project up-to-date with each new version of the compiler can be quite hard. Supporting a subset of D language features suitable for system/embedded programming and porting seems to be the best decision in this case.

I have also been waiting for something like this for a long time.
Feb 19 2014
prev sibling parent "Rel" <relmail rambler.ru> writes:
On Wednesday, 19 February 2014 at 15:46:38 UTC, Tim Krimm wrote:
 On Tuesday, 18 February 2014 at 12:20:52 UTC, Rel wrote:
 On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright 
 wrote:
 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object

 I've used such a subset before when bringing D up on a new 
 platform, as the new platform didn't have a working phobos.

 What do you think?

a lot of people were begging for it for a long time. Obviously I'd like to have this feature in D because it would finally allow game, embedded, system (and operating system) developers to use good, modern and beautiful language for their needs. As for me I've been waiting for this for a long time. Hacking on compiler and phobos in order to make it generate stdlib-indepentent code may be interesting from time to time, but keeping such kind of project up-to-date with each new version of the compiler can be quite hard. Supporting a subset of D language features suitable for system/embedded programming and porting seems to be the best decision in this case.

I have also been waiting for something like this for a long time.

number of features, that are not dependent on runtime, then improve the language by adding features supported by runtime library. Too bad that D doesn't officially support a subset without runtime depemdencies, so we have to either use C/C++ or keep on trying to hack on of D compilers. On the other hand Rust can be used without runtime libraries.
Mar 20 2014