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



Reply via email to