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

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

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

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

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.

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.

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?

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.

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

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