On processors for D ~ decoupling

[kris]

As I said, that viewpoint is from my perspective ~ the intent was 
certainly not to elicit a defensive response. Instead, I'd hoped you'd 
be open to some suggestions;

More inline:


Walter Bright wrote:
> kris wrote:
> 
>> Walter Bright wrote:
>>
>>> I'd like to get to the bottom of this feeling. For example, Kris was 
>>> unhappy that typeinfo imported std.strings. I can't figure out what 
>>> the problem with that is.
>>
>>
>>
>> I'll try to explain it from my perspective:
>>
>> 1) You show an adversion to tightly coupled library modules ~ made a 
>> number of negative comments about the Java libraries in that respect ~ 
>> and have spelled out in the past a desire to duplicate code as 
>> necessary to avoid said tight coupling. This is good design, and it's 
>> one of the harder things to balance when building a library. Yet, 
>> there's flagrant cases where D tosses this out of the window along 
>> with the bathwater.
> 
> 
> The trouble with Java was that even the most trivial program pulled in 
> *everything*, including the graphics library. The typeinfo for a 
> particular type is only linked in if that type is actually used in a 
> user program.

Yes, that's correct. But typeinfo is a rather rudimetary part of the 
language support. Wouldn't you agree? If I, for example, declare an 
array of 10 bytes (static byte[10]) then I'm bound over to import 
std.string ~ simply because TypeInfo_StaticArray wants to use 
std.string.toString(int), rather than the C library version of itoa() or 
a "low-level support" version instead.

That's tight-coupling within very low-level language support. Uncool.

Wouldn't you at least agree that specific instance is hardly an absolute 
necessity?


>> Instead of adding a duplicate itoa() method (about 60 bytes of code), 
>> or perhaps linking to the C library version, TypeInfo gratuitously 
>> imports std.string and all its vast array of baggage. Heck, everyone 
>> makes mistakes, but your comment above indicates you feel this kind of 
>> tight coupling is perfectly fine?
> 
> 
> Although there is a lot of code in std.string, unreferenced free 
> functions in it should be discarded by the linker. A check of the 
> generated .map file should verify this - it is certainly supposed to 
> work that way. One problem Java has is that there are no free functions, 
> so referencing one function wound up pulling in every part of the class 
> the function resided in.

This is exactly the case with printf <g>. It winds up linking the world 
because it's a general purpose utility function that does all kinds of 
conversion and all kinds of IO. Printf() is an all or nothing design ~ 
you can't selectively link pieces of it.

That's usually not a problem. However, you've chosen to bind it to 
low-level language support (in the root Object). That choice causes 
tight coupling between the language low-level support and a high-level 
library function ~ one which ought to be optional.

Wouldn't you at least agree this specific case is not necessary for the 
D language to function correctly? That there are other perfectly 
workable alternatives?


>> Then, there's printf() being linked via Object ~ it's been 2 years 
>> since the push to have that removed (which you agreed to), yet it's 
>> now clear there's no intent to do so. So what's wrong with printf()? 
>> Well, it brings along with it almost the entire C IO library, 
>> including most of the wide-char processing and, of course, all the 
>> floating-point support, setup, and management. All completely 
>> unecessary where one doesn't use it. And it's linked at the base of 
>> the Object tree.
> 
> 
> printf doesn't pull in the floating point library (I went to a lot of 
> effort to make that so!). It does pull in the C IO library, which is 
> very hard to not pull in (there always seems to be something referencing 
> it). It shouldn't pull in the C wide character stuff. D's IO (writefln) 
> will pull in C's IO anyway, so the only thing extra is the integer 
> version of the specific printf code (about 4K).

How can it convert %f, %g and so on if it doesn't use FP support at all? 
Either way, it's not currently possible to build a D program without a 
swathe of FP support code, printf, the entire C IO package, wide-char 
support, and a whole lot more besides. I'd assumed the linked FP support 
was for printf, but perhaps it's for std.string instead? I've posted the 
linker maps (in the past) to illustrate exactly this.

There's no absolute need for most of this stuff. It shouldn't be bound 
at the low level.



>> 2) Not everyone likes Phobos. One might think you'd be happy to 
>> encourage (support, even!) alternate libraries that might far exceed 
>> the utility and/or design parameters of Phobos itself. Yet, by tightly 
>> coupling the D language to Phobos, you make life difficult for those 
>> alternate libraries. And for what reason? It makes no sense at all.
> 
> 
> The only parts of phobos directly referenced by the compiler are 
> typeinfo, object, and the code in internal.


No argument there. Yet those modules are slowly importing chunks of 
Phobos, making them dependencies also. My point is, and has always been, 
there's no need for those secondary dependencies. Especially at the 
level of language-support (like typeinfo and object).


> 
> 
>> If you'd decouple the language from the library, you'd end up with 
>> something very close to Ares. It's lean, efficient, and very flexible. 
>> In fact, it lends itself very well to others building a working D 
>> compiler & environment ~ the kind of thing that helps increase 
>> adoption by decreasing concerns. By encouraging development of 
>> alternate libraries, the D language stands a better chance of having a 
>> good one. Via judicious decoupling, you can keep the resultant 
>> executable lean and mean ~ making it more attractive to the embedded 
>> market, amongst others. D might even avoid having to link the FPU 
>> management code by default :-P
>>
>>
>> You said "Kris was unhappy that typeinfo imported std.strings. I can't 
>> figure out what the problem with that is" ~~ I hope this helps you get 
>> there.
> 
> 
> And I hope I responded adequately.


Are you not at all interested in improving this aspect of the language 
usage?