Syntax experiment: String format syntax eg "$(x, digits=2)"

[c42f]

See JuliaLang/julia#18703

julia> JuliaSyntax.parsestmt(SyntaxNode, "\"prefix \$(1.0, digits=2) suffix\"")
line:col│ tree                                   │ file_name
   1:1  │[string]
   1:2  │  "prefix "
   1:10 │  [format]
   1:11 │    1.0
   1:16 │    [=]
   1:16 │      digits
   1:23 │      2
   1:25 │  " suffix"


julia> JuliaSyntax.parsestmt(Expr, "\"prefix \$(1.0, digits=2) suffix\"")
:("prefix $($(Expr(:format, 1.0, :(digits = 2)))) suffix")

CC @simonbyrne

[giordano]

Can we use semicolons to start keyword arguments here?

[c42f]

Can we use semicolons to start keyword arguments here?

Certainly! But is it a good idea to diverge from the syntax for keyword args supported everywhere else in the language?

[giordano]

But is it a good idea to diverge from the syntax for keyword args supported everywhere else in the language?

Uhm? Keyword arguments do start with semicolons in the language already, sadly that's optional and using commas can lead to not-so-fun-to-debug problems.

[c42f]

Keyword arguments do start with semicolons in the language already

Haha! I do know about this. And some other fiddly details of Julia's syntax ;-)

My point is, I think it'd be confusing not to support the comma notation, given that it's supported and extremely widely used for normal function calls. I think consistency is more important here than trying to fix problems which can't be fixed in the other more widely used syntax due to compat concerns.

[andyferris]

I also kinda feel like semicolons might be good here, but it's not a super strong opinion. For one thing it wasn't obvious to me (before I checked) that "$(1,2)" isn't interpolating the tuple (1,2).

can't be fixed in the other more widely used syntax due to compat concerns

This isn't the right forum/issue - but I rather like the idea of having something like Rust's "editions" to make breaking syntax improvements over time (without needing e.g. Julia 2.0), hence I'd challenge what "can't" be done (eventually...).

[c42f]

I rather like the idea of having something like Rust's "editions" to make breaking syntax improvements over time (without needing e.g. Julia 2.0), hence I'd challenge what "can't" be done (eventually...).

I agree with this and I've been thinking a lot about it for a while :-) I don't know exactly how it should work yet but I've been wanting to write a julep on it :)