Pull requests to add functionality are a great way to push changes forward. The exact syntax and functionality would need a fair amount of bikeshedding for something so fundamental – and personally, I'm not convinced that we need new syntax for this. It's unlikely to happen without someone who wants it taking the initiative to implement it.
On Sat, Jun 14, 2014 at 2:25 AM, Andrew Simper <[email protected]> wrote: > Can ask what the point of the "$(variable)" syntax is? My understanding is > that is is a hack to allow you to easily and quickly insert the results of > expressions into strings, ie formatting a value as a string. As it stands > it is only a marginally useful hack, since most of the time when I format a > value as a string I want to be able to specify for format. Modifying the > hack to allow a second argument to be a formatting string would be insanely > useful, you would watch people ditch using sprintf by the droves (apart > from porting old c code to julia). > > On Saturday, June 14, 2014 2:06:31 PM UTC+8, Andrew Simper wrote: >> >> That sounds great with regards using the printf internals in a more >> general context. >> >> Now I just tried this: >> >> julia> v = 0.1234 >> 0.1234 >> >> julia> "$(v, v)" >> ERROR: syntax: invalid interpolation syntax >> >> So for the first "argument" of the tuple it makes sense it has to be a >> valid expression, but for the second argument it would be cool to support >> formatted output of whatever the first argument evaluates to. eg: >> >> julia> "$(v, %0.2f)" >> "0.12" >> >> julia> "$(v+v, %0.2f)" >> "0.25" >> >> This would be a huge win for making complicated formatting very powerful, >> succinct, and easy to use without mistakes. >> >> >> On Saturday, June 14, 2014 1:46:26 AM UTC+8, Stefan Karpinski wrote: >>> >>> The trouble is that what's inside the parentheses is just an expression >>> and printf format specifiers are not generally valid expressions. I've been >>> meaning for a while to take a crack at making some of the printf formatting >>> machinery a little more generally usable. It's easier now that Jameson, >>> Keno and Jeff have made it efficient enough to use local variables for the >>> printf machinery instead of having to use const globals. >>> >>> >>> On Thu, Jun 12, 2014 at 11:05 PM, Andrew Simper <[email protected]> >>> wrote: >>> >>>> Perhaps even the other way around may be better to keep things as >>>> similar as possible to the regular println syntax: >>>> >>>> $(arg, fmt) >>>> >>>> v0 = 1.234 >>>> v1 = 200 >>>> @print ("some formatted numbers: $(v0, 0.2f), $(v1, 06d)") >>>> >>>> >>>> On Friday, June 13, 2014 10:56:35 AM UTC+8, Andrew Simper wrote: >>>>> >>>>> I love the old style c formatting specifiers, they are quick and easy >>>>> to use. I noticed that there is an @printf macro that will still have the >>>>> same sort of issues as the old c version in that you have to match the >>>>> order of vargs to that of the formating string which can lead to errors. I >>>>> noticed that the println function uses $(var) syntax like php which I >>>>> think >>>>> is much better since the variable is inplace in the string. >>>>> >>>>> What do people think about keeping the same php type syntax but adding >>>>> an optional formatting element and making the $(arg) into a tuple $(fmt, >>>>> arg) so you can't screw up the matching of the format with the argument? >>>>> >>>>> so using this type of style: >>>>> v0 = 1.234 >>>>> v1 = 200 >>>>> @print ("some formatted numbers: $(0.2f, v0), $(06d, v1)") >>>>> >>>>> >>>>> instead of the current: >>>>> @printf("some formatted numbers: %0.2f, %06d", v0, v1) >>>>> >>>>> >>>>> both output: >>>>> >>>>> *some formatted numbers: float 1.23, int 000200* >>>>> >>>>> >>>>> >>>>> >>>
