On May 2, 2016, at 1:49 AM, Brent Royal-Gordon <[email protected]> wrote:
>> • using the default string literal recognition mechanism binds us to have >> to ‘wait’ a bit in order to figure which kind of string literal we are >> dealing with (single/multi line) > > Part of the idea of the continuation quotes proposal is that there *is* no > distinction between a single-line literal and a multi-line literal. There are > just string literals, which may include one line or many. > > And in general, part of the advantage of this proposal is precisely that it > has such low impact on the parser and lexer, and the grammar more generally. > It is currently illegal to open a string and fail to close it on the same > line, so we are just giving that obviously illegal construct an > interpretation. By extending the existing feature, we get a whole lot of > stuff for free: > I appreciate how easy it is to retrofit some multiline literal behavior without touching much as demonstrated by John's code (I also implemented a different patch that isolates all code changes inside a couple new methods and generates the existing string_literal token). The problem I am facing is that I also want to support "ZERO massaging" schemes (direct past without editing the lines), and so far I have not seen how to do it without opening a wider whole through the parser/lexer. I chose to make a parallel route simply to avoid risking making my code a merge nightmare as soon as the core team touches anything in the vicinity. > * We don't have to worry about whether `|>` or `@|` or whatever construct you > end up using might, in some place where you could otherwise use a string > literal, be confusable with some other construct. > * We don't have to worry about whether obscure corners of the language, like > the string parameters to `@available`, support multiline string literals > (they do, automatically). > * We don't have to do a huge amount of redesigning in the lexer, and I doubt > we'll have to touch the parser at all (the prototype doesn't). > > It seems a bit backwards to propose we introduce a separate path for lexing > multiline strings, and then complain that one of the proposals on the table > makes it difficult to tell which path you should take, when the proposal in > question is specifically designed to make having a separate path unnecessary. Just to be sure, I am complaining about anything, but merely referencing an argument I read in one of John Holdsworth's recent contribution. Regarding the "unnecessary separate path", IMHO it depends on what the end game is supposed to look like (as previously stated, I want to try tagging the contents of multine literals, which makes them different from single line ones), and at what horizon. No matter what, you are the experts... I just appreciate how easy the quality of the codebase makes prototyping some of these ideas. King regards _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
