[swift-evolution] [Pitch] alternative multiline string literals

[L Mihalkovic]

Please accept my apologies for the repeat… I seem to have more trouble with my emails than the brilliant codebase this team has produced.
Best regards
LM/

——————————

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
type checker code for the @string_literal attribute 
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:
comment before the literal data
@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. I persist in thinking that a lot of good can come from being able to tag the contents of string literal (e.g. XML schema validation, custom syntax coloring, … )
the code is based on a string_multiline_literal tag to make these extension formally visible in the grammar 
no need to prefix each line (although it will be possible to use | as a margin)



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 <mailto: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/bea7c95a/attachment.html>