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 > <[email protected] <mailto:[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
