Sorry to drag out an old conversation, but I was indisposed at the
time, and only just got back to it.
On Mon, Jun 16, 2003 at 01:07:21PM +0200, Edwin Steiner wrote:
: Edwin Steiner <[EMAIL PROTECTED]> writes:
:
: > Disallowing interpolated formats on \F has the additional advantage of
: > making the {} unnecessary in the most common cases (also removing the
: > 'force to string').
:
: As an afterthought: This suggests getting rid of the {} entirely.
:
: The rule could be like:
:
: \\F <printf_format_without_percent> <funny_character_expression>
:
: so
:
: "The value in hex is \Fx$value."
: "The value in hex is \Fx%lookup{$key}."
: "The value in hex is \Fx$(calculate($x,5))."
:
: would both be ok. For more complex formatting you use C<sprintf> or
: C<but formatted>.
: I really like that. (It's perlish, too, don't you think?)
Apart with the leaning toothpick, there are several other problems
with the \F approach:
* It's hard to parse visually.
* It's not general enough.
* It doesn't put the important thing out front.
* It's inventing new syntax when we don't actually need it.
The thing everyone is missing here is that methods can now be
interpolated (and that everything in Perl 6 can be treated as an
object if you want it to be). Suppose we have a method .form that
can format any object. Without changing anything, we already have:
"The value in hex is $value.form('x')."
"The value in hex is %lookup{$key}.form('x')."
"The value in hex is $(calculate($x,5).form('x'))."
That doesn't invent new syntax, and it puts the variable out front
where it belongs. It's more general in that it works outside of
interpolations as well as inside. It's also easier to parse visually.
If that is not deemed easy enough to parse visually, then we can talk
about syntactic relief. If we wanted to stick with standard printf
formats, we could go with a pythonesque operator. We can even go
with % if we add dot to keep it unambiguous:
"The value in hex is $value.%02x."
"The value in oct is $value.%03o."
"The value as string is $value.%-20.20s."
Those dots might look ambiguous there, but they're not, at least in
principle. It's basically using formats as a funny quoting construct
starting with .% and ending with a letter. Nevertheless, if it *looks*
ambiguous, that's also a problem.
On the other hand, if we went with a more rules-based formatting system,
this syntax suggests itself:
"The value in hex is $value.<02x>."
"The value in oct is $value.<03o>."
"The value as string is $value.<-20.20s>."
The nice thing about this approach is that the format is visually
encapsulated inside angles, so it's easy to ignore when you want to,
and easy to find the other end of. It's also more amenable to
interpolation:
"The value as string is $value.<-$x.$y s>."
This also gives us the more general
"The value is $value.<money>."
which can presumably take arguments:
"The value is $value.<money(11, 2, comma => 1)>."
But then maybe you might as well write
"The value is $value.as_money(11, 2, comma => 1)."
or some such.
Still, one could consider inverting the standard formatting sequence
"The value in hex is $value.<x 02>."
"The value in oct is $value.<o 03>."
"The value as string is $value.<s -$x.$y>."
where the defaults are just
"The value in hex is $value.<x>."
"The value in oct is $value.<o>."
"The value as string is $value.<s>."
We could even go as far as to reserve single character rule names
for rules that can work both directions. (Not all can.) But that's
probably a bad idea. On the other hand, if there are predefined rules
like <o>, <d>, and <x>, they'd map naturally to people's formatting
skills.
On the gripping hand, I've always loathed scanf() and its ilk...
But none of that needs to be added for 6.0.0, since methods work
just fine. All we need to figure out for sure is the name of the
standard formatting method. (And its arguments...)
Larry
