[swift-evolution] [Pitch] multiline string literals

[L Mihalkovic]

Wanting to test the validity of some of the arguments I read on the main proposal, I worked on my own prototype. I think there is more freedom than seem to have been identified so far.

The syntax I am exploring is visible here: https://gist.github.com/lmihalkovic/718d1b8f2ae6f7f6ba2ef8da07b64c1c <https://gist.github.com/lmihalkovic/718d1b8f2ae6f7f6ba2ef8da07b64c1c>

There are still a couple of things that do not work 
serialization of the @string_literal attribute (I persist in thinking that a lot of good can come from being able to tag the contents of string literal)
skipping leading spaces on each lines, based on the indentation of the first line
removing some of the extra EOL (rule to be defined)

The following works:
comments 
@string_literal(“xxxx”). At the moment the attribute value is a string_literal, maybe a identifier would be better, and maybe it should be @string_literal(type: “xxxx”), so that other properties can be added
the code is based on a string_multiline_literal tag to make these extension visible in the grammar (other prototypes rely on clever tricks in the Lexer)



let s0 = "s0"

let s1 = "{\"key1\": \"stringValue\"}"

let s2 = _"{"v2"}"_

let s3 =
    /* this is a template */
    _"{"key3": "stringValue"}"_

let s4 =
/* this is (almost) the same template */
_"
{
  "key4": "stringValue"
  , "key2": "stringValue"
}
"_

@string_literal("json") let s5 =
  /* this is exactly the same template as s5 */
  _"
  {
    "key5": "stringValue"
  }
  "_

@string_literal("json") let s6 =
  /* this is exactly the same template as s5 */
  _"
  |{
  |  "key6": "stringValue"
  |  , "key2": "stringValue"
  |}
  "_




> On May 7, 2016, at 1:53 AM, John Holdsworth via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I’ve had a go at parsing HEREDOC (why does autocorrect always change this to HERETIC!)
> It wasn’t as difficult as I’d expected once you comment out a few well meaning asserts in the 
> compiler. To keep lexing happy there are two variants <<“HEREDOC” and <<‘HEREDOC’.
> 
>         assert( (<<"XML" + <<"XML") == (xml + xml) )
>         <?xml version="1.0"?>
>         <catalog>
>            <book id="bk101" empty="">
>                <author>\(author)</author>
>                <title>XML Developer's Guide</title>
>                <genre>Computer</genre>
>                <price>44.95</price>
>                <publish_date>2000-10-01</publish_date>
>                <description>An in-depth look at creating applications with XML.</description>
>            </book>
>         </catalog>
>         XML
>         <?xml version="1.0"?>
>         <catalog>
>            <book id="bk101" empty="">
>                <author>\(author)</author>
>                <title>XML Developer's Guide</title>
>                <genre>Computer</genre>
>                <price>44.95</price>
>                <publish_date>2000-10-01</publish_date>
>                <description>An in-depth look at creating applications with XML.</description>
>            </book>
>         </catalog>
>         XML
> 
> Its a credit to it's authors that Xcode and the remainder of the toolchain cope with this remarkably well
> now that tokens arrive out of order. The weird colouring is an artefact I’ve not been able to resolve.
> 
> The changes are here: https://github.com/apple/swift/pull/2275 <https://github.com/apple/swift/pull/2275>, and amount to an additional 60 lines of by no
> means bullet proof code. The total changes for multi-line literals are now 10% of the Swift lib/Parse/Lexer.cpp.
> 
>>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160507/3ee06638/attachment-0001.html>