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

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
>
> =) 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'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 =)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

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

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

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.

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.

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

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

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 =)
>
> That's a good point.  Maybe 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.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

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.