This is very but it doesn't entirely solve the problem. The f"..." macro still entails code generation, which *can* be done at compile time, but to support runtime formats the code generation has to be deferred until run time – and the exact same thing could be done with the @printf macro. The main thing that the generated function approach gives you is a way of caching generated code associated with a particular format. But we could also do code caching with @printf by just maintaining a dict mapping format strings to generated code (this is essentially what generated functions do) and it would avoid polluting the generated function cache, so it's arguably better. The concern with this is that someone is going to write a format string that depends on variables and they'll end up generating a huge amount of formatting code. To see why this could be an exponential explosion of code, consider the format "%$(w1)d %$(w2)d %$(w3)d %$(w4)d\n", and suppose that each of w1 through w4 ranges from 1 to 32. That would generate over a million formatting functions. Ruh roh.
I don't think there's a clever way around this without fundamentally changing the design – you have make some of the values that are currently being specialized on a compile time into runtime parameters so that you can reuse the same code for more formats. The good news is that I'm pretty sure that this is entirely doable, but it's a chunk of work. On Tue, Sep 22, 2015 at 9:34 PM, Tim Holy <[email protected]> wrote: > On Tuesday, September 22, 2015 05:21:10 PM Luke Stagner wrote: > > Would it be possible to rewrite @printf as a generated function instead > of > > a macro. That way the calling syntax would be more familiar. > > That's a good suggestion. > > At the risk of encouraging emacs users to "fix" the syntax with ctrl-T, I'd > propose the following (apparently complete?) solution: > > > immutable FormatString{S} end > > FormatString(str::AbstractString) = FormatString{symbol(str)} > > macro f_str(arg) > :(FormatString{symbol($arg)}) > end > > @generated function Base.print{format}(::Type{FormatString{format}}, > args...) > meta = Expr(:meta, :inline) > fmt = string(format) > allargs = [:(args[$d]) for d = 1:length(args)] > quote > @printf($fmt, $(allargs...)) > end > end > > > > Demo: > julia> print(f"%.3f", pi) > 3.142 > julia> function foo(strs) > for str in strs > print(FormatString(str), pi) > end > end > foo (generic function with 1 method) > > julia> strs = ("%.3f\n", "%.5f\n") > ("%.3f\n","%.5f\n") > > julia> foo(strs) > 3.142 > 3.14159 > > julia> @time 1 # just to warm up @time > 0.000004 seconds (148 allocations: 10.151 KB) > 1 > > julia> @time foo(strs) > 3.142 > 3.14159 > 0.000106 seconds (18 allocations: 704 bytes) > > > Nice that we get to re-use the macro that Stefan worked so hard on! > > Best, > --Tim > > > > > On Tuesday, September 22, 2015 at 1:07:23 PM UTC-7, Stefan Karpinski > wrote: > > > Possible, but I don't relish the thought of forever explaining to > people > > > that they need to use printf with or without the @ depending on if they > > > want it to be fast or flexible. If you really don't care about speed, > you > > > can just do this right now: > > > > > > printf(fmt::AbstractString, args...) = @eval > @printf($(bytestring(fmt)), > > > $(args...)) > > > > > > > > > But actually don't do that because it's so horrifically slow and > > > inefficient I just can't. > > > > > > On Tue, Sep 22, 2015 at 3:57 PM, Daniel Carrera <[email protected] > > > > > > <javascript:>> wrote: > > >> On 22 September 2015 at 20:40, Stefan Karpinski <[email protected] > > >> > > >> <javascript:>> wrote: > > >>> I think that before any further discussion takes place of how easy or > > >>> hard implementing a high-performance printf is, anyone who'd like to > > >>> comment should spend some time perusing GNU libc's vfprintf > > >>> implementation > > >>> < > http://repo.or.cz/w/glibc.git/blob/ec999b8e5ede67f42759657beb8c5fef87c8 > > >>> cc63:/stdio-common/vfprintf.c>. This code is neither easy nor > trivial – > > >>> it's batsh*t crazy. > > >> > > >> That is insane... 2388 lines, half of it macros, and I have no idea > how > > >> it works. > > >> > > >>> And we want to match its performance yet be much more flexible and > > >>> generic. The current printf implementation does just that, while > being > > >>> somewhat less insane GNU's printf code. If someone has bright ideas > for > > >>> how > > >>> to *also* allow runtime format specification without sacrificing > > >>> performance or generality, I'm all ears. > > >> > > >> This might be a stupid question, but what's the harm in sacrificing > > >> performance as long as we keep the current @sprintf for scenarios that > > >> call > > >> for performance? I don't always need printf() to be fast. > > >> > > >>> I have some thoughts, but they're just that – thoughts. One option > is to > > >>> change the design and avoid printf-style formatting altogether. But > then > > >>> I'm sure I'll never hear the end of it with people kvetching about > how > > >>> we > > >>> don't have printf. > > >> > > >> Probably. Everyone is used to printf and they are comfortable with it. > > >> > > >> Daniel. > >
