> On 4 May 2016, at 15:07, L. Mihalkovic <[email protected]> wrote:
>
> Cool job!.. Yup, you proceed by "widening the existing holes" to carry the
> missing info (eg Modifiers). Making direct changes to lexCharacter() is a
> step I thought might be a bit premature considering nothing is carved in
> stone yet. I was trying to advocate for a clean boundary between current
> behavior and new ones, such that we, as well as others, would be able to try
> alternative syntaxes by changing the content of clearly identified methods
> (as opposed to starting their own integration from scratch each time, or
> having to un-unstitch parts of multiple already not so simple methods). I
> guess I am also extra cautious in my own coding because this a lexer, and the
> more paths through something like lexCharacter() or
> getEncodedStringSegment(), the more difficult it might be to prove that all
> of them have been identified and exercised. Thx for inspiring my
> experimentations.
>
Thanks (I think!). I’m not trying to disenfranchise other developers by trying
to squeeze all functionality into the existing functions.
It’s the nature of the problem. Multiline strings, alternative delimiter _””_
and non processing of escapes (\’s) are orthogonal;
they can in theory be applied separately and together. Wouldn’t that require 8
separate implementations dependent on
the combination? Far easier to just use modality. The code is getting unruly
but not beyond the pale yet.
It’s just a prototype anyway intended to help with specification and testing.
Better take a step back.
Did we get near to acquiescence to any of the following as a prospective
proposal (as I understand it)?
1) Any string literal that is it not closed becomes a multiline literal
if the first non-whitespace character on the next line is “
let 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>\n"
print(xml)
While this is not ideal in terms of having to massage data templates as you
paste them in, it is the price of code that looks
easy on the eye. (In practice pasting into Xcode it will reformat your string
anyway so editing will normally be required.)
What will other editors make of this novel format?
Optionally, for a separate proposal perhaps:
2) As a convenience, if a literal starts with _” it must be terminated
by “_ to avoid having to escape embedded “s.
assert( 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>
""_ )
3) Opening the floodgates to an alphabet of the literal modifiers, if
the string starts e”a string” then all escape sequences
including interpolation but not including \” and \<newline> are not
processed but passed through into the literal intact.
assert( e"\w\d+\(author)\n" == "\\w\\d+\\(author)\\n" );
These modifiers are smuggled through the parsing process to code
generation by storing them against the Token.
Very Optionally, and largely as an historical accident
4) an r”regex” string will pass through non-standard escapes but still
process \0, \r, \n, \”, \’, \\, \u{NNNN} and \(
assert( r"\w\d+\(author)\n" == "\\w\\d+\(author)\n" ); // handy if you
ask me
Brent, what is the state of the proposal document you prepared?
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
