small feature request concerning string interpolation

[Steven Sagaert]

Hi,

One thing I find annoying is that when you want to format number strings/output you cannot use string interpolation anymore but have to switch to a completely different mechanism (@printf/@sprintf + string concatenation). It would be nice that one could stay with string interpolation and still format number (number of decimals). So I propose something like this:

"blabla $(n:0.1f) lalala"

basically add a format string preceded by a colon to an interpolation expression.

What do you think?

[Tom Breloff]

I like this concept (I've had the same thought before) but I suspect the implementation would be pretty tricky, since you can parenthesize arbitrary code within the string (a feature I find really cool btw).  Look what happens with your string:

julia> n, f =  1, 100

(1,100)

julia> "blabla $(n:0.1f) lalala"

"blabla 1.0:1.0:10.0 lalala"

[Scott Jones]

I don't think Julia needs more special syntax... I think maybe this could be solved by simply having a simple `fmt` function,

that takes a single format specification, and a single value, and returns a string...  That could be added in a package right now.

i.e:

"blablabla $(fmt("0.1f",n)) lalala"

[Steven Sagaert]

That would be acceptable :)

[Scott Jones]

I'll create a PR on GitHub, as soon as I get a few moments of spare time, for it then.

I'm still enough of a Newbie with Julia that I need to learn how to create a package of my own though!

[Kevin Squire]

Not to discourage you from creating a package, Scott, but it would be nice if something like this were part of Formatting.jl.  Generally, it's often encouraged not to split very related functionality across different packages (which is why, e.g., Formatting.jl has both Python and C style formatting).

Cheers,

   Kevin 

[Scott Jones]

Ha, after all that's been thrown at me, have you yet seen me get really discouraged? :-)

I wasn't aware of Formatting.jl, I've just been seeing the complaints about how sprintf is a macro, not a function, and can't be used everywhere people want to...

(and I've had the same problem myself)

Thanks very much for pointing out where this really should belong!  (I'll have to learn about Package creation some other time!)

Cheers!

[Scott Jones]

I was just thinking, maybe the arguments should be `fmt(formatstring, value, modifiers...)`, instead of the sprintf way where any modifiers (for * in the format), come before the value...

That would allow dispatching to different `fmt` methods based on the value... (so nice to be using Julia instead of C!)

What do you all think? (esp. Kevin, who I know is one of the Julia experts!)...

On second thought, would it be even better to be `fmt(value, formatstring, modifiers...)`, which would allow a "default" format based on the type of value...

Again, thoughts please!

[Josh Langsfeld]

Doesn't Formatting.jl already have a 'fmt' function?

Is there discussion about moving some of the Formatting functionality into Base? I would say formatted printing is among the most core tasks done in programming and I think it's a bad sign if people are frequently directed to an external package.

[Tom Breloff]

I have these functions which I use for this purpose (which call Formatting.format)

stringfloat(v::Float64, prec::Int = 3) = Formatting.format(v, precision = prec)

stringfloats(v::VecF, prec::Int = 3) = string("[", join(map(x->stringfloat(x,prec), v), ", "), "]")

Obviously stringfloat is a bad name, but maybe all we need are some nice shortened method names added to Formatting?  Personally I don't mind the separate package (as long as it's maintained well and is simple to include).  These methods aren't especially performant though, so that could be an issue.

[Scott Jones]

Don't get me started on what should, and should not, belong in Base! ;-)

I agree, but it seems that many of the core team believe that only things for numeric/technical computing belong in Base.

I've been having a debate over the last few weeks, centered now on the inclusion of a single conversion method,

from an array of UInt16 (UTF-16 encoded string) to a UTF8String, 5 lines of code & 1206 bytes added, that is absolutely

necessary for loading UTF-16 strings from databases, Java, ICU, ... (without additional copying just to tack on a `\0` word

at the end of the string, just to throw the temporary string away immediately).

It's very frustrating, to say the least.

On Tuesday, June 16, 2015 at 10:46:11 AM UTC-4, Josh Langsfeld wrote:

[Scott Jones]

I did dig up https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Flindahua%2FFormatting.jl%23formatted-string&sa=D&sntz=1&usg=AFQjCNHBock_E8VXytq85iDfcM7yAQfwSg, and saw the `fmt` function there.

I don't think that is as good as what I suggested, where you can have a default format based on the type,

and a constant string that accepts run-time parameters like C/C++ printf (when you have a * in the format string).

The `fmt` in Formatting.jl seems to require that you have to build up a string, then convert it into a FormatSpec,

before you can use it... that doesn't seem very convenient when you want to do something like:

`fmt(mystring, "*s", min(40,length(mystring)))`  (in my version of fmt).

On Tuesday, June 16, 2015 at 10:46:11 AM UTC-4, Josh Langsfeld wrote: