www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D-

reply "Tim Krimm" <twkrimm yahoo.com> writes:
We have C and C++

How about D- and D?

D- would be the have a similar use as today's C compilers.

===========================
Why create this language?
===========================

Well I would love to have a D compiler that supports 
microcontrollers.
The ones that have say 32 K of RAM and 64K of FLASH.
A language that is targeted for embedded and/or low resource 
environments.
It would be nice to have a modern language for low resource 
environments.

A potential way to implement this language is to use the DMD 
frontend,
then flag the unsupported features of D,
Next create a backend, like "C front" that outputs C code instead 
of assembler.


===========================
What do I envision with D-,
D-- or Dm or what ever you want to call it.
===========================

This language would basically be D without the garbage collection.
For example there would be structures but no classes.
There would be regular arrays but no dynamic arrays.
Code that is mostly equivalent to C, but you would still have 
structures with functions and overloading support,
and other features like templates etc.

I think you get the idea.

What are your thoughts?
Feb 10 2012
next sibling parent reply Zachary Lund <admin computerquip.com> writes:
On 02/10/2012 01:02 PM, Tim Krimm wrote:
 We have C and C++

 How about D- and D?

 D- would be the have a similar use as today's C compilers.

 ===========================
 Why create this language?
 ===========================

 Well I would love to have a D compiler that supports microcontrollers.
 The ones that have say 32 K of RAM and 64K of FLASH.
 A language that is targeted for embedded and/or low resource environments.
 It would be nice to have a modern language for low resource environments.

 A potential way to implement this language is to use the DMD frontend,
 then flag the unsupported features of D,
 Next create a backend, like "C front" that outputs C code instead of
 assembler.


 ===========================
 What do I envision with D-,
 D-- or Dm or what ever you want to call it.
 ===========================

 This language would basically be D without the garbage collection.
 For example there would be structures but no classes.
 There would be regular arrays but no dynamic arrays.
 Code that is mostly equivalent to C, but you would still have structures
 with functions and overloading support,
 and other features like templates etc.

 I think you get the idea.

 What are your thoughts?

I would love this as well. I *think* you wouldn't have to recreate the language, just recreate the runtime. You can currently use D and can completely avoid the use of the GC by just using static functions. From what I understand, dynamic arrays are also controlled and provided through the runtime. You can also export C symbols if you wanted to.
Feb 10 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-02-10 20:23, Zachary Lund wrote:
 On 02/10/2012 01:02 PM, Tim Krimm wrote:
 We have C and C++

 How about D- and D?

 D- would be the have a similar use as today's C compilers.

 ===========================
 Why create this language?
 ===========================

 Well I would love to have a D compiler that supports microcontrollers.
 The ones that have say 32 K of RAM and 64K of FLASH.
 A language that is targeted for embedded and/or low resource
 environments.
 It would be nice to have a modern language for low resource environments.

 A potential way to implement this language is to use the DMD frontend,
 then flag the unsupported features of D,
 Next create a backend, like "C front" that outputs C code instead of
 assembler.


 ===========================
 What do I envision with D-,
 D-- or Dm or what ever you want to call it.
 ===========================

 This language would basically be D without the garbage collection.
 For example there would be structures but no classes.
 There would be regular arrays but no dynamic arrays.
 Code that is mostly equivalent to C, but you would still have structures
 with functions and overloading support,
 and other features like templates etc.

 I think you get the idea.

 What are your thoughts?

I would love this as well. I *think* you wouldn't have to recreate the language, just recreate the runtime. You can currently use D and can completely avoid the use of the GC by just using static functions. From what I understand, dynamic arrays are also controlled and provided through the runtime. You can also export C symbols if you wanted to.

No need to restrict yourself yo static functions. Functions in structs are not virtual and doesn't require the GC. -- /Jacob Carlborg
Feb 11 2012
parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Jacob Carlborg wrote:
 On 2012-02-10 20:23, Zachary Lund wrote:
 On 02/10/2012 01:02 PM, Tim Krimm wrote:
 This language would basically be D without the garbage collection.
 For example there would be structures but no classes.
 There would be regular arrays but no dynamic arrays.
 Code that is mostly equivalent to C, but you would still have structures
 with functions and overloading support,
 and other features like templates etc.

 I think you get the idea.

 What are your thoughts?

I would love this as well. I *think* you wouldn't have to recreate the language, just recreate the runtime. You can currently use D and can completely avoid the use of the GC by just using static functions. From what I understand, dynamic arrays are also controlled and provided through the runtime. You can also export C symbols if you wanted to.

No need to restrict yourself yo static functions. Functions in structs are not virtual and doesn't require the GC.

Virtual functions don't require the GC either.
Feb 11 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-02-11 18:40, Piotr Szturmaj wrote:
 Jacob Carlborg wrote:
 On 2012-02-10 20:23, Zachary Lund wrote:
 On 02/10/2012 01:02 PM, Tim Krimm wrote:
 This language would basically be D without the garbage collection.
 For example there would be structures but no classes.
 There would be regular arrays but no dynamic arrays.
 Code that is mostly equivalent to C, but you would still have
 structures
 with functions and overloading support,
 and other features like templates etc.

 I think you get the idea.

 What are your thoughts?

I would love this as well. I *think* you wouldn't have to recreate the language, just recreate the runtime. You can currently use D and can completely avoid the use of the GC by just using static functions. From what I understand, dynamic arrays are also controlled and provided through the runtime. You can also export C symbols if you wanted to.

No need to restrict yourself yo static functions. Functions in structs are not virtual and doesn't require the GC.

Virtual functions don't require the GC either.

No they don't, but the will add other overhead. -- /Jacob Carlborg
Feb 11 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/10/12 11:02 AM, Tim Krimm wrote:
 We have C and C++

 How about D- and D?

No please. Andrei
Feb 10 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/10/12 12:54 PM, Tim Krimm wrote:
 On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu wrote:
 On 2/10/12 11:02 AM, Tim Krimm wrote:
 We have C and C++

 How about D- and D?

No please. Andrei

Please elaborate.

The last thing we need is balkanization of the community. You are of course free to initiate such a project but if you care about D it would be great to apply your talent in a different direction. Thanks, Andrei
Feb 10 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-02-10 23:06, Jonathan M Davis wrote:
 On Friday, February 10, 2012 13:54:49 H. S. Teoh wrote:
 Perhaps one solution is to simply have the compiler recognize all valid
 D constructs, but to give an error when it sees a construct not
 supported by the target platform. For example:

 input.d(123): Error: dynamic arrays not supported by target
 platform.

 This way, we don't cause fragmentation of D, and at the same time users
 will know which constructs should be avoided due to target platform
 limitations.

I think that the only switch even vaguely like that which has any chance of making it into the compiler is one which makes any constructs which use the GC illegal. And no one has been able to get Walter to even put _that_ in yet. For the most part, I'd argue that if you don't want to use all of D's features, then just don't use them all. The only major issue that I'm aware of is if you want to avoid the GC entirely (either for performance reasons or paranoia), you're probably going to have to forgoe using a lot of Phobos. - Jonathan M Davis

It's possible to remove the GC and you'll get linker errors when the GC is used. This is a hack but it works today. -- /Jacob Carlborg
Feb 11 2012
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Tim Krimm" <twkrimm yahoo.com> wrote in message 
news:kwweecfnvetseprndtjw dfeed.kimsufi.thecybershadow.net...
 On Friday, 10 February 2012 at 21:04:26 UTC, Andrei Alexandrescu wrote:
 On 2/10/12 12:54 PM, Tim Krimm wrote:
 On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu wrote:
 On 2/10/12 11:02 AM, Tim Krimm wrote:
 We have C and C++

 How about D- and D?

No please. Andrei

Please elaborate.

The last thing we need is balkanization of the community. You are of course free to initiate such a project but if you care about D it would be great to apply your talent in a different direction. Thanks, Andrei

Can we minimize the fragmentation issues by handling this with a flag in the front end of the compiler, similar to the way we handle "The SafeD Subset".

VOTE++!!!!
Feb 11 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:jh40oq$26p0$1 digitalmars.com...
 On 2/10/12 12:54 PM, Tim Krimm wrote:
 On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu wrote:
 On 2/10/12 11:02 AM, Tim Krimm wrote:
 We have C and C++

 How about D- and D?

No please. Andrei

Please elaborate.

The last thing we need is balkanization of the community. You are of course free to initiate such a project but if you care about D it would be great to apply your talent in a different direction.

I absolutely agree: We've learned a very hard lession from the community-fragmenting failure that was known as SafeD.
Feb 11 2012
next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Nick Sabalausky wrote:
 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:jh40oq$26p0$1 digitalmars.com...
 On 2/10/12 12:54 PM, Tim Krimm wrote:
 On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu wrote:
 On 2/10/12 11:02 AM, Tim Krimm wrote:
 We have C and C++

 How about D- and D?

No please. Andrei

Please elaborate.

The last thing we need is balkanization of the community. You are of course free to initiate such a project but if you care about D it would be great to apply your talent in a different direction.

I absolutely agree: We've learned a very hard lession from the community-fragmenting failure that was known as SafeD.

So now SafeD is only thing of the past?
Feb 11 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/11/2012 06:43 PM, Piotr Szturmaj wrote:
 Nick Sabalausky wrote:
 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org> wrote in message
 news:jh40oq$26p0$1 digitalmars.com...
 On 2/10/12 12:54 PM, Tim Krimm wrote:
 On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu wrote:
 On 2/10/12 11:02 AM, Tim Krimm wrote:
 We have C and C++

 How about D- and D?

No please. Andrei

Please elaborate.

The last thing we need is balkanization of the community. You are of course free to initiate such a project but if you care about D it would be great to apply your talent in a different direction.

I absolutely agree: We've learned a very hard lession from the community-fragmenting failure that was known as SafeD.

So now SafeD is only thing of the past?

Nick was quite obviously being sarcastic. ;)
Feb 11 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/12 12:28 PM, Timon Gehr wrote:
 Nick was quite obviously being sarcastic. ;)

oops... Andrei
Feb 11 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/12 8:48 AM, Nick Sabalausky wrote:
 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:jh40oq$26p0$1 digitalmars.com...
 On 2/10/12 12:54 PM, Tim Krimm wrote:
 On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu wrote:
 On 2/10/12 11:02 AM, Tim Krimm wrote:
 We have C and C++

 How about D- and D?

No please. Andrei

Please elaborate.

The last thing we need is balkanization of the community. You are of course free to initiate such a project but if you care about D it would be great to apply your talent in a different direction.

I absolutely agree: We've learned a very hard lession from the community-fragmenting failure that was known as SafeD.

Not sure what you mean there. As far as I can tell SafeD did not fail and there was no community fragmentation at any point because of it. Andrei
Feb 11 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/11/2012 06:55 PM, Andrei Alexandrescu wrote:
 On 2/11/12 8:48 AM, Nick Sabalausky wrote:
 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org> wrote in message
 news:jh40oq$26p0$1 digitalmars.com...
 On 2/10/12 12:54 PM, Tim Krimm wrote:
 On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu wrote:
 On 2/10/12 11:02 AM, Tim Krimm wrote:
 We have C and C++

 How about D- and D?

No please. Andrei

Please elaborate.

The last thing we need is balkanization of the community. You are of course free to initiate such a project but if you care about D it would be great to apply your talent in a different direction.

I absolutely agree: We've learned a very hard lession from the community-fragmenting failure that was known as SafeD.

Not sure what you mean there. As far as I can tell SafeD did not fail and there was no community fragmentation at any point because of it. Andrei

He was setting up an analogy between SafeD and 'EmbedD' in a satirical attempt to ridicule non-uniform treatment of the concepts.
Feb 11 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/12 12:07 PM, H. S. Teoh wrote:
 On Sat, Feb 11, 2012 at 11:55:07AM -0600, Andrei Alexandrescu wrote:
 On 2/11/12 8:48 AM, Nick Sabalausky wrote:

 I absolutely agree: We've learned a very hard lession from the
 community-fragmenting failure that was known as SafeD.

Not sure what you mean there. As far as I can tell SafeD did not fail and there was no community fragmentation at any point because of it.

AFAIK, SafeD is just incompletely implemented, right? But it exists and it will be done one day.

That is correct. A nicer way to put it is safe needs more work. Andrei
Feb 11 2012
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 11.02.2012 19:50, schrieb Andrei Alexandrescu:
 On 2/11/12 12:07 PM, H. S. Teoh wrote:
 On Sat, Feb 11, 2012 at 11:55:07AM -0600, Andrei Alexandrescu wrote:
 On 2/11/12 8:48 AM, Nick Sabalausky wrote:

 I absolutely agree: We've learned a very hard lession from the
 community-fragmenting failure that was known as SafeD.

Not sure what you mean there. As far as I can tell SafeD did not fail and there was no community fragmentation at any point because of it.

AFAIK, SafeD is just incompletely implemented, right? But it exists and it will be done one day.

That is correct. A nicer way to put it is safe needs more work. Andrei

Andrei, what would be needed to improve it? Just submitting patches to existing open issues or is some kind of redesign also needed? -- Paulo
Feb 12 2012
prev sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:jh6daf$1vq7$1 digitalmars.com...
 On 2/11/12 12:07 PM, H. S. Teoh wrote:
 On Sat, Feb 11, 2012 at 11:55:07AM -0600, Andrei Alexandrescu wrote:
 On 2/11/12 8:48 AM, Nick Sabalausky wrote:

 I absolutely agree: We've learned a very hard lession from the
 community-fragmenting failure that was known as SafeD.

Not sure what you mean there. As far as I can tell SafeD did not fail and there was no community fragmentation at any point because of it.

AFAIK, SafeD is just incompletely implemented, right? But it exists and it will be done one day.

That is correct. A nicer way to put it is safe needs more work. Andrei

I don't know why people keep saying this. Most of safeD is implemented as of about six months ago.
Feb 12 2012
prev sibling next sibling parent Norbert Nemec <Norbert Nemec-online.de> writes:
On 10.02.2012 22:04, Andrei Alexandrescu wrote:
 On 2/10/12 12:54 PM, Tim Krimm wrote:
 On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu wrote:
 On 2/10/12 11:02 AM, Tim Krimm wrote:
 We have C and C++

 How about D- and D?

No please. Andrei

Please elaborate.

The last thing we need is balkanization of the community. You are of course free to initiate such a project but if you care about D it would be great to apply your talent in a different direction.

In my understanding, balkanization would begin only if D- would stop being a pure subset of D "Safe D" is already one kind of subset that you can use for a large class of real-world problems. Maybe, the new concept could be communicated as "Embedded D" in a very similar way, prohibiting certain language features by a compiler switch and making sure that a meaningful subset of the runtime library can still be used. In fact, the concept of such a restricted subset of D could be quite useful for hard real-time code that has been discussed on this list recently. Perhaps the requirements are slightly different, but why not expand the concept of restricting D for various purposes? (real-time, embedded systems, memory-safe programming, maybe others will come up too?)
Feb 12 2012
prev sibling parent reply Zach the Mystic <reachzachatgooglesmailservice dot.com> writes:
On 2/10/12 4:04 PM, Andrei Alexandrescu wrote:
 The last thing we need is balkanization of the community. You are of
 course free to initiate such a project but if you care about D it would
 be great to apply your talent in a different direction.

I think this might be going a little bit too far. In other posts on this thread, is has been clearly shown that D isn't afraid run with a design even though the implementation may be quite a ways into the future. As you yourself said, " safe needs more work". The reason I'm saying this is because I don't think that a subset of D which is good for tiny devices breaks the language itself. And it would also showcase D's versatility. In other words, the community may actually *gain* followers when people using other languages start to think to themselves, "You know, I can't do that in my language, not even in principle. That's pretty cool."
Feb 13 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/13/12 10:45 AM, Zach the Mystic wrote:
 On 2/10/12 4:04 PM, Andrei Alexandrescu wrote:
 The last thing we need is balkanization of the community. You are of
 course free to initiate such a project but if you care about D it would
 be great to apply your talent in a different direction.

I think this might be going a little bit too far. In other posts on this thread, is has been clearly shown that D isn't afraid run with a design even though the implementation may be quite a ways into the future. As you yourself said, " safe needs more work". The reason I'm saying this is because I don't think that a subset of D which is good for tiny devices breaks the language itself. And it would also showcase D's versatility. In other words, the community may actually *gain* followers when people using other languages start to think to themselves, "You know, I can't do that in my language, not even in principle. That's pretty cool."

I just find it difficult to imagine things that way. Tiny devices are confined to small programs by definition, and at that magnitude the field is quite leveled; for a 3K-lines program, C is just fine and many of D's (and other languages') advantages are at best minor. Andrei
Feb 13 2012
parent reply Zach the Mystic <reachzachatgooglesmailservice dot.com> writes:
On 2/13/12 11:54 AM, Andrei Alexandrescu wrote:
 I just find it difficult to imagine things that way. Tiny devices are
 confined to small programs by definition, and at that magnitude the
 field is quite leveled; for a 3K-lines program, C is just fine and many
 of D's (and other languages') advantages are at best minor.

 Andrei

From a practical standpoint, you are correct, and I won't argue. But from an idealistic standpoint, D stands as one of the few languages (the only language?) which really has a finger in every pie. So we seek a compromise answer. How to manage D's current limited manpower effectively while still holding true to a few ideals. Ideals do matter, and in that sense they are, ironically, practical, because they motivate people.
Feb 13 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/13/12 11:46 AM, Zach the Mystic wrote:
 On 2/13/12 11:54 AM, Andrei Alexandrescu wrote:
 I just find it difficult to imagine things that way. Tiny devices are
 confined to small programs by definition, and at that magnitude the
 field is quite leveled; for a 3K-lines program, C is just fine and many
 of D's (and other languages') advantages are at best minor.

 Andrei

From a practical standpoint, you are correct, and I won't argue. But from an idealistic standpoint, D stands as one of the few languages (the only language?) which really has a finger in every pie. So we seek a compromise answer. How to manage D's current limited manpower effectively while still holding true to a few ideals. Ideals do matter, and in that sense they are, ironically, practical, because they motivate people.

Agreed. There are two issues I see here in my opinion. First, putting some of our manpower in a small subset of D for tiny embedded systems is a misplaced investment because it would make a small impact at best. Second, coming up with another D-derived brand is a bad marketing move. We've been hurt for too long a time by D1/D2. With that in mind, if working on D for small embedded systems is what you like, I encourage you to go down that path and see what you discover. Andrei
Feb 13 2012
next sibling parent Zach the Mystic <reachzachatgooglesmailservice dot.com> writes:
On 2/13/12 1:17 PM, Andrei Alexandrescu wrote:
 Agreed. There are two issues I see here in my opinion. First, putting
 some of our manpower in a small subset of D for tiny embedded systems is
 a misplaced investment because it would make a small impact at best.
 Second, coming up with another D-derived brand is a bad marketing move.
 We've been hurt for too long a time by D1/D2. With that in mind, if
 working on D for small embedded systems is what you like, I encourage
 you to go down that path and see what you discover.

 Andrei

Once again, you're correct. I have little to add to this, except to say that when I first read the topic I was rather excited, and I read on hoping to see a discussion of what exactly would be involved in stripping out a chunk of D that it might produce extremely small programs. I wonder if my desire to read these threads for educational purposes is at odds with their other functions, such as internal debates about where the language should be headed. I don't know what to say about the D1/D2 debacle. It seems like D's extraordinary dedication to "getting it right" has had some unfortunate side effects. Perhaps it's possible to interpret D's past as a sort of "nekyia" on D's way to a more glorious future: http://en.wikipedia.org/wiki/Nekyia
Feb 13 2012
prev sibling parent reply Don <nospam nospam.com> writes:
On 13.02.2012 19:17, Andrei Alexandrescu wrote:
 Second, coming up with another D-derived brand is a bad marketing move.
 We've been hurt for too long a time by D1/D2.

Andrei, can I ask you to please never mention D1 again? You seem to have _fundamental_ misconceptions about it. It's obvious that D1 was exceedingly poorly explained, to the extent that even you didn't understand it, and you've spread your misunderstandings everywhere. And THAT has been a marketing disaster. To try to set the record straight: The D language has been developed continuously since the beginning. "D1" is a stability snapshot of DMD 1.015. "D2" is the continued development of D after 1.015. There was no change in the rate of language development before the stability snapshot (ie, what went into D1) vs after the stability snapshot (what has gone into D2). There was no decision "1.015 is a good enough language, let's stabilize on this". It was essentially a freezing of the language development at a largely arbitrary point, for purposes of stability. Most importantly, note that "D1" was not planned. It's not a language that anyone wanted. It's just a snapshot. And it was successful - 75% of the open bugs are D2-only. Any mention of D1 as if it were the "first attempt" of the D language is offensive, and wrong. Here's the original announcement of D1: http://www.digitalmars.com/d/archives/digitalmars/D/announce/Stick_a_fork_in_it_8521.html
Feb 15 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/15/12 4:40 PM, Don wrote:
 On 13.02.2012 19:17, Andrei Alexandrescu wrote:
 Second, coming up with another D-derived brand is a bad marketing move.
 We've been hurt for too long a time by D1/D2.

Andrei, can I ask you to please never mention D1 again? You seem to have _fundamental_ misconceptions about it. It's obvious that D1 was exceedingly poorly explained, to the extent that even you didn't understand it, and you've spread your misunderstandings everywhere. And THAT has been a marketing disaster. To try to set the record straight: The D language has been developed continuously since the beginning. "D1" is a stability snapshot of DMD 1.015. "D2" is the continued development of D after 1.015. There was no change in the rate of language development before the stability snapshot (ie, what went into D1) vs after the stability snapshot (what has gone into D2). There was no decision "1.015 is a good enough language, let's stabilize on this". It was essentially a freezing of the language development at a largely arbitrary point, for purposes of stability. Most importantly, note that "D1" was not planned. It's not a language that anyone wanted. It's just a snapshot. And it was successful - 75% of the open bugs are D2-only. Any mention of D1 as if it were the "first attempt" of the D language is offensive, and wrong. Here's the original announcement of D1: http://www.digitalmars.com/d/archives/digitalmars/D/announce/Stick_a_fork_in_it_8521.html

All of this is in agreement with my understanding of the situation, so I fail to see where my fundamental misconceptions would be. Is it possible that your perception of my view of D1 is inaccurate? As a simple starting point, note that none of the above contradicts, either directly or indirectly, my assertion. Thanks, Andrei
Feb 15 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Feb 10, 2012 at 08:02:52PM +0100, Tim Krimm wrote:
 We have C and C++
 
 How about D- and D?

Great, just what I need: a D- in programming! :-P T -- PNP = Plug 'N' Pray
Feb 10 2012
prev sibling next sibling parent "Tim Krimm" <twkrimm yahoo.com> writes:
On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu 
wrote:
 On 2/10/12 11:02 AM, Tim Krimm wrote:
 We have C and C++

 How about D- and D?

No please. Andrei

Please elaborate.
Feb 10 2012
prev sibling next sibling parent "Tim Krimm" <twkrimm yahoo.com> writes:
On Friday, 10 February 2012 at 21:04:26 UTC, Andrei Alexandrescu 
wrote:
 On 2/10/12 12:54 PM, Tim Krimm wrote:
 On Friday, 10 February 2012 at 20:21:53 UTC, Andrei 
 Alexandrescu wrote:
 On 2/10/12 11:02 AM, Tim Krimm wrote:
 We have C and C++

 How about D- and D?

No please. Andrei

Please elaborate.

The last thing we need is balkanization of the community. You are of course free to initiate such a project but if you care about D it would be great to apply your talent in a different direction. Thanks, Andrei

It seems like D would catch on faster if it could be used more places, but at the same time I do understand your concern about the language fragmentation that could occur. That is a major, major issue. D is superior to C and C++ but D is fighting an up hill battle when it comes to market share. Unfortunately, I guess for now, I am stuck using the C/C++ tools that are available for all of the different microcontrollers out there.
Feb 10 2012
prev sibling next sibling parent maarten van damme <maartenvd1994 gmail.com> writes:
--047d7b33d19efd7f1604b8a30eb1
Content-Type: text/plain; charset=ISO-8859-1

I would love to be able to use D on memory limited devices like arduino but
creating a whole new language would certainly add up to the confusion for
many new potential users (they can't deal with two standard library's, let
alone two language named nearly the same)
if one were to do such project I would certainly hope he'd keep nearly
everything the same and only strip out what's really necessary.

--047d7b33d19efd7f1604b8a30eb1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I would love to be able to use D on memory limited devices like arduino=A0b=
ut creating a whole new language would certainly add up to the confusion fo=
r many new potential users (they can&#39;t deal with two standard library&#=
39;s, let alone two language named nearly the same)<div>
if one were to do such project I would certainly hope he&#39;d keep nearly =
everything the same and only strip out what&#39;s really=A0necessary.</div>

--047d7b33d19efd7f1604b8a30eb1--
Feb 10 2012
prev sibling next sibling parent "Tim Krimm" <twkrimm yahoo.com> writes:
On Friday, 10 February 2012 at 21:04:26 UTC, Andrei Alexandrescu 
wrote:
 On 2/10/12 12:54 PM, Tim Krimm wrote:
 On Friday, 10 February 2012 at 20:21:53 UTC, Andrei 
 Alexandrescu wrote:
 On 2/10/12 11:02 AM, Tim Krimm wrote:
 We have C and C++

 How about D- and D?

No please. Andrei

Please elaborate.

The last thing we need is balkanization of the community. You are of course free to initiate such a project but if you care about D it would be great to apply your talent in a different direction. Thanks, Andrei

Can we minimize the fragmentation issues by handling this with a flag in the front end of the compiler, similar to the way we handle "The SafeD Subset".
Feb 10 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Feb 10, 2012 at 01:04:26PM -0800, Andrei Alexandrescu wrote:
 On 2/10/12 12:54 PM, Tim Krimm wrote:
On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu wrote:
On 2/10/12 11:02 AM, Tim Krimm wrote:
We have C and C++

How about D- and D?

No please. Andrei

Please elaborate.

The last thing we need is balkanization of the community. You are of course free to initiate such a project but if you care about D it would be great to apply your talent in a different direction.

Perhaps one solution is to simply have the compiler recognize all valid D constructs, but to give an error when it sees a construct not supported by the target platform. For example: input.d(123): Error: dynamic arrays not supported by target platform. This way, we don't cause fragmentation of D, and at the same time users will know which constructs should be avoided due to target platform limitations. T -- Never trust an operating system you don't have source for! -- Martin Schulze
Feb 10 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, February 10, 2012 13:54:49 H. S. Teoh wrote:
 Perhaps one solution is to simply have the compiler recognize all valid
 D constructs, but to give an error when it sees a construct not
 supported by the target platform. For example:
 
 input.d(123): Error: dynamic arrays not supported by target
 platform.
 
 This way, we don't cause fragmentation of D, and at the same time users
 will know which constructs should be avoided due to target platform
 limitations.

I think that the only switch even vaguely like that which has any chance of making it into the compiler is one which makes any constructs which use the GC illegal. And no one has been able to get Walter to even put _that_ in yet. For the most part, I'd argue that if you don't want to use all of D's features, then just don't use them all. The only major issue that I'm aware of is if you want to avoid the GC entirely (either for performance reasons or paranoia), you're probably going to have to forgoe using a lot of Phobos. - Jonathan M Davis
Feb 10 2012
prev sibling next sibling parent "Jesse Phillips" <jessekphillips+D gmail.com> writes:
On Friday, 10 February 2012 at 19:02:54 UTC, Tim Krimm wrote:
 We have C and C++

 How about D- and D?

There has been discussion of having a compiler switch that flags use of the GC. I'm pretty sure Walter agreed it would be good to have. So someone needs to create a pull request so he can pull it in. Then a runtime and standard library could be created for the needed device/purpose.
Feb 10 2012
prev sibling next sibling parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 10.02.2012, 20:02 Uhr, schrieb Tim Krimm <twkrimm yahoo.com>:

 What are your thoughts?

There is no way you get a D application into 64K. The language is not powerful enough. Only C can achieve that.
Feb 10 2012
next sibling parent Xinok <xinok live.com> writes:
On 2/10/2012 8:13 PM, Tim Krimm wrote:
 If you make a subset of D, it would most likely be named Mini-D. But
 at that point you've got an enhanced C without going C++.

Yes and that probably would be better than what I have now. Going back and forth programming in C/C++ today, and then switching back to D tomorrow. Let me see if I remember again, classes and structures are almost the same in C++ but different in D. Well I did the assignment A=B, if I change A will it also change B, or is B a copy of A. Is A a class or a structure that is an important distinction in D. Today, Oh crap I forgot the #include Tomorrow, Oh crap I forgot the import Oh crap what was that syntax for initializing the class variables again.

That hardly seems like a good enough reason to create a second language. The community has enough to work on from the standard library to squashing bugs to writing literature and much more. I think a more practical idea would be to write a utility which translates a subset of D's features to equivalent C code.
Feb 10 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Era Scarecrow" <rtcvb32 yahoo.com> wrote in message 
news:jzavmzbmjoyujhqyfvhp dfeed.kimsufi.thecybershadow.net...
 What are your thoughts?

There is no way you get a D application into 64K. The language is not powerful enough. Only C can achieve that.

I'll need to agree. Porting D to a smaller memory space and with cramped features in all of this is not going to be good no matter how you look at it. I'm sure it's similar to comparing using perl in something with only 64k of memory, one must ask where you can put the interpreter, decoding and working with the source text, and many other things, not to mention even if you pulled it off, the speed penalty. With only 64k, you aren't going to need anything extremely complex or elaborate. You MIGHT get away with exporting D code to using C symbols, but you'll likely be stuck working with structs, no library support, no heap, no memory management, and fixed-sized arrays. I doubt you'd need templates, or any of the higher functions. All structures and types must be basic or known statically at compile time. Unlikely for lambdas to be used, and a score of other features. This is all just speculation, but I think you get the picture. If you make a subset of D, it would most likely be named Mini-D. But at that point you've got an enhanced C without going C++.

That would *still* be a very notable improvement over C. Hell, if you ask me, a proper module system alone is one of the killer features of D over C. Header files? Seriously? Fuck that shit. What the hell is this, 1970? And then there's other things that are *at the very least* icing on the cake: Faster compilation, slicing, better safety, metaprogramming (esp CTFE) that whups C's ass and makes it much less less tempting to do things at runtime that don't need to be done at runtime. That's all just off the top of my head. I find it an absolute enigma that anyone would even consider that wouldn't be worthwhile. Ok, so it wouldn't add *all* of D's features...so the fuck what? The ones it would add would be more than enough to beat the shit out of C. And like I've said before, why should we be focusing so exclusivly on desktop/web developers who *already* have five billion fucking languages to choose from, when we're already in the extremely unique position of actually having some potential to provide an alternative to areas that *don't* have many (or any) language choices available.
Feb 11 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-02-11 15:36, Nick Sabalausky wrote:
 "Era Scarecrow"<rtcvb32 yahoo.com>  wrote in message
 news:jzavmzbmjoyujhqyfvhp dfeed.kimsufi.thecybershadow.net...
 What are your thoughts?

There is no way you get a D application into 64K. The language is not powerful enough. Only C can achieve that.

I'll need to agree. Porting D to a smaller memory space and with cramped features in all of this is not going to be good no matter how you look at it. I'm sure it's similar to comparing using perl in something with only 64k of memory, one must ask where you can put the interpreter, decoding and working with the source text, and many other things, not to mention even if you pulled it off, the speed penalty. With only 64k, you aren't going to need anything extremely complex or elaborate. You MIGHT get away with exporting D code to using C symbols, but you'll likely be stuck working with structs, no library support, no heap, no memory management, and fixed-sized arrays. I doubt you'd need templates, or any of the higher functions. All structures and types must be basic or known statically at compile time. Unlikely for lambdas to be used, and a score of other features. This is all just speculation, but I think you get the picture. If you make a subset of D, it would most likely be named Mini-D. But at that point you've got an enhanced C without going C++.

That would *still* be a very notable improvement over C. Hell, if you ask me, a proper module system alone is one of the killer features of D over C. Header files? Seriously? Fuck that shit. What the hell is this, 1970? And then there's other things that are *at the very least* icing on the cake: Faster compilation, slicing, better safety, metaprogramming (esp CTFE) that whups C's ass and makes it much less less tempting to do things at runtime that don't need to be done at runtime. That's all just off the top of my head.

I think slicing is quite difficult without a GC. Not the actual slicing but freeing the memory. -- /Jacob Carlborg
Feb 11 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:jh63p2$17li$1 digitalmars.com...
 On 2012-02-11 15:36, Nick Sabalausky wrote:
 "Era Scarecrow"<rtcvb32 yahoo.com>  wrote in message
 news:jzavmzbmjoyujhqyfvhp dfeed.kimsufi.thecybershadow.net...
 What are your thoughts?

There is no way you get a D application into 64K. The language is not powerful enough. Only C can achieve that.

I'll need to agree. Porting D to a smaller memory space and with cramped features in all of this is not going to be good no matter how you look at it. I'm sure it's similar to comparing using perl in something with only 64k of memory, one must ask where you can put the interpreter, decoding and working with the source text, and many other things, not to mention even if you pulled it off, the speed penalty. With only 64k, you aren't going to need anything extremely complex or elaborate. You MIGHT get away with exporting D code to using C symbols, but you'll likely be stuck working with structs, no library support, no heap, no memory management, and fixed-sized arrays. I doubt you'd need templates, or any of the higher functions. All structures and types must be basic or known statically at compile time. Unlikely for lambdas to be used, and a score of other features. This is all just speculation, but I think you get the picture. If you make a subset of D, it would most likely be named Mini-D. But at that point you've got an enhanced C without going C++.

That would *still* be a very notable improvement over C. Hell, if you ask me, a proper module system alone is one of the killer features of D over C. Header files? Seriously? Fuck that shit. What the hell is this, 1970? And then there's other things that are *at the very least* icing on the cake: Faster compilation, slicing, better safety, metaprogramming (esp CTFE) that whups C's ass and makes it much less less tempting to do things at runtime that don't need to be done at runtime. That's all just off the top of my head.

I think slicing is quite difficult without a GC. Not the actual slicing but freeing the memory.

Those are orthogonal concerns. Just because you're taking a slice doesn't mean you aren't still using the rest. And if you're not using the rest, then the problem just reduces to the classic old "GC vs manual" issue.
Feb 11 2012
prev sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Jonathan M Davis wrote:
 On Saturday, February 11, 2012 19:00:51 q66 wrote:
 What's so difficult on that? Slices do not require the GC, you
 allocate once, slice many times, deallocate once.

With dynamic arrays, the GC owns the memory, and _all_ dynamic arrays are slices. _None_ of them own their own memory. The GC keeps track of whether you have any slices for a particular memory block and deals with freeing up wth the block if you don't. However, if you allocate a dynamic array without the GC, then all of a sudden, it effectively owns its own memory, so the semantics of dealing with arrays and memories changes drastically. What happens when you slice it? Which one owns the memory? What happens when you try and do stuff like popFront on an array? All of a sudden, you have memory which is no longer referenced. It's been leaked. If you have a very careful scheme for handling memory, you _can_ slice arrays without a GC, but you have to worry about all the bookkeeping of keeping track of the originally allocated memory and how many slices reference it so that you can free it when appropriate. Also, you can't concatenate to arrays at all, because that requires the GC. So, you're dealing with a mine field if you try and use D's array capabilities without a GC. Yes, you _can_ use some of them if you're _very_ careful, but I'd seriously advise just sticking to using arrays like you would in C except for the fact that arrays know their length.

Delphi has dynamic arrays and appendable strings without a GC. In Delphi pointers and objects are managed manually, but arrays and strings are managed automatically (ref counted with Copy-On-Write). Take a look at http://www.codexterity.com/delphistrings.htm. Maybe some Delphi solutions may be used in NoGcD?
Feb 11 2012
prev sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 02/11/12 02:46, Era Scarecrow wrote:
 There is no way you get a D application into 64K. The language is not powerful
enough. Only C can achieve that.

I'll need to agree. Porting D to a smaller memory space and with cramped features in all of this is not going to be good no matter how you look at it. I'm sure it's similar to comparing using perl in something with only 64k of memory, one must ask where you can put the interpreter, decoding and working with the source text, and many other things, not to mention even if you pulled it off, the speed penalty. With only 64k, you aren't going to need anything extremely complex or elaborate. You MIGHT get away with exporting D code to using C symbols, but you'll likely be stuck working with structs, no library support, no heap, no memory management, and fixed-sized arrays. I doubt you'd need templates, or any of the higher functions. All structures and types must be basic or known statically at compile time. Unlikely for lambdas to be used, and a score of other features. This is all just speculation, but I think you get the picture. If you make a subset of D, it would most likely be named Mini-D. But at that point you've got an enhanced C without going C++.

I assumed the poster you're replying to was not being serious. There's absolutely no difference between the code generated from C and D, unless you use a few D-only concepts; ignoring compiler issues. Having several levels of modules and templates, that in the end emit single CPU instructions is not only possible, it lets you write completely generic code that's both safer and not less efficient than writing the equivalent in assembler. I can easily see D being acceptable for 8K projects, 64K would probably allow for a mostly complete runtime. The answer isn't to butcher the language, it's to fix the shortcomings. So, for example: all array ops need to be lowered and mapped to D code so that they can be intercepted. Then you can either disallow everything not supported or allow some subset and fail for every other operation. Slicing probably counts too, as you may want to disallow or limit its use. (Intercepted) pseudo-GC allocation might even work for some cases, even if i'm not sure that it would be very useful, w/o things like scoped args and more compiler support. "synchronized" needs to accept anything that implements opLock() and opUnlock(). Not only does that let you change the locking primitives, it also lets you use it for things like CLI/STI-type UP exclusion, since I doubt the 64K machine would be MP. "synchronized" is better than RAII/scope because it gives the compiler more information; once it knows that the code inside the critical region is much more expensive to run, it can more aggressively move certain parts outside, keeping the critical region as small as possible (think "immutable" accesses, that are hidden under a layer of functions/templates). Classes are probably not a good idea in such a small system, yes. A compiler option to turn off the default TLS model would help too. What did I miss? artur
Feb 11 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
 What are your thoughts?

There is no way you get a D application into 64K. The language is not powerful enough. Only C can achieve that.

I'll need to agree. Porting D to a smaller memory space and with cramped features in all of this is not going to be good no matter how you look at it. I'm sure it's similar to comparing using perl in something with only 64k of memory, one must ask where you can put the interpreter, decoding and working with the source text, and many other things, not to mention even if you pulled it off, the speed penalty. With only 64k, you aren't going to need anything extremely complex or elaborate. You MIGHT get away with exporting D code to using C symbols, but you'll likely be stuck working with structs, no library support, no heap, no memory management, and fixed-sized arrays. I doubt you'd need templates, or any of the higher functions. All structures and types must be basic or known statically at compile time. Unlikely for lambdas to be used, and a score of other features. This is all just speculation, but I think you get the picture. If you make a subset of D, it would most likely be named Mini-D. But at that point you've got an enhanced C without going C++.
Feb 10 2012
prev sibling next sibling parent "Tim Krimm" <twkrimm yahoo.com> writes:
 If you make a subset of D, it would most likely be named 
 Mini-D. But at that point you've got an enhanced C without 
 going C++.

Yes and that probably would be better than what I have now. Going back and forth programming in C/C++ today, and then switching back to D tomorrow. Let me see if I remember again, classes and structures are almost the same in C++ but different in D. Well I did the assignment A=B, if I change A will it also change B, or is B a copy of A. Is A a class or a structure that is an important distinction in D. Today, Oh crap I forgot the #include Tomorrow, Oh crap I forgot the import Oh crap what was that syntax for initializing the class variables again.
Feb 10 2012
prev sibling next sibling parent "Tim Krimm" <twkrimm yahoo.com> writes:
On Saturday, 11 February 2012 at 00:58:53 UTC, Marco Leise wrote:
 Am 10.02.2012, 20:02 Uhr, schrieb Tim Krimm <twkrimm yahoo.com>:

 What are your thoughts?

There is no way you get a D application into 64K. The language is not powerful enough. Only C can achieve that.

It seems to me that if you are only using the D constructs that are similar to C, then you should probably be generating similar assembly code. It also seems to me that if you are only using the D constructs that are similar to C, then you could rather easily convert the D into equivalent C code. Then you could use the existing C compiler to compile the code for your Microchip, Ardinuo, Zilog, ARM, Intel, Propeller, etc.
Feb 10 2012
prev sibling next sibling parent "Tim Krimm" <twkrimm yahoo.com> writes:
On Saturday, 11 February 2012 at 01:46:26 UTC, Era Scarecrow 
wrote:
 What are your thoughts?

There is no way you get a D application into 64K. The language is not powerful enough. Only C can achieve that.

I'll need to agree. Porting D to a smaller memory space and with cramped features in all of this is not going to be good no matter how you look at it. I'm sure it's similar to comparing using perl in something with only 64k of memory, one must ask where you can put the interpreter, decoding and working with the source text, and many other things, not to mention even if you pulled it off, the speed penalty. With only 64k, you aren't going to need anything extremely complex or elaborate. You MIGHT get away with exporting D code to using C symbols, but you'll likely be stuck working with structs, no library support, no heap, no memory management, and fixed-sized arrays. I doubt you'd need templates, or any of the higher functions. All structures and types must be basic or known statically at compile time. Unlikely for lambdas to be used, and a score of other features. This is all just speculation, but I think you get the picture. If you make a subset of D, it would most likely be named Mini-D. But at that point you've got an enhanced C without going C++.

Also computer chips are becoming more powerful every day. I think we will soon be needing better tools. example: Microchip PIC32MX795F512L 32 bit MIPS architecture 512K flash, 128K RAM priced less than $10 http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en545660#2
Feb 10 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
 This is all just speculation, but I think you get the picture. 
 If you make a subset of D, it would most likely be named 
 Mini-D. But at that point you've got an enhanced C without 
 going C++.

Also computer chips are becoming more powerful every day. I think we will soon be needing better tools. example: Microchip PIC32MX795F512L 32 bit MIPS architecture 512K flash, 128K RAM priced less than $10 http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en545660#2

Interesting and curious. I've wondered if you could string a hundred such processors onto a board and have it work properly at a fast speed, but obviously there's issues with that. (No need to explain the problems) Just think though; What if they had this back when they were still making atari800 PCs? Since the Atari was only at about 3Mhz, then this would be supped up, on steroids, crack, and maybe a few other illegal drugs as well :P Now if only I had the expertise... then I might make one just for the hell of it.
Feb 10 2012
prev sibling next sibling parent bcs <bcs example.com> writes:
On 02/10/2012 11:02 AM, Tim Krimm wrote:
 We have C and C++

 How about D- and D?

 D- would be the have a similar use as today's C compilers.

 ===========================
 Why create this language?
 ===========================

 Well I would love to have a D compiler that supports microcontrollers.
 The ones that have say 32 K of RAM and 64K of FLASH.
 A language that is targeted for embedded and/or low resource environments.
 It would be nice to have a modern language for low resource environments.

 A potential way to implement this language is to use the DMD frontend,
 then flag the unsupported features of D,
 Next create a backend, like "C front" that outputs C code instead of
 assembler.


 ===========================
 What do I envision with D-,
 D-- or Dm or what ever you want to call it.
 ===========================

 This language would basically be D without the garbage collection.
 For example there would be structures but no classes.
 There would be regular arrays but no dynamic arrays.
 Code that is mostly equivalent to C, but you would still have structures
 with functions and overloading support,
 and other features like templates etc.

 I think you get the idea.

 What are your thoughts?

If it's strict subset of D, then it could be done in a lint-esqu fashion by statical checking for anything not in the subset. I could see this as a patch to DMD that makes no modifications to the processing aside from adding extra errors. Any legal D- should be legal D and do exactly the same thing.
Feb 10 2012
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Saturday, 11 February 2012 at 02:13:19 UTC, Tim Krimm wrote:
 If you make a subset of D, it would most likely be named 
 Mini-D. But at that point you've got an enhanced C without 
 going C++.

Yes and that probably would be better than what I have now. Going back and forth programming in C/C++ today, and then switching back to D tomorrow. Let me see if I remember again, classes and structures are almost the same in C++ but different in D. Well I did the assignment A=B, if I change A will it also change B, or is B a copy of A. Is A a class or a structure that is an important distinction in D. Today, Oh crap I forgot the #include Tomorrow, Oh crap I forgot the import Oh crap what was that syntax for initializing the class variables again.

"I'm incompetent so I want to fork the language"
Feb 10 2012
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 10.02.2012 20:02, schrieb Tim Krimm:
 We have C and C++

 How about D- and D?

 D- would be the have a similar use as today's C compilers.

 ===========================
 Why create this language?
 ===========================

 Well I would love to have a D compiler that supports microcontrollers.
 The ones that have say 32 K of RAM and 64K of FLASH.
 A language that is targeted for embedded and/or low resource environments.
 It would be nice to have a modern language for low resource environments.

 A potential way to implement this language is to use the DMD frontend,
 then flag the unsupported features of D,
 Next create a backend, like "C front" that outputs C code instead of
 assembler.


 ===========================
 What do I envision with D-,
 D-- or Dm or what ever you want to call it.
 ===========================

 This language would basically be D without the garbage collection.
 For example there would be structures but no classes.
 There would be regular arrays but no dynamic arrays.
 Code that is mostly equivalent to C, but you would still have structures
 with functions and overloading support,
 and other features like templates etc.

 I think you get the idea.

 What are your thoughts?

I don't see the point. C++ was the last systems programming language without GC getting market share. I seriously doubt any new systems programming language without GC will ever suceed. Specially since systems programming in MacOS X and Windows world is slowly meaning the use of reference counting or GC in the vendor supported systems programming languages. Objective-C in MacOS X supports GC and Reference Counting (GC). C++ in Windows has the std::*ptr and handles in C++/CX. Then there is also C# for systems programming, when used in context of Microsoft Research projects like Singularity. So sum this up. If you need a languague without GC, C and C++ are quite good, have lots of tools and excellent compilers available. Do you need a very simple C like language, but with GC and a few improvements, Go might be an option. Do you need a language with GC, that is C++ done right and quite capable for systems programming, pick D. There is no need to D-. -- Paulo
Feb 11 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Paulo Pinto" <pjmlp progtools.org> wrote in message 
news:jh5aip$1qma$1 digitalmars.com...
 I don't see the point.

 C++ was the last systems programming language without GC getting market 
 share. I seriously doubt any new systems programming language without GC 
 will ever suceed.

You're looking at it backwards. The whole point is for places where you wouldn't want GC. Those people are currently limited to the rotting, antiquated C and...that's about it. Nobody said this "D-" would need to take over the world. It can still succeed in a niche, and that niche is the whole point here.
 Specially since systems programming in MacOS X and Windows world is

Nobody's talking about Mac and Windows here.
 So sum this up. If you need a languague without GC, C and C++ are quite 
 good,

That's laughable. C and C++ are convoluted anachronistic crap. The only reason anyone still uses them is because 99.99% of language designers feel the way you do, and as a reasult, C/C++ remain the *only* options for certain uses.
 have lots of tools and excellent compilers available.

 Do you need a very simple C like language, but with GC and a few 
 improvements, Go might be an option.

First of all, Issue 9 is shit. Secondly, we're talking systems/embedded here, and Issue 9 is nowhere remotely near the same planet. That's like suggesting Perl or PHP.
 Do you need a language with GC,

Not the scenario we're talking about.
 that is C++ done right and quite capable
 for systems programming, pick D.

 There is no need to D-.

Poppycock.
Feb 11 2012
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 11.02.2012 15:46, schrieb Nick Sabalausky:
 "Paulo Pinto"<pjmlp progtools.org>  wrote in message
 news:jh5aip$1qma$1 digitalmars.com...
 I don't see the point.

 C++ was the last systems programming language without GC getting market
 share. I seriously doubt any new systems programming language without GC
 will ever suceed.

You're looking at it backwards. The whole point is for places where you wouldn't want GC. Those people are currently limited to the rotting, antiquated C and...that's about it. Nobody said this "D-" would need to take over the world. It can still succeed in a niche, and that niche is the whole point here.
 Specially since systems programming in MacOS X and Windows world is

Nobody's talking about Mac and Windows here.
 So sum this up. If you need a languague without GC, C and C++ are quite
 good,

That's laughable. C and C++ are convoluted anachronistic crap. The only reason anyone still uses them is because 99.99% of language designers feel the way you do, and as a reasult, C/C++ remain the *only* options for certain uses.

The reason being that if you remove the GC, then you end up with some kind of C, C++, Pascal or Ada flavour, because there is only so much you can do without a GC. So in the end you just get an already existing language, but with different syntax. So it is not worth the effort designing such languages. More to the point, research has proven that system programming languages with GC is possible, they have yet not become mainstream because for a systems programming language to become mainstream it has to be choosen from a major OS company. One of the things I like in D is that it really feels like Sing#, the C# Singularity version but open source. -- Paulo
Feb 12 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Paulo Pinto" <pjmlp progtools.org> wrote in message 
news:jh7tvk$29sv$1 digitalmars.com...
 So in the end you just get an already existing language, but with 
 different syntax.

 So it is not worth the effort designing such languages.

Where are you getting the crazy idea that the GC is the only non-syntactic improvement D has vs C/C++? Additionally, you keep implying that the syntactic improvements are unimportant, or at least insignificant. Rediculous. Even if the GC were the only non-syntactic improvement and all the other changes were syntax (which isn't even true anyway), the syntax alone would absolutely be a worthwhile improvement over C or C++.
Feb 12 2012
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 12.02.2012 15:23, schrieb Nick Sabalausky:
 "Paulo Pinto"<pjmlp progtools.org>  wrote in message
 news:jh7tvk$29sv$1 digitalmars.com...
 So in the end you just get an already existing language, but with
 different syntax.

 So it is not worth the effort designing such languages.

Where are you getting the crazy idea that the GC is the only non-syntactic improvement D has vs C/C++? Additionally, you keep implying that the syntactic improvements are unimportant, or at least insignificant. Rediculous. Even if the GC were the only non-syntactic improvement and all the other changes were syntax (which isn't even true anyway), the syntax alone would absolutely be a worthwhile improvement over C or C++.

Because I see it as a wasted effort that could be better spent in other areas D needs. There already other languages with manual memory management like Ada or Pascal, which in my personal opinion have a much better syntax and module systems than C or C++. -- Paulo
Feb 13 2012
prev sibling parent reply bcs <bcs example.com> writes:
On 02/11/2012 12:58 AM, Paulo Pinto wrote:
 Am 10.02.2012 20:02, schrieb Tim Krimm:
 We have C and C++

 How about D- and D?

 D- would be the have a similar use as today's C compilers.

 ===========================
 Why create this language?
 ===========================

 Well I would love to have a D compiler that supports microcontrollers.
 The ones that have say 32 K of RAM and 64K of FLASH.
 A language that is targeted for embedded and/or low resource
 environments.
 It would be nice to have a modern language for low resource environments.

 A potential way to implement this language is to use the DMD frontend,
 then flag the unsupported features of D,
 Next create a backend, like "C front" that outputs C code instead of
 assembler.


 ===========================
 What do I envision with D-,
 D-- or Dm or what ever you want to call it.
 ===========================

 This language would basically be D without the garbage collection.
 For example there would be structures but no classes.
 There would be regular arrays but no dynamic arrays.
 Code that is mostly equivalent to C, but you would still have structures
 with functions and overloading support,
 and other features like templates etc.

 I think you get the idea.

 What are your thoughts?

I don't see the point. C++ was the last systems programming language without GC getting market share. I seriously doubt any new systems programming language without GC will ever suceed. Specially since systems programming in MacOS X and Windows world is

Systems programming in the MacOS X and Windows world isn't real systems programming. The closest you get is kernel and driver work but even there you have most of an OS to work with. I think the kind of systems programming being considered is embedded work and/or things like BIOS work.
 slowly meaning the use of reference counting or GC in the vendor
 supported systems programming languages. Objective-C in MacOS X supports
 GC and Reference Counting (GC). C++ in Windows has the std::*ptr and
 handles in C++/CX. Then there is also C# for systems programming, when
 used in context of Microsoft Research projects like Singularity.

 So sum this up. If you need a languague without GC, C and C++ are quite
 good, have lots of tools and excellent compilers available.

 Do you need a very simple C like language, but with GC and a few
 improvements, Go might be an option.

 Do you need a language with GC, that is C++ done right and quite capable
 for systems programming, pick D.

 There is no need to D-.

 --
 Paulo

Feb 11 2012
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 11.02.2012 18:00, schrieb bcs:
 On 02/11/2012 12:58 AM, Paulo Pinto wrote:
 Am 10.02.2012 20:02, schrieb Tim Krimm:
 We have C and C++

 How about D- and D?

 D- would be the have a similar use as today's C compilers.

 ===========================
 Why create this language?
 ===========================

 Well I would love to have a D compiler that supports microcontrollers.
 The ones that have say 32 K of RAM and 64K of FLASH.
 A language that is targeted for embedded and/or low resource
 environments.
 It would be nice to have a modern language for low resource
 environments.

 A potential way to implement this language is to use the DMD frontend,
 then flag the unsupported features of D,
 Next create a backend, like "C front" that outputs C code instead of
 assembler.


 ===========================
 What do I envision with D-,
 D-- or Dm or what ever you want to call it.
 ===========================

 This language would basically be D without the garbage collection.
 For example there would be structures but no classes.
 There would be regular arrays but no dynamic arrays.
 Code that is mostly equivalent to C, but you would still have structures
 with functions and overloading support,
 and other features like templates etc.

 I think you get the idea.

 What are your thoughts?

I don't see the point. C++ was the last systems programming language without GC getting market share. I seriously doubt any new systems programming language without GC will ever suceed. Specially since systems programming in MacOS X and Windows world is

Systems programming in the MacOS X and Windows world isn't real systems programming. The closest you get is kernel and driver work but even there you have most of an OS to work with. I think the kind of systems programming being considered is embedded work and/or things like BIOS work.

Systems programming is everything you need to get an OS up and running. At least it was so a few decades back when I attended computer science and informatics engineering course. Regarding embedded and BIOS work, many systems being used today still required a custom C compiler without full ANSI C support, so how would such systems support a D- implementation? -- Paulo
Feb 11 2012
parent reply bcs <bcs example.com> writes:
On 02/11/2012 09:19 AM, Paulo Pinto wrote:
 Am 11.02.2012 18:00, schrieb bcs:
 On 02/11/2012 12:58 AM, Paulo Pinto wrote:
 Specially since systems programming in MacOS X and Windows world is

Systems programming in the MacOS X and Windows world isn't real systems programming. The closest you get is kernel and driver work but even there you have most of an OS to work with. I think the kind of systems programming being considered is embedded work and/or things like BIOS work.

Systems programming is everything you need to get an OS up and running. At least it was so a few decades back when I attended computer science and informatics engineering course.

OK then there may be some people doing systems programming for MacOS X and Windows, but they all work for Apple and MS.
 Regarding embedded and BIOS work, many systems being used today still
 required a custom C compiler without full ANSI C support, so how would
 such systems support a D- implementation?

 --
 Paulo

Feb 11 2012
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 12.02.2012 03:03, schrieb bcs:
 On 02/11/2012 09:19 AM, Paulo Pinto wrote:
 Am 11.02.2012 18:00, schrieb bcs:
 On 02/11/2012 12:58 AM, Paulo Pinto wrote:
 Specially since systems programming in MacOS X and Windows world is

Systems programming in the MacOS X and Windows world isn't real systems programming. The closest you get is kernel and driver work but even there you have most of an OS to work with. I think the kind of systems programming being considered is embedded work and/or things like BIOS work.

Systems programming is everything you need to get an OS up and running. At least it was so a few decades back when I attended computer science and informatics engineering course.

OK then there may be some people doing systems programming for MacOS X and Windows, but they all work for Apple and MS.

So do you mean everyone doing device driver development are also working for them? As well as all the companies writing services/daemons with low level protocols for optimal perfomance? -- Paulo
Feb 12 2012
parent bcs <bcs example.com> writes:
On 02/12/2012 12:32 AM, Paulo Pinto wrote:
 Am 12.02.2012 03:03, schrieb bcs:
 On 02/11/2012 09:19 AM, Paulo Pinto wrote:
 Am 11.02.2012 18:00, schrieb bcs:
 On 02/11/2012 12:58 AM, Paulo Pinto wrote:
 Specially since systems programming in MacOS X and Windows world is

Systems programming in the MacOS X and Windows world isn't real systems programming. The closest you get is kernel and driver work but even there you have most of an OS to work with. I think the kind of systems programming being considered is embedded work and/or things like BIOS work.

Systems programming is everything you need to get an OS up and running. At least it was so a few decades back when I attended computer science and informatics engineering course.

OK then there may be some people doing systems programming for MacOS X and Windows, but they all work for Apple and MS.

So do you mean everyone doing device driver development are also working for them?

I've never worked on them but I seem to recall from somewhere that Windows drivers operate in an environment that has a lot of "supporting infrastructure". Assuming that's not off in the weeds, I suspect the cases is not to different for OS-x.
 As well as all the companies writing services/daemons with low level
 protocols for optimal perfomance?

If you are working in user mode your claim to doing systems programming is weakened. The same goes if any part of your program can afford to use a GC. I will grant that there is a lot of ground between that and the "very much not systems programming" type of work that goes into a things like web apps. However, I would assert that a formal D- sub-set/dialect would mostly be of use on the core kernel development and embedded-systems/micro-controllers end of things. Outside that, I suspect that >90% of the advantage can be had via a well selected style guide.
Feb 14 2012
prev sibling next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
This is actually probably not that difficult to do.

A C backend for dmd would be quite difficult to make - but if you strip out 
most of the complex features that make it to code generation (exceptions, 
garbage collected memory, tls, classes, array ops, threading, floating 
point, typeinfo, destructors, postblits etc) then the actual code generated 
doesn't need to be that complex.

This could be (well, it _should_ be, stuff like array ops currently happens 
in the frontend) implemented completely in the glue layer of the compiler, 
with everything not supported just stubbed out. 
Feb 11 2012
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 11.02.2012 16:32, schrieb Daniel Murphy:
 This is actually probably not that difficult to do.

 A C backend for dmd would be quite difficult to make - but if you strip out
 most of the complex features that make it to code generation (exceptions,
 garbage collected memory, tls, classes, array ops, threading, floating
 point, typeinfo, destructors, postblits etc) then the actual code generated
 doesn't need to be that complex.

If you remove all of that then how good would D- be in regard with existing languages being used for the same tasks? For example, MikroEletronica sells C, Basic and Pascal compilers that target everything from a small PIC up to big ARMs. http://www.mikroe.com/eng/products/view/754/mikropascal-pro-for-arm/ I can also get Ada for embedded systems programming, which was actually one of Ada's design goals, http://www.adacore.com/home/products/gnatpro/development_solutions/embedded/?gclid=CJ-7yNeImK4CFUGIDgodXT4CJQ So what does D- bring to the table, besides fragmenting the community? -- Paulo
Feb 12 2012
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Paulo Pinto" <pjmlp progtools.org> wrote in message 
news:jh7v08$2chs$1 digitalmars.com...
 If you remove all of that then how good would D- be in regard with 
 existing languages being used for the same tasks?

You still have all of D's compile-time magic, which I miss every time I need to do embedded programming. You still have the simple syntax improvement. I would love to be able to do away with the preprocessor and stupidly_long_method_names_because_of_no_overloading_or_method_syntax.
 So what does D- bring to the table, besides fragmenting the community?

No need to fork the lanugage - just add a couple of pragmas and a basic C backend.
Feb 12 2012
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 12.02.2012 11:55, schrieb Daniel Murphy:
 "Paulo Pinto"<pjmlp progtools.org>  wrote in message
 news:jh7v08$2chs$1 digitalmars.com...
 If you remove all of that then how good would D- be in regard with
 existing languages being used for the same tasks?

You still have all of D's compile-time magic, which I miss every time I need to do embedded programming. You still have the simple syntax improvement. I would love to be able to do away with the preprocessor and stupidly_long_method_names_because_of_no_overloading_or_method_syntax.

Overloading is also possible with C++. I know compile-time magic is messy (to say the least) with C++, still it is already there.
 So what does D- bring to the table, besides fragmenting the community?

No need to fork the lanugage - just add a couple of pragmas and a basic C backend.

How basic would this C backend be? Specially taking into account it would be one extra backend to support and not all embedded processors are even able to support full ANSI C even on this day and age. I am just playing a bit the devil's advocate here, as I think our industry suffers a lot from the "Worse is Better" principle, and as such one really needs to think about ROI when proposing new solutions for problems with existing solutions, even if they aren't the best ones. -- Paulo
Feb 12 2012
next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Paulo Pinto" <pjmlp progtools.org> wrote in message 
news:jh87aj$2upa$1 digitalmars.com...
 Overloading is also possible with C++.

 I know compile-time magic is messy (to say the least) with C++, still it 
 is already there.

Having D able to work on embedded platforms isn't going to enable anything that wasn't possible, it will just make it easier and more pleasant.
 So what does D- bring to the table, besides fragmenting the community?

No need to fork the lanugage - just add a couple of pragmas and a basic C backend.

How basic would this C backend be? Specially taking into account it would be one extra backend to support and not all embedded processors are even able to support full ANSI C even on this day and age.

Honestly, I don't really know. I've never written a C backend before. I know the compiler already has code to print expressions and statements back out as D code, and this is not incredibly complex. I don't know if it's possible to really keep it simple, but if it is... The great thing about it only being a backend is that it benefits from all the work that goes into the frontend, and that is where most of the development is these days. Not trying to support all D features means a lot of code can be directly mapped to C code - if you take out everything on my list, how much stuff in D is actually not supported by C?
 I am just playing a bit the devil's advocate here, as I think our industry 
 suffers a lot from the "Worse is Better" principle, and as such
 one really needs to think about ROI when proposing new solutions for
 problems with existing solutions, even if they aren't the best ones.

Yeah well, I'm not really discussing this as a solution to anything, just something interesting to try out. Nobody sane would try to make something that works on every microprocessor out there, but if it was pluggable and open source, maybe people would rather be writing D than C? I know I would, even for extremely low-level stuff.
Feb 12 2012
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
Turns out I can't help myself:

https://github.com/yebblies/dmd/tree/microd
(the makefile changes are win32 only, but aren't very compilcated)

It compiles the following into cryptic c full of mangled names just fine:

__gshared int global = 3;

int main()
{
    uint x;
    foreach(i; 0..20)
    {
        x += i;
    }
    return 0;
}

Doesn't seem that hard.  Dmd would need support for 8/16 bit pointers and a 
few other things, but I think most of the customization could be done with 
some well-defined macros and per-architecture header files.  Some features 
are implemented in wrong part of the compiler, and will cause problems. 
Feb 12 2012
next sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Iain Buclaw" <ibuclaw ubuntu.com> wrote in message 
news:mailman.287.1329145247.20196.digitalmars-d puremagic.com...
 O_O

=) Which bit's making you pull that face? Is it the fact I think it might be a good idea or the fact I think it wouldn't be that hard? It currently can translate: import core.stdc.stdio; __gshared int global = 3; struct S { int a; void fun() { printf("member a: %d\n", a); } } int main() { uint x; foreach(i; 0..20) { x += i; } printf("%d\n", x); S y = S(7); y.a += 5; y.fun(); return 0; } into typedef struct __d_5testx1S __d_5testx1S; __d_int _D5testx6globali; struct __d_5testx1S { __d_int _D5testx1S1ai; }; __d_int _Dmain(); __d_void _D5testx1S3funMFZv(__d_5testx1S* _D5testx1S3funMFZv4thisS5testx1S); __d_int _D5testx6globali = 3; __d_int _Dmain() { __d_uint _D5testx4mainFZi1xk = 0u; for (__d_int _D5testx4mainFZi1ii = 0, _D5testx4mainFZi8__limit3i = 20; (_D5testx4mainFZi1ii < _D5testx4mainFZi8__limit3i); (_D5testx4mainFZi1ii += 1)) (_D5testx4mainFZi1xk += ((__d_uint)_D5testx4mainFZi1ii)); printf("%d\x0a", _D5testx4mainFZi1xk); __d_5testx1S _D5testx4mainFZi1yS5testx1S = {7}; ((_D5testx4mainFZi1yS5testx1S)._D5testx1S1ai += 5); _D5testx1S3funMFZv(&_D5testx4mainFZi1yS5testx1S); return 0; } __d_void _D5testx1S3funMFZv(__d_5testx1S* _D5testx1S3funMFZv4thisS5testx1S) { &*_D5testx1S3funMFZv4thisS5testx1S || __d_assert_msg(__d_array("null this", 9), __d_array("testx.d", 7), 9);; printf("member a: %d\x0a", (*_D5testx1S3funMFZv4thisS5testx1S)._D5testx1S1ai); } Looking at that, it seems I'd forgotten just how ugly C really is.
Feb 13 2012
prev sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:rdluxkzwxsxlxfgcaqle dfeed.kimsufi.thecybershadow.net...
 On Sunday, 12 February 2012 at 17:45:46 UTC, Daniel Murphy wrote:
 Turns out I can't help myself:

 https://github.com/yebblies/dmd/tree/microd

hmmm.... Do you see anything wrong with using a similar strategy to output something like C# or Java? It might be a relatively easy way to get (a subset of) D integrated into those environments.

C works because you can build all the high level features of D (classes, exceptions, etc) out of C and assembler. You can build high-level features out of low-level ones, but not the other way around. I don't know how C#/Java would handle things like value types, unions, pointers, interior pointers etc. I'm not sure, but I think there might be some limitations in the underlying bytecode that prevents some of these things, and unlike C you can't drop down to assembler to fill in the gaps. So I guess it depends on which features you want - you'd lose some of the low-level features, and might be unable to build the high-level features without them.
Feb 13 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/12/2012 12:20 PM, Paulo Pinto wrote:
 Am 12.02.2012 11:55, schrieb Daniel Murphy:
 "Paulo Pinto"<pjmlp progtools.org> wrote in message
 news:jh7v08$2chs$1 digitalmars.com...
 If you remove all of that then how good would D- be in regard with
 existing languages being used for the same tasks?

You still have all of D's compile-time magic, which I miss every time I need to do embedded programming. You still have the simple syntax improvement. I would love to be able to do away with the preprocessor and stupidly_long_method_names_because_of_no_overloading_or_method_syntax.

Overloading is also possible with C++.

So is garbage collection.
 I know compile-time magic is messy (to say the least) with C++, still it
 is already there.

I wouldn't go as far as to call it magic.
 So what does D- bring to the table, besides fragmenting the community?

No need to fork the lanugage - just add a couple of pragmas and a basic C backend.

How basic would this C backend be? Specially taking into account it would be one extra backend to support and not all embedded processors are even able to support full ANSI C even on this day and age. I am just playing a bit the devil's advocate here, as I think our industry suffers a lot from the "Worse is Better" principle,

Very true and very sad.
 and as such one really needs to think about ROI when proposing new solutions
for
 problems with existing solutions, even if they aren't the best ones.

The D philosophy is "The Right Thing". Therefore it is adequate to discuss better solutions for 'solved' problems on this NG.
Feb 12 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Murphy" <yebblies nospamgmail.com> wrote in message 
news:jh85rp$2rs4$1 digitalmars.com...
 "Paulo Pinto" <pjmlp progtools.org> wrote in message 
 news:jh7v08$2chs$1 digitalmars.com...
 If you remove all of that then how good would D- be in regard with 
 existing languages being used for the same tasks?

You still have all of D's compile-time magic, which I miss every time I need to do embedded programming. You still have the simple syntax improvement. I would love to be able to do away with the preprocessor and stupidly_long_method_names_because_of_no_overloading_or_method_syntax.

Plus a module system that's actually sane.
Feb 12 2012
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 12.02.2012 15:27, schrieb Nick Sabalausky:
 "Daniel Murphy"<yebblies nospamgmail.com>  wrote in message
 news:jh85rp$2rs4$1 digitalmars.com...
 "Paulo Pinto"<pjmlp progtools.org>  wrote in message
 news:jh7v08$2chs$1 digitalmars.com...
 If you remove all of that then how good would D- be in regard with
 existing languages being used for the same tasks?

You still have all of D's compile-time magic, which I miss every time I need to do embedded programming. You still have the simple syntax improvement. I would love to be able to do away with the preprocessor and stupidly_long_method_names_because_of_no_overloading_or_method_syntax.

Plus a module system that's actually sane.

+1 on this one actually. C, C++ and Objective-C are the only languages without proper module support. I really miss my Turbo Pascal days, where compilation was just instantanious. -- Paulo
Feb 12 2012
prev sibling next sibling parent "q66" <quaker66 gmail.com> writes:
On Saturday, 11 February 2012 at 16:08:02 UTC, Jacob Carlborg 
wrote:
 On 2012-02-11 15:36, Nick Sabalausky wrote:
 "Era Scarecrow"<rtcvb32 yahoo.com>  wrote in message
 news:jzavmzbmjoyujhqyfvhp dfeed.kimsufi.thecybershadow.net...
 What are your thoughts?

There is no way you get a D application into 64K. The language is not powerful enough. Only C can achieve that.

I'll need to agree. Porting D to a smaller memory space and with cramped features in all of this is not going to be good no matter how you look at it. I'm sure it's similar to comparing using perl in something with only 64k of memory, one must ask where you can put the interpreter, decoding and working with the source text, and many other things, not to mention even if you pulled it off, the speed penalty. With only 64k, you aren't going to need anything extremely complex or elaborate. You MIGHT get away with exporting D code to using C symbols, but you'll likely be stuck working with structs, no library support, no heap, no memory management, and fixed-sized arrays. I doubt you'd need templates, or any of the higher functions. All structures and types must be basic or known statically at compile time. Unlikely for lambdas to be used, and a score of other features. This is all just speculation, but I think you get the picture. If you make a subset of D, it would most likely be named Mini-D. But at that point you've got an enhanced C without going C++.

That would *still* be a very notable improvement over C. Hell, if you ask me, a proper module system alone is one of the killer features of D over C. Header files? Seriously? Fuck that shit. What the hell is this, 1970? And then there's other things that are *at the very least* icing on the cake: Faster compilation, slicing, better safety, metaprogramming (esp CTFE) that whups C's ass and makes it much less less tempting to do things at runtime that don't need to be done at runtime. That's all just off the top of my head.

I think slicing is quite difficult without a GC. Not the actual slicing but freeing the memory.

What's so difficult on that? Slices do not require the GC, you allocate once, slice many times, deallocate once.
Feb 11 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Feb 11, 2012 at 11:55:07AM -0600, Andrei Alexandrescu wrote:
 On 2/11/12 8:48 AM, Nick Sabalausky wrote:

I absolutely agree: We've learned a very hard lession from the
community-fragmenting failure that was known as SafeD.

Not sure what you mean there. As far as I can tell SafeD did not fail and there was no community fragmentation at any point because of it.

AFAIK, SafeD is just incompletely implemented, right? But it exists and it will be done one day. T -- Жил-был король когда-то, при нём блоха жила.
Feb 11 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 11 February 2012 17:47, Artur Skawina <art.08.09 gmail.com> wrote:
 On 02/11/12 02:46, Era Scarecrow wrote:
 There is no way you get a D application into 64K. The language is not p=



 I'll need to agree. Porting D to a smaller memory space and with cramped=


it. I'm sure it's similar to comparing using perl in something with only 64= k of memory, one must ask where you can put the interpreter, decoding and w= orking with the source text, and many other things, not to mention even if = you pulled it off, the speed penalty.
 With only 64k, you aren't going to need anything extremely complex or el=


 You MIGHT get away with exporting D code to using C symbols, but you'll =


y management, and fixed-sized arrays. I doubt you'd need templates, or any = of the higher functions. All structures and types must be basic or known st= atically at compile time. Unlikely for lambdas to be used, and a score of o= ther features.
 This is all just speculation, but I think you get the picture. If you ma=


ou've got an enhanced C without going C++.

I assumed the poster you're replying to was not being serious. There's absolutely no difference between the code generated from C and D, unless you use a few D-only concepts; ignoring compiler issues. Having several levels of modules and templates, that in the end emit single CPU instructions is not only possible, it lets you write completely generic code that's both safer and not less efficient than writing the equivalent in assembler. I can easily see D being acceptable for 8K projects, 64K would probably allow for a mostly complete runtime.

I'd imagine the general idea is, just how much of druntime can we strip away and still have the compiler be happy with all it's implicit library calls. After that, then decide what we don't *need*, or could do in an alternative way and achieve the same result (without loosing safeness). I'd imagine there's quite a few things that could be done differently depending on whether the compiler is building with the assumption the program is going to be free standing environment, or will depend on some sort of runtime existing that we'll link to. What can't be done may most likely be an error. --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Feb 11 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, February 11, 2012 19:00:51 q66 wrote:
 What's so difficult on that? Slices do not require the GC, you
 allocate once, slice many times, deallocate once.

With dynamic arrays, the GC owns the memory, and _all_ dynamic arrays are slices. _None_ of them own their own memory. The GC keeps track of whether you have any slices for a particular memory block and deals with freeing up wth the block if you don't. However, if you allocate a dynamic array without the GC, then all of a sudden, it effectively owns its own memory, so the semantics of dealing with arrays and memories changes drastically. What happens when you slice it? Which one owns the memory? What happens when you try and do stuff like popFront on an array? All of a sudden, you have memory which is no longer referenced. It's been leaked. If you have a very careful scheme for handling memory, you _can_ slice arrays without a GC, but you have to worry about all the bookkeeping of keeping track of the originally allocated memory and how many slices reference it so that you can free it when appropriate. Also, you can't concatenate to arrays at all, because that requires the GC. So, you're dealing with a mine field if you try and use D's array capabilities without a GC. Yes, you _can_ use some of them if you're _very_ careful, but I'd seriously advise just sticking to using arrays like you would in C except for the fact that arrays know their length. - Jonathan M Davis
Feb 11 2012
parent "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.242.1328986002.20196.digitalmars-d puremagic.com...
 On Saturday, February 11, 2012 19:00:51 q66 wrote:
 What's so difficult on that? Slices do not require the GC, you
 allocate once, slice many times, deallocate once.

With dynamic arrays, the GC owns the memory, and _all_ dynamic arrays are slices.

But not all slices are slices of dynamic arrays.
 _None_ of them own their own memory. The GC keeps track of whether you
 have any slices for a particular memory block and deals with freeing up 
 wth
 the block if you don't. However, if you allocate a dynamic array without 
 the
 GC, then all of a sudden, it effectively owns its own memory, so the 
 semantics
 of dealing with arrays and memories changes drastically. What happens when 
 you
 slice it? Which one owns the memory? What happens when you try and do 
 stuff
 like popFront on an array? All of a sudden, you have memory which is no 
 longer
 referenced. It's been leaked.

 If you have a very careful scheme for handling memory, you _can_ slice 
 arrays
 without a GC, but you have to worry about all the bookkeeping of keeping 
 track
 of the originally allocated memory and how many slices reference it so 
 that
 you can free it when appropriate.

Yea, manual memory management is hard and you have to be careful. That's true slices or not.
 Also, you can't concatenate to arrays at all, because that requires the 
 GC.

That's true (at least without providing some way to provide an alternate concatenation allocator). But nobody said that all D features would be usable.
 So, you're dealing with a mine field if you try and use D's array 
 capabilities
 without a GC. Yes, you _can_ use some of them if you're _very_ careful, 
 but
 I'd seriously advise just sticking to using arrays like you would in C 
 except
 for the fact that arrays know their length.

Arrays knowing their own length *is* a notable improvement over C.
Feb 11 2012
prev sibling next sibling parent "Tim Krimm" <twkrimm yahoo.com> writes:
On Saturday, 11 February 2012 at 18:53:13 UTC, Andrei 
Alexandrescu wrote:
 On 2/11/12 12:28 PM, Timon Gehr wrote:
 Nick was quite obviously being sarcastic. ;)

oops... Andrei

I am sorry Andrei, I think I stirred up a rats nest with this D- or EmbeddedD stuff.
Feb 11 2012
prev sibling next sibling parent "Zachary Lund" <admin computerquip.com> writes:
On Saturday, 11 February 2012 at 19:21:49 UTC, Piotr Szturmaj 
wrote:
 Jonathan M Davis wrote:
 On Saturday, February 11, 2012 19:00:51 q66 wrote:
 What's so difficult on that? Slices do not require the GC, you
 allocate once, slice many times, deallocate once.

With dynamic arrays, the GC owns the memory, and _all_ dynamic arrays are slices. _None_ of them own their own memory. The GC keeps track of whether you have any slices for a particular memory block and deals with freeing up wth the block if you don't. However, if you allocate a dynamic array without the GC, then all of a sudden, it effectively owns its own memory, so the semantics of dealing with arrays and memories changes drastically. What happens when you slice it? Which one owns the memory? What happens when you try and do stuff like popFront on an array? All of a sudden, you have memory which is no longer referenced. It's been leaked. If you have a very careful scheme for handling memory, you _can_ slice arrays without a GC, but you have to worry about all the bookkeeping of keeping track of the originally allocated memory and how many slices reference it so that you can free it when appropriate. Also, you can't concatenate to arrays at all, because that requires the GC. So, you're dealing with a mine field if you try and use D's array capabilities without a GC. Yes, you _can_ use some of them if you're _very_ careful, but I'd seriously advise just sticking to using arrays like you would in C except for the fact that arrays know their length.

Delphi has dynamic arrays and appendable strings without a GC. In Delphi pointers and objects are managed manually, but arrays and strings are managed automatically (ref counted with Copy-On-Write). Take a look at http://www.codexterity.com/delphistrings.htm. Maybe some Delphi solutions may be used in NoGcD?

It's possible that we just create our own dynamic array similar to that of std::vector from C++ except using cleaner syntax available in D. I'd really rather not do that though since it feels redundant.
Feb 11 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, February 11, 2012 18:01:05 Nick Sabalausky wrote:
 But not all slices are slices of dynamic arrays.

But all slices are still dynamic arrays, even if they refer to a static array. They just have a capacity of 0, so any appending will result in them being reallocated. And slicing static arrays is one of those things that you generally have to be careful about precisely because they aren't managed by the GC and can go out of scope before their slices do.
 Yea, manual memory management is hard and you have to be careful. That's
 true slices or not.

Yes, but in this case, you're dealing with a language feature which is _designed_ to be managed by the GC. It's not designed for manual memory management at all. It's a completely different situation when you're dealing with user-defined types.
 Arrays knowing their own length *is* a notable improvement over C.

Indeed, but that's pretty much the only improvement that D makes to arrays which is safe to use without a GC without being _very_, _very_ careful. - Jonathan M Davis
Feb 11 2012
parent Zachary Lund <admin computerquip.com> writes:
On 02/11/2012 07:00 PM, Jonathan M Davis wrote:
 On Sunday, February 12, 2012 01:40:50 Zachary Lund wrote:
 Btw, I'm not very fluent in the inner workings of a garbage
 collector implementation but how does one go about concatenating
 to an array in a garbage collector as compared to manual memory
 management? I believe array concatenation can be done in
 std::vector with the insert() function just fine. Isn't it as
 simple as determining both array sizes and allocating enough
 memory for both arrays? I could be oversimplifying things...

Read this: http://www.dsource.org/projects/dcollections/wiki/ArrayArticle Appending to vectors is very different from appending to dynamic arrays because dynamic arrays do _not_ own their own memory (the GC does) and not only could other slices refer the same memory (in which case, you can't just free that memory when an array gets reallocated due to running out of space to append to), but they could already refer to the memory one past the end of the array, making it so that it can't expand into that memory. Slices change the entire equation. And the way slices are designed, they require the GC. - Jonathan M Davis

Right but they use the same semantics and the information to do either seems to be present. I'm not sure why an abstraction between the two cannot be made.
Feb 13 2012
prev sibling next sibling parent "Zachary Lund" <admin computerquip.com> writes:
On Sunday, 12 February 2012 at 00:29:35 UTC, Jonathan M Davis 
wrote:
 On Saturday, February 11, 2012 18:01:05 Nick Sabalausky wrote:
 But not all slices are slices of dynamic arrays.

But all slices are still dynamic arrays, even if they refer to a static array. They just have a capacity of 0, so any appending will result in them being reallocated. And slicing static arrays is one of those things that you generally have to be careful about precisely because they aren't managed by the GC and can go out of scope before their slices do.
 Yea, manual memory management is hard and you have to be 
 careful. That's
 true slices or not.

Yes, but in this case, you're dealing with a language feature which is _designed_ to be managed by the GC. It's not designed for manual memory management at all. It's a completely different situation when you're dealing with user-defined types.
 Arrays knowing their own length *is* a notable improvement 
 over C.

Indeed, but that's pretty much the only improvement that D makes to arrays which is safe to use without a GC without being _very_, _very_ careful. - Jonathan M Davis

Btw, I'm not very fluent in the inner workings of a garbage collector implementation but how does one go about concatenating to an array in a garbage collector as compared to manual memory management? I believe array concatenation can be done in std::vector with the insert() function just fine. Isn't it as simple as determining both array sizes and allocating enough memory for both arrays? I could be oversimplifying things...
Feb 11 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, February 12, 2012 01:40:50 Zachary Lund wrote:
 Btw, I'm not very fluent in the inner workings of a garbage
 collector implementation but how does one go about concatenating
 to an array in a garbage collector as compared to manual memory
 management? I believe array concatenation can be done in
 std::vector with the insert() function just fine. Isn't it as
 simple as determining both array sizes and allocating enough
 memory for both arrays? I could be oversimplifying things...

Read this: http://www.dsource.org/projects/dcollections/wiki/ArrayArticle Appending to vectors is very different from appending to dynamic arrays because dynamic arrays do _not_ own their own memory (the GC does) and not only could other slices refer the same memory (in which case, you can't just free that memory when an array gets reallocated due to running out of space to append to), but they could already refer to the memory one past the end of the array, making it so that it can't expand into that memory. Slices change the entire equation. And the way slices are designed, they require the GC. - Jonathan M Davis
Feb 11 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 12 February 2012 17:45, Daniel Murphy <yebblies nospamgmail.com> wrote:
 Turns out I can't help myself:

 https://github.com/yebblies/dmd/tree/microd
 (the makefile changes are win32 only, but aren't very compilcated)

 It compiles the following into cryptic c full of mangled names just fine:

 __gshared int global =3D 3;

 int main()
 {
 =A0 =A0uint x;
 =A0 =A0foreach(i; 0..20)
 =A0 =A0{
 =A0 =A0 =A0 =A0x +=3D i;
 =A0 =A0}
 =A0 =A0return 0;
 }

 Doesn't seem that hard. =A0Dmd would need support for 8/16 bit pointers a=

 few other things, but I think most of the customization could be done wit=

 some well-defined macros and per-architecture header files. =A0Some featu=

 are implemented in wrong part of the compiler, and will cause problems.

O_O --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Feb 13 2012
prev sibling next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 13 February 2012 15:31, Daniel Murphy <yebblies nospamgmail.com> wrote:
 "Iain Buclaw" <ibuclaw ubuntu.com> wrote in message
 news:mailman.287.1329145247.20196.digitalmars-d puremagic.com...
 O_O

=3D) Which bit's making you pull that face? =A0Is it the fact I think it =

 be a good idea or the fact I think it wouldn't be that hard?

It's the fact that it does *nothing* to change code generation, as D code compiles down to the same as C equivalent. /* SNIP */
 Looking at that, it seems I'd forgotten just how ugly C really is.

Code represented like that is exactly what gdc emits to it's backend for your example, albeit, a in a little bit more simplified language (and a little bit more optimized once it goes through all codegen passes =3D) --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Feb 13 2012
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Iain Buclaw" <ibuclaw ubuntu.com> wrote in message 
news:mailman.288.1329151783.20196.digitalmars-d puremagic.com...
 It's the fact that it does *nothing* to change code generation, as D
 code compiles down to the same as C equivalent.

Isn't that what a C backend is supposed to do?
 Code represented like that is exactly what gdc emits to it's backend
 for your example, albeit, a in a little bit more simplified language
 (and a little bit more optimized once it goes through all codegen
 passes =)

That's a good point. Maybe this effort would be better spent trying to build avr-gdc instead of the compiler centipede.
Feb 13 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 12 February 2012 at 17:45:46 UTC, Daniel Murphy wrote:
 Turns out I can't help myself:

 https://github.com/yebblies/dmd/tree/microd

hmmm.... Do you see anything wrong with using a similar strategy to output something like C# or Java? It might be a relatively easy way to get (a subset of) D integrated into those environments.
Feb 13 2012
prev sibling next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 13 February 2012 17:22, Daniel Murphy <yebblies nospamgmail.com> wrote:
 "Iain Buclaw" <ibuclaw ubuntu.com> wrote in message
 news:mailman.288.1329151783.20196.digitalmars-d puremagic.com...
 It's the fact that it does *nothing* to change code generation, as D
 code compiles down to the same as C equivalent.

Isn't that what a C backend is supposed to do?

My point is that D is low level / slick enough, that it generates near-identical code to C/C++ in comparison benchmarks - recent example I can recall, someone did a speed test on vectors in GDC vs G++, and found both to be pretty much on par with each other. Then again, I wouldn't expect less when both use the same backend.
 Code represented like that is exactly what gdc emits to it's backend
 for your example, albeit, a in a little bit more simplified language
 (and a little bit more optimized once it goes through all codegen
 passes =3D)

That's a good point. =A0Maybe this effort would be better spent trying to build avr-gdc instead of the compiler centipede.

I think it starts with a runtime library that is written for the given architecture in mind. The compiler is already there in my opinion, and I have seen little reason for it not to be. --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Feb 13 2012
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Iain Buclaw" <ibuclaw ubuntu.com> wrote in message
 I think it starts with a runtime library that is written for the given
 architecture in mind.  The compiler is already there in my opinion,
 and I have seen little reason for it not to be.

Is the compiler really ready? Assuming that it's possible to build gdc as (for eg) an avr cross compiler, you'll still need support for: - 16 bit pointers - program memory - interrupts - IO registers - stripping out typeinfo/moduleinfo - issuing errors for unsupported features - inline assembler If gdc can do most of this already, that's great - but I doubt it can do all of it.
Feb 13 2012
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, February 13, 2012 20:41:01 Zachary Lund wrote:
 On 02/11/2012 07:00 PM, Jonathan M Davis wrote:
 On Sunday, February 12, 2012 01:40:50 Zachary Lund wrote:
 Btw, I'm not very fluent in the inner workings of a garbage
 collector implementation but how does one go about concatenating
 to an array in a garbage collector as compared to manual memory
 management? I believe array concatenation can be done in
 std::vector with the insert() function just fine. Isn't it as
 simple as determining both array sizes and allocating enough
 memory for both arrays? I could be oversimplifying things...

Read this: http://www.dsource.org/projects/dcollections/wiki/ArrayArticle Appending to vectors is very different from appending to dynamic arrays because dynamic arrays do _not_ own their own memory (the GC does) and not only could other slices refer the same memory (in which case, you can't just free that memory when an array gets reallocated due to running out of space to append to), but they could already refer to the memory one past the end of the array, making it so that it can't expand into that memory. Slices change the entire equation. And the way slices are designed, they require the GC. - Jonathan M Davis

Right but they use the same semantics and the information to do either seems to be present. I'm not sure why an abstraction between the two cannot be made.

I'm not sure what you're saying. All dynamic arrays are slices and _none_ of them own their own memory. As such, you need a way to manage their memory. Vectors, on the other hand, own their memory and do not allow slicing at all. - Jonathan M Davis
Feb 13 2012