Hi Andrew

I’m probably stating the obvious here but you can get some of the 
formatting options with $() as follows:

julia> x=3.45678771
3.45678771

julia> "x is $x"
"x is 3.45678771"

julia> "x is $(round(x))"
"x is 3.0"

julia> "x is $(int(x))"
"x is 3"

julia> "x is $(round(x,4))"
"x is 3.4568"

I actually find $() really useful and never need the additional 
functionality of @printf, etc…

Cheers
On Saturday, June 14, 2014 12:56:37 AM UTC-7, Andrew Simper wrote:

Hi Stefan,
>
> I'll get my hands dirty and give it a go, but only if you can't see a 
> gotcha that will kill the elegance of julia, I don't know know the whole 
> picture of julia like you and I don't want to screw something up in the 
> language. It seems conceptually clean enough to me that $() interpolation 
> is already parsing a string then extracting the first argument and 
> interpreting it as an expression, and the second argument as a formatting 
> string fine for the gains it gives you.
>
> What is the best way to put forward a proposal like this and get feedback 
> from the Julia community as to if they think it is a good idea?
>
> On Saturday, June 14, 2014 3:12:00 PM UTC+8, Stefan Karpinski wrote:
>>
>> 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*
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>  ​

Reply via email to