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