Skip to content
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

Bring back string literal juxtaposition = concatenation? #28348

Closed
IainNZ opened this issue Jul 30, 2018 · 11 comments
Closed

Bring back string literal juxtaposition = concatenation? #28348

IainNZ opened this issue Jul 30, 2018 · 11 comments
Labels
needs decision A decision on this change is needed parser Language parsing and surface syntax

Comments

@IainNZ
Copy link
Member

IainNZ commented Jul 30, 2018

In particular, parse-time concatenation.

Current behaviour on Julia 0.6:

julia> x = "foo""bar"
"foobar"

julia> x = ("foo"
       "bar")
ERROR: syntax: missing comma or ) in argument list

#21787 killed off the first case "foo""bar". That was to fix #20575 which was talking about juxtaposition of "foo"x, not two literals. A big past discussion on related topics happened in #2301, which mostly doesn't talk about this issue except in two posts at the end.

It works in C, and Python copied it. In this post Guido asks whether he should deprecate it, and there is useful summary of where the conversation went.

My main interest is in this is for long error messages, which came up a lot when writing library code in Python in the last major codebase I worked on. Triple-quoted strings aren't really a good solution, and the chaff of * is kind of annoying (especially in more nested code and an 80 char limit).

Given this is completely removed from 0.7 and is a parse-time error, I guess adding this in later is possible, so not urgent. But was curious what people thought.

@JeffBezanson
Copy link
Member

I read the link. And I quote:

Van Rossum's lament should be a helpful reminder for language designers. It is very difficult to get rid of a feature once it has been added.

Why are triple-quoted strings not a good solution?

@ararslan
Copy link
Member

Why are triple-quoted strings not a good solution?

Well, they force line breaks into the text, whereas "a" * "b" * ... does not.

@IainNZ
Copy link
Member Author

IainNZ commented Jul 30, 2018

Yeah the link isn't exactly strong backing for what I'm asking for...

Triple-quoted newlines make for bad exceptions due to the newlines at an arbitrary position based on how deeply the exception message was indented when it started (given a fixed number of columns).

Here is some fake Julia code that demonstrates the utility:

module Example

function solve_ai(data::Data{Big})
    if weather_looks_good()
        if !valid(data)
            throw(NotIntelligentError("Could not solve AI due to invalid data "
                                      "(size $(size(data)), please reinstall "
                                      "universe and try again (or give up).")))
        else
            return AI()
        end
    end
end

end  # module Example.

With concatenation, its just more visual noise:

            throw(NotIntelligentError("Could not solve AI due to invalid " *
                                      "data (size $(size(data)), please " *
                                      "reinstall universe and try again " *
                                      "(or give up).")))

@JeffBezanson JeffBezanson added parser Language parsing and surface syntax needs decision A decision on this change is needed labels Jul 30, 2018
@RalphAS
Copy link

RalphAS commented Jul 31, 2018

I haven't seen it mentioned that the proposal would be breaking (without strange precedence rules):

julia-0.6> ["abc" "def"]
1×2 Array{String,2}:
 "abc"  "def"

@IainNZ
Copy link
Member Author

IainNZ commented Aug 2, 2018

Yeah that seems pretty fatal. Ah well.

@IainNZ IainNZ closed this as completed Aug 2, 2018
@IainNZ
Copy link
Member Author

IainNZ commented Aug 2, 2018

Playing around with string macros could make triple-quotes viable maybe, by stripping newlines.

@omus
Copy link
Member

omus commented Aug 2, 2018

If we go the string macro route we should should make it general and support options with flags:

julia> macro ex_str(str, flags)
           str, flags
       end
@ex_str (macro with 1 method)

julia> ex"foo"abc
("foo", "abc")

@IainNZ
Copy link
Member Author

IainNZ commented Aug 5, 2018

Thats not quite what I meant, at least. What I meant was:

macro nn_str(foo)
    return replace(foo, "\n", " ")
end

x = nn"""Multiline
         string
         testing"""

@show x
x = "Multiline string testing"

@IainNZ
Copy link
Member Author

IainNZ commented Aug 5, 2018

(I don't know how to make that work with interpolation but thats the rough idea)

@omus
Copy link
Member

omus commented Aug 6, 2018

I didn't explain myself very well in my previous post. Somewhat similar to your use case I also can also see having string macro for removing the trailing newline (chomp). I find myself formatting longer multi-line strings with the trailing """ on its own line which introduces a trailing newline. For example:

julia> x = """
           Bacon ipsum dolor amet biltong alcatra short loin, meatball jerky corned
           beef porchetta shoulder kevin t-bone ham flank. Strip steak biltong flank bacon.
           """
"Bacon ipsum dolor amet biltong alcatra short loin, meatball jerky corned\nbeef porchetta shoulder kevin t-bone ham flank. Strip steak biltong flank bacon.\n"

Potentially this could be included in the same macro using flags.

@IainNZ
Copy link
Member Author

IainNZ commented Aug 7, 2018

Yeah. Although - what I'm doing above doesn't actually require a macro at all. It just is the tersest possible thing with a macro.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs decision A decision on this change is needed parser Language parsing and surface syntax
Projects
None yet
Development

No branches or pull requests

5 participants