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?

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

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

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.

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.

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.

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

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

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

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.