Re: rethinking printf
On Mon, 18 Mar 2002, Jim Cromie wrote:
Rich Morin wrote:
At 11:24 PM -0500 3/6/02, Uri Guttman wrote:
qn would be just like qq but not allow any
direct hash interpolations (%foo or %foo{bar}). you can always get those
with $() if needed. this solves the common case with a minimal of noise
and the uncommon case has a simple out of using $(). no need for wacko
ways to put in \n. it is double quotish in all ways but one and mainly
to be used for printf format strings.
I also like this because it allows a typical format string to be
converted
merely by adding a two-character prefix:
printf(The value is %7.2f\n, $foo);
---
printf(qnThe value is %7.2f\n, $foo);
-r
if qf() is defensible, it should pass some generality tests;
1. make it 'replace' printf
print qf'%s %d', $somestring, $someint;
2. make it 'replace' sprintf.
$res = qf('%s %d %d', $somestr, $anint)
3. detect the silent error above - insufficient args.
this quote-like operator is now a list-op, and a smart one.
4. make it know whether %s means hash interpolation or printf-format-spec
a. ive seen perl5 warn about escaping when printing undefined / undeclared
array (cant seem to replicate now :-/ )
b. the universe of printf format specs is pretty small, it really only
interferes
with (the expansion of: {[ each %s ]} ) a few single letter hashes %s,
%d, etc..
c. item b implies a run-time check to see that no %s, %d, are hidden by
a format-spec
interpretation, but that is excessive; a comment in `perldoc -f printf`
would address
that rather fully.
I'm thinking, an operator really isn't needed is it? Hows about we extend
printf to support double quote-like escape sequences. So:
(s)printf 'Hello $foo,\n how %s you?', 'am';
Would print:
Hello $foo,
how am you?
In other words, we change printf, not the quotes.
Re: rethinking printf
On 10 Mar 02 at 11:14:26PM, Uri Guttman wrote: i really think that the printf format spec is so standard and ingrained that changing it with # for % or requiring \% is not a good idea. but then again, backwards compatibility is not a rule you must always obey. i just think in this case it should be. Especially as this is a case in which the functionality itself is not broken, and not itself under review, but rather that a seemingly unrelated proposed change to another part of the language is in effect breaking printf. If the printf formats were to be changed simply to accommodate other changes elsewhere, then they should really be looked at more generally: what would people like to get out of them, before we break them? But even then, backwards compatibility would be nice... Ian Boreham
Re: rethinking printf
On 10 Mar 02 at 11:14:26PM, Uri Guttman wrote: i really think that the printf format spec is so standard and ingrained that changing it with # for % or requiring \% is not a good idea. but then again, backwards compatibility is not a rule you must always obey. i just think in this case it should be. Especially as this is a case in which the functionality itself is not broken, and not itself under review, but rather that a seemingly unrelated proposed change to another part of the language is in effect breaking printf. If the printf formats were to be changed simply to accommodate other changes elsewhere, then they should really be looked at more generally: what would people like to get out of them, before we break them? But even then, backwards compatibility would be nice... Ian Boreham
Re: rethinking printf
a == abigail [EMAIL PROTECTED] writes:
a On Wed, Mar 06, 2002 at 11:15:30PM -0500, Uri Guttman wrote:
good point. $() can still wrap that but then there has to be a balance
between printf strings and double quoters. how about this wacky idea:
make a new type of string where %foo{bar} is not interpolated by
default. maybe something in the q/qq family could be added like qn for
no hash interpolation. you can use $() to still force it if you need to
in printf formats.
a I'd think it would be much better that '%' followed by a word *not*
a followed by a { isn't interpolated. Granted, you cannot do
a interpolation of hashes (well, one could always write @{[%hash]},
a just like in perl5, and there's little change of clashing with
a printf formats. There's only a clash if a format specifier is
a followed by a brace.
i already covered how @() and $() will allow interpolation of full
hashes so the hack @{[]} is not needed there or in fact anywhere.
a But the way perl6 is going, I doubt we'll see this kind of DWIM; perl6
a is going more in the way of a bondage and discipline language.
i disagree. but we shall see if larry is listening to this thread and
will back away from hash interpolation or take some of our suggestions
that make it work without killing format strings. i hate to see a
special call or wierd syntax for that. my qn (or qf) suggestion seems to
have some backing and it is clean and unobtrusive.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
-- Stem is an Open Source Network Development Toolkit and Application Suite -
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
RE: rethinking printf
Uri Guttman:
# i disagree. but we shall see if larry is listening to this thread and
# will back away from hash interpolation or take some of our suggestions
# that make it work without killing format strings. i hate to see a
# special call or wierd syntax for that. my qn (or qf)
# suggestion seems to
# have some backing and it is clean and unobtrusive.
I think qn counts as weird syntax. I ask again, what's wrong with one
of:
sprintf(%hash\%s, $string);
sprintf(%hash.'%s', $string);
sprintf('%s%s', _%hash, $string);
?
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
RE: rethinking printf
Abigail:
# I'd think it would be much better that '%' followed by a word *not*
# followed by a { isn't interpolated. Granted, you cannot do
# interpolation
# of hashes (well, one could always write @{[%hash]}, just
# like in perl5,
# and there's little change of clashing with printf formats.
# There's only
# a clash if a format specifier is followed by a brace.
There's only a clash if you double-quote the format string anyway, which
is a rare thing to need to do at all.
# But the way perl6 is going, I doubt we'll see this kind of DWIM; perl6
# is going more in the way of a bondage and discipline language.
It's more like Perl 6 is removing many inconsistencies. This
particular case isn't incredibly different from the changes in the
precedence of open() between Perls 4 and 5. (For those who don't
remember this or haven't read about it somewhere, open() was once a
hybrid unary and list operator, so open FOO, 'bar' || die; worked.) A
minor adjustment in either the language or the user's usage was all that
was necessary to avoid problems with the change
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
Re: rethinking printf
BD == Brent Dax [EMAIL PROTECTED] writes:
BD I think qn counts as weird syntax. I ask again, what's wrong with one
BD of:
BD sprintf(%hash\%s, $string);
BD sprintf(%hash.'%s', $string);
BD sprintf('%s%s', _%hash, $string);
what if you want to use %hash{width} as a field precision? i don't like
the idea that all format specifiers would be the noisy \%s. they are
much more common than using hashes in format strings. now as i said in
another post, you can use the * method but i never liked it. in c it was
the only decent solution to dynamic precisions (other than doing a
sprint of the format string itself which loses). in perl, interpolation
makes that easier but i have rarely seen hashes used in that way. a temp
variable is as good a solution for that too.
$prec = %hash{width} ;
sprintf( qf%${prec}s, $string);
sprintf( \%${prec}s, $string);
is one of your alternatives. :-/
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
-- Stem is an Open Source Network Development Toolkit and Application Suite -
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
RE: rethinking printf
Uri Guttman:
# BD == Brent Dax [EMAIL PROTECTED] writes:
#
# BD I think qn counts as weird syntax. I ask again, what's
# wrong with one
# BD of:
#
# BD sprintf(%hash\%s, $string);
#
# BD sprintf(%hash.'%s', $string);
# BD sprintf('%s%s', _%hash, $string);
#
# what if you want to use %hash{width} as a field precision? i
# don't like
# the idea that all format specifiers would be the noisy \%s. they are
# much more common than using hashes in format strings. now as i said in
# another post, you can use the * method but i never liked it.
# in c it was
# the only decent solution to dynamic precisions (other than doing a
# sprint of the format string itself which loses). in perl,
# interpolation
# makes that easier but i have rarely seen hashes used in that
# way. a temp
# variable is as good a solution for that too.
#
# $prec = %hash{width} ;
# sprintf( qf%${prec}s, $string);
#
# sprintf( \%${prec}s, $string);
#
# is one of your alternatives. :-/
You forgot one.
sprintf('%'_%hash{width}_'s', $string);
Not horribly pretty, true, but not bad enough to justify writing a
quoting hack into the language. (And yes, I do consider 'qf' a quoting
hack.)
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
Re: rethinking printf
Why not replace the escape character '%' with '#'? No new quoting operators or functions to learn. And introduce a warning if there are no #'s in the format string. Eugene
Re: rethinking printf
PS == Peter Scott [EMAIL PROTECTED] writes: PS At 01:39 AM 3/11/02 +0100, Eugene van der Pijll wrote: Why not replace the escape character '%' with '#'? No new quoting operators or functions to learn. PS Beat me to it. And introduce a warning if there are no #'s in the format string. PS Maybe if it's a constant, but not if you're doing something like PS printf #.3f x @nums, @nums; Perl permits the following universally-known flags between the % and the conversion letter: # prefix non-zero octal with 0, non-zero hex with 0x how will that be handled? the classic way to print a % in printf was to double it up but this allows # after # already. i really think that the printf format spec is so standard and ingrained that changing it with # for % or requiring \% is not a good idea. but then again, backwards compatibility is not a rule you must always obey. i just think in this case it should be. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com -- Stem is an Open Source Network Development Toolkit and Application Suite - - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org
Re: rethinking printf
At 11:24 PM -0500 3/6/02, Uri Guttman wrote:
qn would be just like qq but not allow any
direct hash interpolations (%foo or %foo{bar}). you can always get those
with $() if needed. this solves the common case with a minimal of noise
and the uncommon case has a simple out of using $(). no need for wacko
ways to put in \n. it is double quotish in all ways but one and mainly
to be used for printf format strings.
I also like this because it allows a typical format string to be converted
merely by adding a two-character prefix:
printf(The value is %7.2f\n, $foo);
---
printf(qnThe value is %7.2f\n, $foo);
-r
--
email: [EMAIL PROTECTED]; phone: +1 650-873-7841
http://www.cfcl.com/rdm- my home page, resume, etc.
http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc.
http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series
http://www.ptf.com/tdc - Prime Time Freeware's Darwin Collection
Re: rethinking printf
On Wed, Mar 06, 2002 at 11:24:57PM -0500, Uri Guttman wrote:
that is another point. not allowing a complete hash to interpolate. but
what defines that? what if you wanted %s{bar} and that was a format and
not a hash and in a double quoted string? my proposal handles that well
with no major noise factors. qn would be just like qq but not allow any
direct hash interpolations (%foo or %foo{bar}). you can always get those
with $() if needed. this solves the common case with a minimal of noise
and the uncommon case has a simple out of using $(). no need for wacko
ways to put in \n. it is double quotish in all ways but one and mainly
to be used for printf format strings.
why not qf for format strings then?
s/(printf)/\1 qf/g
Re: rethinking printf
BC == Bernie Cosell [EMAIL PROTECTED] writes:
cced perl6-language
BC I wonder if the solution is to look at it the other way: that you
BC have to do something to get interpolation to happen. If we look
BC at it from the old adage of making the more common things simpler,
BC at least in my code I very rarely interpolate arrays [and I
BC suspect I'd even LESS often interpolate hashes], I wouldn't mind
BC the syntax going the other way -- maybe @ never interpolates and
BC you need to do \@ to make interpolation happen [and then
BC similarly with '%']... This is also simlar to the logic behind
BC Perl's reversing the longstanding unix convention WRT to chars
BC like '(' in REs.
that is a good idea. the @() and $() things will interplate any
expressions into strings. so use a method on the hash to get a string
out and wrap it in $().
printf %d hash is $(%foo.string), $bar ;
no ambiguity and no confusion. how often will you need to interpolate a
hash? so make it more cumbersome as it is a rare thing. that is larry's
credo from way back. breaking % in a s/printf format is not good as that
is the very common thing to do.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
-- Stem is an Open Source Network Development Toolkit and Application Suite -
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
RE: rethinking printf
printf %d hash is $(%foo.string), $bar ;
no ambiguity and no confusion.
This would be nice, if scalar things use '$'. But:
perl5: printf %d is $foo{bar}, $baz;
perl6: printf %d is $(%foo{bar}), $baz;
Not so nice.
Dave.
Re: rethinking printf
On Wed, 6 Mar 2002 17:57:07 -0500, Uri Guttman wrote:
how often will you need to interpolate a hash?
A whole hash: quite rarely. A hash item: a LOT. Don't forget that
$foo{BAR} will now become %foo{BAR}
--
Bart.
Re: rethinking printf
--- Bart Lateur [EMAIL PROTECTED] wrote:
On Wed, 6 Mar 2002 17:57:07 -0500, Uri Guttman wrote:
how often will you need to interpolate a hash?
A whole hash: quite rarely. A hash item: a LOT. Don't forget that
$foo{BAR} will now become %foo{BAR}
Of course, it could also become %s. Or _ %foo{BAR} _
I agree that the ability to interpolate simple scalars (no matter how
complex they are to describe) is a good thing. %foo{BAR} would be nice
in even a printf-ian context.
=Austin
__
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/
RE: rethinking printf
Uri Guttman:
# printf %d hash is $(%foo.string), $bar ;
#
# no ambiguity and no confusion. how often will you need to
# interpolate a
# hash?
As others have pointed out, %foo{BAR} has to work. But I have another
question for you: what's wrong with
sprintf '%d hash is %s', $bar, %foo;
? After all, interpolating into an sprintf is a bit dangerous anyway
(what if %foo=('%d' = '')?), and you avoid special cases.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
Re: rethinking printf
BL == Bart Lateur [EMAIL PROTECTED] writes:
BL On Wed, 6 Mar 2002 17:57:07 -0500, Uri Guttman wrote:
how often will you need to interpolate a hash?
BL A whole hash: quite rarely. A hash item: a LOT. Don't forget that
BL $foo{BAR} will now become %foo{BAR}
good point. $() can still wrap that but then there has to be a balance
between printf strings and double quoters. how about this wacky idea:
make a new type of string where %foo{bar} is not interpolated by
default. maybe something in the q/qq family could be added like qn for
no hash interpolation. you can use $() to still force it if you need to
in printf formats.
just trying out various ideas,
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
-- Stem is an Open Source Network Development Toolkit and Application Suite -
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
