On processors for D ~ decoupling

[Walter Bright]

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.


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

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


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


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