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

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.

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?

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

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

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

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

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"

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

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