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 > <[email protected]> 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. > >>>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
