On Monday, June 16, 2003, at 10:39 AM, Edwin Steiner wrote:
I'm content if this will be revisited (hopefully by someone with better overview than mine). It just should not be ignored.
Oh, it definitely won't be ignored. :-) It's come up several times before -- try searching for "stringification", IIRC -- and has always sortof fizzled because the higher-ups were never quite ready for it yet. And there's some primitive type and type conversion questions that are still unclear -- until those are fleshed out, the stringification proposals have been a bit "stuck".
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.
If you really want to make your brain hurt, consider this: stringification can be thought of, obliquely, as the "inverse" of regexes. One puts strings together, the other takes them apart. And Perl6 introduces shiny, clean-looking rule syntax:
/here is a <thingy>/
Oooh, pretty.
So if I were in an evil mood, which I almost always am, I'd ask: what's the inverse of a <thingy> rule? Is it possible that interpolated strings could benefit from the same angle-bracket syntax? __Is it possible that there are "output rules" just like there are "input rules"?__
So what would
"The value of x is <thingy>"
mean, from the interpolation end of things? _Could_ it mean something? Is it possible that
"The value of x is <expr but formatted(...)>"
is in fact a cleaner, more elegant syntax than:
"The value of x is $(expr but formatted(...))"
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>"
having previously defined your MoneyFormat "formatting rule" in some other location?
MikeL