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

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 é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.
>>
> Object isn't only for runtime type info and others basics properties of 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

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

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

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.

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

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

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

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

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.