A quick comment: I understand what you're asking for and I personally think that it is important as well but remember that "quick-and-dirty today" often equals "major legacy problem" tomorrow. I bet a lot of bloat in existing software can be attributed to this type of thing. Those are some footsteps that we would rather not follow and I think you don't want us headed that way either. I believe Carl already has in mind how he wants to solve these types of formatting issues within REBOL. I don't know when it'll happen though. Take care, Sterling > Within the recent benchmark discussion, Gabriele made a comment > which reminded me of a suggestion I have been meaning to make > for some time. > > Almost every real application I write has a need for at least a > rudimentary level of output formatting. Examples include: > > - truncating strings and/or padding strings with trailing blanks > to a fixed length, > > - converting numerical values to string values, padding with > leading blanks to a fixed length, > > - formatting decimal values as strings, complete with the usual > sorts of leading-blank, trailing-zero, fractional-rounding > string thrashing, > > - combining all of the above with interpolation into literal > string data to form an entire message or output line. > > > I understand/assume that the underlying REBOL infrastructure is > written in C. > > Therefore... > > Please consider exposing an interface to printf-style formatting > of data values into text. Let me quickly say that I don't view > printf as anything NEAR the acme of readability or elegance, but > it has a few offsetting benefits to compensate for its offputting > appearance: > > 1) It's already in C, which I assume means it could be exposed > in REBOL more quickly than a completely new formatting scheme > could be conceived, designed, and developed. I certainly > understand that RT has MANY priorities and demands on your > time and personnel; I view this need as basic enough to > justify considering a bit of a quick-and-dirty solution (and > printf ain't hospital sanitary...) > > 2) It could serve as the underlying mechanism supporting nicer > interfaces that could be build above as mezzanine functions. > > 3) A large portion of professional programmers have been exposed > (in the epidemiological sense ;-) to C, and therefore would > require almost no training or documentation to be able to > use printf-style format strings. > > 4) It could provide a "standard" means of bridging the need until > RT has the time to build a more elegant, REBOL-style solution. > (Here I use "standard" in the sense of "available to everyone > using REBOL", without the need to write one's own or go find > some code written by someone else.) > > -jn-
