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

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

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

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

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

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.

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

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.

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

O_O


-- 
Iain Buclaw

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

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