February 10, 2012
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
February 10, 2012
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.
February 11, 2012
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.
February 11, 2012
>> 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++.
February 11, 2012
> 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.
February 11, 2012
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.

February 11, 2012
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

February 11, 2012
>> 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.
February 11, 2012
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.
February 11, 2012
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.