--- David Storrs <[EMAIL PROTECTED]> wrote: > On Mon, Jun 16, 2003 at 11:37:06AM -0700, Michael Lazzaro wrote: > > [...] > > But there is broad support for the idea that the somewhat elderly > > printf syntax is a PITA, and that printf, in general, should be > > completely unnecessary since we already *have* interpolated > strings, > > fer pete's sake. > > A PITA, yes, but a darned powerful *and concise* PITA. > > > > Is it possible that > > > > "The value of x is <expr but formatted(...)>" > > > > is in fact a cleaner, more elegant syntax than: > > Quite honestly, I'd like to do better. One of the things that makes > regexen so powerful is their concision; they pack a tremendous amount > of meaning into every character and yet, for the most part, they > aren't that hard to understand. I'd like to see the same for output > rules. The vast majority of output rules will probably be on the > order of: "make this an integer and left-pad with 0s to make sure > there are at least 2 digits". I'd much rather write: > > "The value of x is \F02d$($x)" > > than > > "The value of x is $($x as integer but > formatted(<two-digits-left-pad-0>)" > > > > Or, if we have "output rules" just like we have "input rules", > could > > something quite complex be expressed simply as: > > > > "You have <$x as MoneyFormat>" > > I like this better; a good compromise between concision and > readability (although the later poster's suggestion of > 'MoneyFormat($x)' was even better, IMO). > > You still need to define MoneyFormat somewhere, however; I hope that > you will be able to do that with nice concise formatting codes.
Not sure I care about that -- the good ones will wind up in core+, or barely outside, just like useful helper functions. I do like one other aspect of printf codes, however -- they are independent of data, or at least they're REALLY late bound. Remember the signature for printf: int printf(format_string, ...) Being able to code a Grammar used for proactive generation of output makes P6 a real programm(ar)ing language, possibly the first such. :-) But saying rule MoneyFormat { <currency_sigil>? <digit> {1,3} (<thousands_delimiter><digit> {3})* (<decimal_delimiter> <digit> {2})? } isn't the same as saying emit MoneyFormat { my $amt = shift; my $out; $amt = int($amt * 100); $out = $decimal_delimiter _ ($amt % 100); $amt /= 100; while $amt > 999 { $out = $thousands_delimiter _ ($amt % 1000) _ $out; $amt /= 1000; } $out = $currency_sigil _ $amt _ $out; return $out; } And as much as I hate to claim that any of the Apocalypsen are incomplete, I wonder if maybe we need some more thought paid to the "FORMAT" chapter -- replacing, or merging, formats with emit-rules seems like an interesting project. (Although one that won't require *much* in core- other than a standardized "anonymous stream" mechanism that we've already talked over [inconclusively] once). =Austin