I think both of the problems you're hitting are the same core problem: @sprintf is a macro, so its behavior is surprising when you think in terms of the run-time behaviors that control function evaluation. In particular, your line continuation problem wouldn't be fixed by having line continuations. No matter what you're going to end up passing the wrong thing (a call to *) to a macro that expects a literal string.
I believe Dahua tried to work on writing a more function oriented package for doing formatting: https://github.com/lindahua/Formatting.jl There might be some other solutions floating around as well. -- John On Dec 2, 2014, at 5:52 PM, Ronald L. Rivest <[email protected]> wrote: > Another reason for (perhaps) wanting an expression as a format > string: > > Julia doesn't have a line continuation mechanism. > > How does one split a long format string into parts without having > a string expression? The following doesn't work: > > @sprintf("This is the first part of a rather long format string, which I" > * > "would like to extend onto %d (or maybe more) lines.", 5) > > Thanks. > > Cheers, > Ron > > > On Tuesday, December 2, 2014 8:40:56 PM UTC-5, Ronald L. Rivest wrote: > I'm new to Julia, and got burned (aka wasted a fair amount of time) > trying to sort out why @sprintf didn't work as I expected. > > julia> @sprintf("%2d",29) > "29" > > julia> fmt = "%2d" > "%2d" > > julia> @sprintf(fmt,29) > ERROR: @sprintf: first argument must be a format string > > julia> @sprintf("%"*"2d",29) > ERROR: @sprintf: first argument must be a format string > > I would expect that @sprintf would allow an arbitrary string expression as its > format string. It obviously doesn't... > > There are many good reasons why one might want a format string expression > instead > of just a constant format string. For example, the same format may be needed > in > several places in the code, or you may want to compute the format string > based on > certain item widths or other alignment needs. > > At a minimum, this should (please!) be noted in the documentation. > > Better would be to have the extended functionality... > > (Or maybe it exists already -- have I missed something?) > > Thanks! > > Cheers, > Ron Rivest
