-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhanced Interpolations to Replace @printf
#18703
Comments
Does Could we just allow keyword arguments: "$(x; kwargs...)" == string(x; kwargs...) And have more complex strings nest calls to "string" (one call for each $ and a final one for concatenation) or whatever. |
Someone who knows more about the current implementation would have to comment. I assume that it's something similar to that, which means this wouldn't be really hard to implement. A small description of the current setup could probably make make this an easy PR. |
I don't think it does? julia> x = 1
1
julia> @code_lowered("$x")
CodeInfo(:(begin
nothing
return (Base.dec)(x)
end))
julia> x = 1.0
1.0
julia> @code_lowered("$x")
CodeInfo(:(begin
nothing
return (Core._apply)(Base.print_to_string, xs)
end)) but someone more familiar with internals should comment |
It does:
|
@ararslan Do you remember why the thumbs down? Is this just not needed in Base or some other better PR suggesting? Or as in discourse, pointed out as alternative: https://github.com/JuliaString/StringLiterals.jl [Should people in general explain thumps downs?] |
I would generally appreciate this. An unexplained thumbs down generally comes off as kind of passive aggressive and unconstructive. Unless it's clear why you have a problem with something, it's not really helping the conversation. |
No, but rereading this I find it odd and don't see the benefit over |
Is this still relevant/desired? I haven't seen too many requests to overload how an object is interpolated into strings, but maybe I've missed if people still need something like this. It seems that just overloading |
The main use case would be being able to write something like
instead of
A long time ago I started a Julep along these lines (JuliaLang/Juleps#49). I'd still be in favor of this, but the main technical challenge is that it requires mucking about in the parser. |
If I try this now, I get
@c42f as the last person to touch the relevant piece of code in the parser Lines 2368 to 2385 in c4d162e
do you have any idea what would be involved in supporting this? |
This isn't actually a parser error! The error arises from lowering: julia> dump(Meta.parse("\$(1.0, digits=2)"))
Expr
head: Symbol $
args: Array{Any}((1,))
1: Expr
head: Symbol tuple
args: Array{Any}((2,))
1: Float64 1.0
2: Expr
head: Symbol =
args: Array{Any}((2,))
1: Symbol digits
2: Int64 2 Currently syntax like I guess I'd suggest something like
where |
It's probably relatively easy to add this to the first syntax desugaring pass in lowering, somewhere around here: Line 2696 in c4d162e
|
Isn't that just parsing
|
Haha oops! You're right of course. |
Huh, so ah... turns out I didn't copy this restriction into JuliaSyntax.jl ... so the parser fix could be just merging #46372 julia> dump(JuliaSyntax.parsestmt(Expr, "\"\$(x, digits=1)\""))
Expr
head: Symbol string
args: Array{Any}((1,))
1: Expr
head: Symbol tuple
args: Array{Any}((2,))
1: Symbol x
2: Expr
head: Symbol =
args: Array{Any}((2,))
1: Symbol digits
2: Int64 1 (But also I should really add this restriction back into the parser. I'm not sure how it got left out.) |
Ok I've fixed this in JuliaSyntax now and also had a look in the reference parser as part of doing that. To answer the question, it should be fairly easy to change this in the parser - it's roughly a matter of changing the Having changed this we'd need a new expression head as a way to distinguish between I'd suggest something like
I guess. (maybe there's a better name than |
That seems like the obvious lowering. Given how I was actually going to suggest just |
Here's a prototype implementation in JuliaSyntax JuliaLang/JuliaSyntax.jl#308 |
One way to handle the replacing
@printf
may be to enhance string interpolation. To do this, one could introduce ato_str
function (I am not set on the name, but am using it for discussion. This is a proposal for the architecture). For example, currently”piece1$var piece2”
parses similarly tostring(“piece1", var, “ piece2”)
. In reality,"$var"
is the same as"$(var)"
. My idea is to extend the interpolating$()
to a full function call,to_str
, and allow arguments.For example, we could instead use
”piece1$(var,args...) piece2”
which would extend tostring(“piece1", to_str(var,args...), “ piece2”)
.to_str
would be a function which returns a String (or if not,to_str
is reursively called on the output). The standardto_str
would bewhich would just give the string output of the
print
method. But this let's us generalize a lot. For example, we could doto be a function which gives back a string which which is in the chosen style. This would allow one to make
$(var,:sci,dec=3) is the result"
interpolate into the stringvar
in scientific notation with 3 decimal places.I am not proposing the exact details for the Base
to_str
functions, but I think this architecture would work really well for Base since it would cover most use cases while being very extendable (anyone could add dispatches for their own types, so they would work seamlessly for interpolation). This is very different from the idea of #10610, but I think this is a conservative extension to current interpolation behavior that matches well with Julia intuition and could cover most of what people need with@printf
(with anything super special handled in packages).The text was updated successfully, but these errors were encountered: