On processors for D ~ decoupling

[kris]

Walter Bright wrote:
> kris wrote:

I see you snipped the questions about trying to understand the need for 
Ares? I thought those were realistic, reasonable, and pertinent 
questions in the search to understand why you can't understand Ares exists.

Are they just not important enough to warrant attention? Here they are 
again:

<repost>

Kris: Why do you think Ares exists anyway?

Walter: I'm trying to understand.

Kris: Ah. That makes some sense now ~ so, you're saying you don't see 
any need for a better library? That you're trying to understand what 
such a need might be?

</repost>

Those are important questions, since they'll help clarify the apparently 
vast divide between what you think of as a library, and what I do. I 
doubt very much that I'm alone upon that sea of confusion. If I were, 
Ares would not exist. I feel its important for you to be open about your 
perspective on "alternate" libraries vs Phobos ~ after all, there's a 
lot of people putting a lot of effort into making those available ...

BTW: the phrase "better library" is used there because that what Ares 
was designed to be. I now realise that you may have interpreted that as 
some kind of an "insult" to Phobos. Many pardons.


> For printf, the actual coupling problem is:
> 
> 1) It pulls in floating point formatting code. This turns out to not be 
> correct.

Mea culpa; easy mistake to make when there's nothing else referencing 
FP, wouldn't you say? Who might have guessed it were std.string instead 
of printf() ?


> 2) It's bloated. The bloat turns out to be 4K code - a big problem on an 
> 8 bit machine to be sure, but not on a 32 bit one.
> 3) It pulls in the entire C I/O system. This turns out to also not be 
> correct. It pulls in a reasonable portion of it.

Smoke & mirrors: If the C IO were not already leaking in via a number of 
other holes in the boat, then the reference within object.d would be 
solely responsible for pulling in everything that printf references. 
This does amount to a rather large majority of the C IO subsystem, as 
you know. Yes, you've made it perfectly clear that you have no interest 
in even trying to see any relationship therein.


> 4) It should be replaceable/hookable. Yes, it is.

By stubbing out dependencies? That's not what I'd call good design. If 
you think it is, then we can agree to disagree.


> On the other hand, the advantages of having a print in Object are:
> 
> 1) Every object can be relied upon to have some sort of print method.

If that has such an immeasurable value, why is it not used more? I 
submit this particular "reason to exist" is of questionable merit. D 
deserves better debugging support than object.print() ~ there's a decent 
logging package in mango.log ... doesn't even allocate memory.


> 2) Substituting a toString() is problematic because it usually requires 
> extra allocation and hence double buffering - so most I/O systems avoid 
> such designs. 

I see. The type of trivial, lazy, and inflexible debugging-output 
represented by object.print() needs to avoid double buffering at all costs?


> Also, the print is often used for debugging, and having it 
> be forced to use an allocation can upset what one is trying to debug - 
> by causing a gc collection cycle, for example.

Pardon me; std.string is the one of the worst offenders in terms of 
wasteful memory allocation that I've seen in decades. It appears that 
every single toString() method allocates from the heap, Walter. I would 
have mentioned this before, but we couldn't even get past the introduction.

To use your own words "Also, the print is often used for debugging, and 
having it be forced to use an allocation can upset what one is trying to 
debug - by causing a gc collection cycle, for example.".

I'm sure you realise that print() method invokes toString(), quite 
possibly resulting in calls to std.string.toString()? Which does wholly 
unecessary memory allocations? Pardon me, but std.string is hardly the 
shining light to be held aloft in such matters.


> 3) It being synchronized with C's IO means it doesn't screw up when 
> mixed with normal IO code.

That's really stretching: you don't need printf() to synchronize with 
normal IO. Use one of the lower layers instead, since none of the 
formatting options are actually used ~ as you know. This is a good 
example of using an "expensive" library function where a "less costly" 
one would suffice perfectly well. Again, the functionality is of 
questionable value anyway.


> No, I did not ignore it. I don't feel it's productive to rewrite the 
> functions in std.string in each module. std.string is not a burdensome 
> piece of code. 

It is most certainly burdensome, Walter. Allocating memory is one of the 
most expensive things one can do in this realm ~ std.string does it with 
gay abandon. How does that fit with your position?


> I'll agree with you that pointless and gratuitous coupling should be 
> avoided, but that is not the case with the two examples we're discussing.

I submit that printf() within object.d is gratuitous and almost entirely 
pointless. And not even used appropriately. There's fair reason why one 
won't see that kind of appendage in mainstream designs.

The coupling to std.string is indeed pulling in unwarranted FP support, 
so there is clearly an issue there. Std.string also happens to allocate 
memory for each toString() method (looks like all of them do?). That is 
harldy wise to do at a low level, especially where it can be easily 
avoided. You spelt out some reasons to avoid that yourself, vis-a-vis 
allocation whilst debugging.



> 
>> Looking again at your recital of adamant examples, I'm rather sorry, 
>> and entirely disappointed that's all you got from this exchange.
> 
> 
> I used the word adamant because you haven't acknowledged that I've 
> addressed the underlying __fltused and std.uni issues, you haven't 
> acknowledged that they are solvable compiler issues rather than library 
> design issues, and just keep pushing the same solution.

Sigh


> I shall reiterate that what I was doing was addressing what the 
> underlying issue with coupling was. If those can be successfully 
> addressed, then there is no coupling issue.

I'm very happy you found some problems and were able to rectify them. 
That's great! But that doesn't, in any shape or form, mean there's no 
coupling issues. You think these are the only examples? You feel it's OK 
for std.string to be allocating from the heap, when it can easily be 
avoided instead? That it's cool for low level language-support code 
(like object.d) to be invoking the GC where it could easily be avoided?

I don't. But, I'd be perfectly content if you were to leave it just as it is