A possible solution for s?pintf
Juerd
f/%03d %15s/$foo, $bar/;
This gives s?printf to any expression with short and concise syntax,
making printf redundant, which means I won't even have to start a
discussion about sayf :)
printf "%03d %15s", $foo, $bar;
vs
print f/%03d %15s/$foo, $bar/;
Of course, this is s///-like in quoting behaviour, so f[][] or f"""
should work just as well. The RHS is not a string, but parsed as an
expression in list context. If this feels weird, just think of s///e,
where the RHS is also not a string.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Rod Adams
>Without introduction, I'll just present the syntax idea:
>
> f/%03d %15s/$foo, $bar/;
>
>This gives s?printf to any expression with short and concise syntax,
>making printf redundant, which means I won't even have to start a
>discussion about sayf :)
>
> printf "%03d %15s", $foo, $bar;
>
>vs
>
> print f/%03d %15s/$foo, $bar/;
>
>Of course, this is s///-like in quoting behaviour, so f[][] or f"""
>should work just as well. The RHS is not a string, but parsed as an
>expression in list context. If this feels weird, just think of s///e,
>where the RHS is also not a string.
>
>
Why not just rename C< sprintf > to C< format > and ditch printf and sayf?
I will also remind you of the Scalar C< .as() > method, which sprintf's
it's value.
print "$foo.as('%03d') $bar.as('%15s')";
But I'd still like to keep something works on a whole list at once for
those cases where I'm doing several non-trivial expressions at once.
-- Rod Adams
Larry Wall
: Without introduction, I'll just present the syntax idea:
:
: f/%03d %15s/$foo, $bar/;
:
: This gives s?printf to any expression with short and concise syntax,
: making printf redundant, which means I won't even have to start a
: discussion about sayf :)
:
: printf "%03d %15s", $foo, $bar;
:
: vs
:
: print f/%03d %15s/$foo, $bar/;
Well, we do already have:
print $foo.as('%03d'), $bar.as('%15s')
which works on interpolated values as well. It als puts the variable
name out front, since the name is more important than the pattern in
most cases.
: Of course, this is s///-like in quoting behaviour, so f[][] or f"""
: should work just as well. The RHS is not a string, but parsed as an
: expression in list context.
I don't see that this buys us anything over just shortening "sprintf"
to something shorter, like:
print as '%03d %15s', $foo, $bar;
And your argument list falls out naturally from making "as" a listop.
Plus it naturally lets you say other "as-ly" things:
print as MyBigInt, $foo, $bar;
: If this feels weird, just think of s///e,
: where the RHS is also not a string.
Um, actually we did away with /e in Perl 6...
Larry
Brent 'Dax' Royal-Gordon
> Without introduction, I'll just present the syntax idea:
>
> f/%03d %15s/$foo, $bar/;
>
> should work just as well. The RHS is not a string, but parsed as an
> expression in list context. If this feels weird, just think of s///e,
> where the RHS is also not a string.
I think s///e is going away, since you can just use s/pattern/{code}/
now anyway.
Besides, I think "as" will do just fine, especially since you can now
interpolate method calls as well. You can even do something like this
if you want to perform bulk formatting:
say join ' ', ($n1, $n2, $n3) >>.as('%d');
Or, if that's not quite sufficient:
say map { .key.as(.value) }
$num => '%d',
$str => '%s',
...;
--
Brent 'Dax' Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
"I used to have a life, but I liked mail-reading so much better."
Juerd
> Besides, I think "as" will do just fine, especially since you can now
> interpolate method calls as well. You can even do something like this
> if you want to perform bulk formatting:
> say join ' ', ($n1, $n2, $n3) >>.as('%d');
> Or, if that's not quite sufficient:
> say map { .key.as(.value) }
> $num => '%d',
> $str => '%s',
> ...;
I'm really getting the feeling I'm the only one who uses sprintf because
it *separates* and lets you write complex things on one simple line.
That, and I use it a lot in one liners.
Writing complex things as complex things feels weird.
I know there are alternatives, and they're good. I can certainly see how
.as can come in handy. But sprintf (or call it "format", which I do like
better than the unpronounceable "sprintf") as a semi-list operator is
very useful too. I just don't like the amount of typing (with the nested
delimiters: parens and quotes) it requires.
Juerd
> Why not just rename C< sprintf > to C< format > and ditch printf and sayf?
Because format is almost as much typing as sprintf, and in many
circumstances needs both parens and quotes:
format("%03d %15s", $foo, $bar), $baz, ...
compared to
f/%03d %15s/$foo, $bar/, $baz, ...
> I will also remind you of the Scalar C< .as() > method, which sprintf's
> it's value.
> print "$foo.as('%03d') $bar.as('%15s')";
I like sprintf because with it, I can separate data from presentation.
When I interpolate, I want the things I'm interpolating to be as simple
and short as possible. "Hello, $name" looks natural. "Hello,
$person.name" looks a little less natural. Any .as(ugliness) makes it
impossible to read and leaves you with code-in-text, which as many
templating languages have already shown can very quickly get very ugly.
Rod Adams
>Rod Adams skribis 2005-03-12 17:41 (-0600):
>
>
>>Why not just rename C< sprintf > to C< format > and ditch printf and sayf?
>>
>>
>
>Because format is almost as much typing as sprintf, and in many
>circumstances needs both parens and quotes:
>
> format("%03d %15s", $foo, $bar), $baz, ...
>
>compared to
>
> f/%03d %15s/$foo, $bar/, $baz, ...
>
>
Well, I use s?printf extensively in my code, and IMO, it's about the
right level of huffmanization. C< .as() > seems to nicely take care of
the cases where C< sprintf > is too heavy.
Also, on second thought, don't ditch C< printf >. I use it too much. But
I don't see a need for C< sayf >. If you're going through the effort of
supplying a pattern, you can type the "\n".
What's always bothered me about s?printf was that it was doing something
roughly similar to RE's: describing a string pattern, but used a
completely different syntax. Admittedly, it's working in the other
direction, generation, not parsing, but they still seem terribly far
apart at that. But I haven't thought enough about it to offer a
proposal on the subject.
-- Rod Adams
Rod Adams
>I don't see that this buys us anything over just shortening "sprintf"
>to something shorter, like:
>
> print as '%03d %15s', $foo, $bar;
>
>And your argument list falls out naturally from making "as" a listop.
>Plus it naturally lets you say other "as-ly" things:
>
> print as MyBigInt, $foo, $bar;
>
>
ooh. Nice. I like that.
-- Rod Adams
Juerd
> Well, we do already have:
> print $foo.as('%03d'), $bar.as('%15s')
> which works on interpolated values as well. It als puts the variable
> name out front, since the name is more important than the pattern in
> most cases.
It puts the variable name out front, which is great, but it also puts
the second variable name allll the way to the right, after the line
noise.
> I don't see that this buys us anything over just shortening "sprintf"
> to something shorter, like:
> print as '%03d %15s', $foo, $bar;
I like it, although in more complex lists, it still requires the parens
that I so like to avoid. I could certainly live with a list op as short
as 'as', though!
Larry Wall
: I'm really getting the feeling I'm the only one who uses sprintf because
: it *separates* and lets you write complex things on one simple line.
: That, and I use it a lot in one liners.
Then you should feel much better after you read my message where I use
"as" as a list operator.
: I know there are alternatives, and they're good. I can certainly see how
: .as can come in handy. But sprintf (or call it "format", which I do like
: better than the unpronounceable "sprintf") as a semi-list operator is
: very useful too. I just don't like the amount of typing (with the nested
: delimiters: parens and quotes) it requires.
A list operator doesn't require parens unless you start chunking up
your outputs into sublists, but if you do that then you're falling
into the same trap of scattering complexity around that you complained
about for .as().
Larry
Dave Whipp
> I don't see that this buys us anything over just shortening "sprintf"
> to something shorter, like:
>
> print as '%03d %15s', $foo, $bar;
>
> And your argument list falls out naturally from making "as" a listop.
> Plus it naturally lets you say other "as-ly" things:
>
> print as MyBigInt, $foo, $bar;
This seems to have some overlap with the "form" listop in E7. Do we need
both, or will we make c<Form> a possible 1st arg to C<<as>. Eg,
(modified from the first E7 example):
sub myster_rite {
our ($name, $age, $ID, $comments);
print as Form :interleave <<'.'
===================================
| NAME | AGE | ID NUMBER |
|----------+------------+-----------|
| {<<<<<<} | {||||||||} | {>>>>>>>} |
|===================================|
| COMMENTS |
|-----------------------------------|
| {[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[} |
===================================
.
$name, $age, $ID,
$comments;
}
Larry Wall
Rod Adams
>Brent 'Dax' Royal-Gordon <bren...@gmail.com> wrote:
>
>
>>Besides, I think "as" will do just fine, especially since you can now
>>interpolate method calls as well. You can even do something like this
>>if you want to perform bulk formatting:
>>
>> say join ' ', ($n1, $n2, $n3) >>.as('%d');
>>
>>
>
>What about:
>
> say [ $n1, $n2, $n3 >>.as('%d') ].join;
>
>?
>
>Can I (1) use join on a bracketed list
>
Certainly. Almost anywhere you can use an array, an array ref will do
instead.
>and (2) leave off the
>parentheses around C<$n1, $n2, $n3>? (I couldn't find where hyper ops
>are on the precedence table.)
>
>
I think you'd need the parens there, to distinguish that the . operator
applies to the list, not to $n3. Hyper's are not on the list because
they are adverbs to the existing operators. In this case, you're using
unary ., so you follow it's precedence.
You could easily write the above as
say (($n1, $n2, $n3)».as('%d')).join;
What I'm not certain about is if
say ($n1, $n2, $n3)».as('%d').join;
does the same thing, but I think it does.
>And this:
>
> say [ $num => '%d', $str => '%s' ] >>.key.as(.value);
>
>
>
No. .key returns a string, which you call the .as method of, which is
fine, but the .value is a separate expression, and references the
current topic, which is not tied to the array.
Related to what I'm not sure about above is that I think you'd have to
say C< [...]».key».as($pattern) > to get it working correctly.
>(4) use square brackets in
>this instance (to make sure my list doesn't form a parameter list to
>C<say>)?
>
Yes, but whitespace between the "say" and "(" should do the trick as
well. Might generate a warning, however.
-- Rod Adams
Matt Diephouse
> interpolate method calls as well. You can even do something like this
> if you want to perform bulk formatting:
>
> say join ' ', ($n1, $n2, $n3) >>.as('%d');
What about:
say [ $n1, $n2, $n3 >>.as('%d') ].join;
?
Can I (1) use join on a bracketed list and (2) leave off the
parentheses around C<$n1, $n2, $n3>? (I couldn't find where hyper ops
are on the precedence table.)
> Or, if that's not quite sufficient:
>
> say map { .key.as(.value) }
> $num => '%d',
> $str => '%s',
> ...;
And this:
say [ $num => '%d', $str => '%s' ] >>.key.as(.value);
?
Can I (3) hyper-op chained method calls and (4) use square brackets in
this instance (to make sure my list doesn't form a parameter list to
C<say>)?
--
matt diephouse
http://matt.diephouse.com
Larry Wall
: Larry Wall wrote:
: >I don't see that this buys us anything over just shortening "sprintf"
: >to something shorter, like:
: >
: > print as '%03d %15s', $foo, $bar;
: >
: >And your argument list falls out naturally from making "as" a listop.
: >Plus it naturally lets you say other "as-ly" things:
: >
: > print as MyBigInt, $foo, $bar;
:
: This seems to have some overlap with the "form" listop in E7. Do we need
: both, or will we make c<Form> a possible 1st arg to C<<as>.
That would be up to Damian. :-)
: print as Form :interleave <<'.'
I don't think that can be valid syntax--too many nouns in a row, and if
you take :interleave as an adverb, it'd have to apply to "as" rather than
than "Form".
Here docs are now q:here<.> or q:till<.> or some such, by the way. So maybe
we just let Damian define q:f:to/./ or some such, except that we already
make :f mean something, I expect.
Larry
Larry Wall
: You could easily write the above as
:
: say (($n1, $n2, $n3)».as('%d')).join;
:
: What I'm not certain about is if
:
: say ($n1, $n2, $n3)».as('%d').join;
:
: does the same thing, but I think it does.
Yes, hyper only modifies one operator, not all the rest of them, the
operator in this case being ".as('%d')". On the other hand, it may
be that .as automatically iterates formats when it needs to, so maybe
the hyper mod is unnecessary. On the gripping hand, it's then not clear
whether
@foo.as(Bar)
is intending to convert each element to a Bar or the array as a whole.
: >And this:
: >
: > say [ $num => '%d', $str => '%s' ] >>.key.as(.value);
: >
: >
: >
: No. .key returns a string, which you call the .as method of, which is
: fine, but the .value is a separate expression, and references the
: current topic, which is not tied to the array.
Probably need something with an explicit closure (or loop) to make
that work right, but I could be wrong. As it stands now it doesn't
seem like it would become common idiom.
: Related to what I'm not sure about above is that I think you'd have to
: say C< [...]».key».as($pattern) > to get it working correctly.
If .as() autohypers then the second hyper is not necessary.
We could go as far as to define .keys on a list of pairs. If we did that,
then a non-pair might be assumed to match either undef or 1. The only
problem I see with doing that is that, in a sense, the keys of an array
are the integers. But that'd presumably be easy to get with 0..^@foo.
That only works for a named array, though.
: >(4) use square brackets in
: >this instance (to make sure my list doesn't form a parameter list to
: >C<say>)?
: >
: Yes, but whitespace between the "say" and "(" should do the trick as
: well. Might generate a warning, however.
I hope not. We'll have to see how quickly people learn to internalize
the new whitespace dependencies. It's going to be harder for some
people than others. For some people it may be impossible. :-)
Larry