multi-line string literals.


(Ted van Gaalen) #1

hello,
Have read all? conversations about this subject...

Would you all be so kind to take a look at what I suggested
and wrote appr. a week ago? (data lines)
This is with using:
        \@ for verbatim as-is character data
and
        \\ for character data with processing of \ escaped chars and \(var)

The advantage of what I describe is that apart from that a data line starts with
  \@ or \\
No delimiters involved at the start and end of a pack of data lines,
which, if I have seen this correctly, is nowhere the case with the other suggestions
here.

···

--------------
In the meantime I've seen and read more about FP. Some nice and even humoristic videos about this subject. This brought me a different and more nuanced impression
about functional programming and how I can use it.. This contrasts highly with the view of some more or less fanatic individuals, (biasing my impressions)which believe they take part in a holy war, rolling with tanks all over the programing landscape. They spoil it all like people with extreme views tend to do in all aspects on our beautiful blue planet. In any case I was relieved, feeling a lot better and seeing how it can be succesfully integrated into Swift makes me feel more relaxed about most chances and enhancements that can make Swift a very unique and state of the art language. It can be harmonious with OOP as well, which is great. It could be that both forms melt together easily. So, it is sometimes not so easy to keep an open mind, as we are all subjective beings, instinctively defensive against new things...to go beyond what we are "certain" of..
Kind Regards, TedvG
no more time now . moving boxes..physical container objects :o}
www.ravelnotes.com


(Brent Royal-Gordon) #2

Would you all be so kind to take a look at what I suggested
and wrote appr. a week ago? (data lines)
This is with using:
@ for verbatim as-is character data
and
\ for character data with processing of \ escaped chars and (var)

The advantage of what I describe is that apart from that a data line starts with
@ or \
No delimiters involved at the start and end of a pack of data lines,
which, if I have seen this correctly, is nowhere the case with the other suggestions
here.

I addressed suggestions of that type in the third draft of the proposal (although the precise example I used was using " as the data line marker):

Don’t require the end quote

Since each line is marked with a continuation quote, in theory, the end
quote is redundant; the string could simply end after the last line
with a continuation quote.

// Something like:
let xml = M"<?xml version="1.0"?>
           "<catalog>
           "	<book id="bk101" empty="">
           "		<author>\(author)</author>
           "	</book>
           "</catalog>

Alternatively, the M modifier could be left out (which would require
quotes on that line to be escaped), or a different
character or character sequence could be used. There was a fair bit of
bikeshedding on this; in some cases, a single post suggested several
syntaxes with slightly different semantics (such as different escaping
rules). Some marked the first and/or last line differently from the
other lines. What they all have in common is that the beginning of each
line is marked in some way, but the end is not, even at the end of the
literal.

Because there is no end delimiter—only a start-of-line marker—these
designs may not require you to escape quotes; thus, they could
potentially obviate the need for an alternate delimiter feature as
well. Depending on the design, however, many of them have issues:

  • In most designs, it is possible to create a single-line string with
    the feature, but the resulting code tends to be ugly and awkward.

  • If the last line is marked the same as the others and the user forgets
    the marker on a line, the compiler has no way to notice, except by
    diagnosing errors caused by treating a line of a string literal as
    code. Since some lines of string content will be valid code (such as
    blank lines or C-style comments), these mistakes may pass unnoticed.

  • If the last line is marked the same as the others, then commenting
    out a line of a string literal, inserting a blank line in the middle
    of a string literal, or just in general inserting some sort of valid
    Swift code in the middle of a string literal would break the literal
    in half, once again potentially forming syntactically valid but
    incorrect Swift code.

  • Generally, the more these constructs work to avoid the above
    problems, the uglier and less quote-like they end up looking, and
    the more complex they will be for the parser.

Finally, all approaches share one fundamental issue.

String literals are expressions, and so they ought to have a syntax
which can be nested inside other expressions. Line-oriented features
like these don’t work well as expressions, because you normally place
several expressions on a single line, nesting them inside one another.
Thus, these features may be awkward to use in any but the simplest
ways.

···


Brent Royal-Gordon
Architechies


(L Mihalkovic) #3

I have a simple working prototype where the following just works

Let v = _" "key": "value" "_

I am working on adding

Let v =
   /* this is a template */
   _" "key": "value" "_

Let v @string_literal(json) =
   /* this is a template */
   _" "key": "value" "_

This strikes me as far less intrusive on the current compiler structure
Regards
(From mobile)

···

On May 7, 2016, at 3:48 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Would you all be so kind to take a look at what I suggested
and wrote appr. a week ago? (data lines)
This is with using:
       \@ for verbatim as-is character data
and
       \\ for character data with processing of \ escaped chars and \(var)

The advantage of what I describe is that apart from that a data line starts with
\@ or \\
No delimiters involved at the start and end of a pack of data lines,
which, if I have seen this correctly, is nowhere the case with the other suggestions
here.

I addressed suggestions of that type in the third draft of the proposal (although the precise example I used was using `"` as the data line marker):

### Don't require the end quote

Since each line is marked with a continuation quote, in theory, the end
quote is redundant; the string could simply end after the last line
with a continuation quote.

// Something like:
let xml = M"<?xml version="1.0"?>
          "<catalog>
          "	<book id="bk101" empty="">
          "		<author>\(author)</author>
          "	</book>
          "</catalog>

Alternatively, the `M` modifier could be left out (which would require
quotes on that line to be escaped), or a different
character or character sequence could be used. There was a fair bit of
bikeshedding on this; in some cases, a single post suggested several
syntaxes with slightly different semantics (such as different escaping
rules). Some marked the first and/or last line differently from the
other lines. What they all have in common is that the beginning of each
line is marked in some way, but the end is not, even at the end of the
literal.

Because there is no end delimiter—only a start-of-line marker—these
designs may not require you to escape quotes; thus, they could
potentially obviate the need for an alternate delimiter feature as
well. Depending on the design, however, many of them have issues:

* In most designs, it is possible to create a single-line string with
the feature, but the resulting code tends to be ugly and awkward.

* If the last line is marked the same as the others and the user forgets
the marker on a line, the compiler has no way to notice, except by
diagnosing errors caused by treating a line of a string literal as
code. Since some lines of string content will be valid code (such as
blank lines or C-style comments), these mistakes may pass unnoticed.

* If the last line is marked the same as the others, then commenting
out a line of a string literal, inserting a blank line in the middle
of a string literal, or just in general inserting some sort of valid
Swift code in the middle of a string literal would break the literal
in half, once again potentially forming syntactically valid but
incorrect Swift code.

* Generally, the more these constructs work to avoid the above
problems, the uglier and less quote-like they end up looking, and
the more complex they will be for the parser.

Finally, all approaches share one fundamental issue.

String literals are expressions, and so they ought to have a syntax
which can be nested inside other expressions. Line-oriented features
like these don't work well as expressions, because you normally place
several expressions on a single line, nesting them inside one another.
Thus, these features may be awkward to use in any but the simplest
ways.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Ricardo Parada) #4

It seems to me like this would take care of what is needed 99% of the time.

I've seen many who don't favor continuation quotes.

The other option could be triple quote """ and make the continuation quote optional. Not using the continuation quote would require the closing triple quote """

···

On May 7, 2016, at 9:48 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

// Something like:
let xml = M"<?xml version="1.0"?>
          "<catalog>
          "	<book id="bk101" empty="">
          "		<author>\(author)</author>
          "	</book>
          "</catalog>

(L Mihalkovic) #5

Regards
(From mobile)

It seems to me like this would take care of what is needed 99% of the time.

I've seen many who don't favor continuation quotes.

The other option could be triple quote """ and make the continuation quote optional. Not using the continuation quote would require the closing triple quote """

For having built a prototype, I've come to realize that there are more alternatives.

This is some of my own tests:
https://gist.github.com/lmihalkovic/718d1b8f2ae6f7f6ba2ef8da07b64c1c

The idea of these M/e or any other similar prefix remind me of my perl days (there were a lot of these), and IMO have little to do with the rest of Swift.

···

On May 8, 2016, at 12:49 AM, Ricardo Parada via swift-evolution <swift-evolution@swift.org> wrote:

On May 7, 2016, at 9:48 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

// Something like:
let xml = M"<?xml version="1.0"?>
         "<catalog>
         "    <book id="bk101" empty="">
         "        <author>\(author)</author>
         "    </book>
         "</catalog>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Ricardo Parada) #6

The _" and "_ are a good alternative I think.

For some reason the underscore bothers me: it doesn't look as good aesthetically as others, and because it is already used for a couple of other things in Swift (to make large numbers readable and as a placeholder to discard a value).

By the way has the backtick or triple backtick been considered?

···

On May 7, 2016, at 7:24 PM, L. Mihalkovic <laurent.mihalkovic@gmail.com> wrote:

Regards
(From mobile)

On May 8, 2016, at 12:49 AM, Ricardo Parada via swift-evolution <swift-evolution@swift.org> wrote:

It seems to me like this would take care of what is needed 99% of the time.

I've seen many who don't favor continuation quotes.

The other option could be triple quote """ and make the continuation quote optional. Not using the continuation quote would require the closing triple quote """

For having built a prototype, I've come to realize that there are more alternatives.

This is some of my own tests:
https://gist.github.com/lmihalkovic/718d1b8f2ae6f7f6ba2ef8da07b64c1c

The idea of these M/e or any other similar prefix remind me of my perl days (there were a lot of these), and IMO have little to do with the rest of Swift.

On May 7, 2016, at 9:48 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

// Something like:
let xml = M"<?xml version="1.0"?>
        "<catalog>
        "    <book id="bk101" empty="">
        "        <author>\(author)</author>
        "    </book>
        "</catalog>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Brent Royal-Gordon) #7

By the way has the backtick or triple backtick been considered?

Backticks already have a meaning—they "quote" an identifier which would otherwise be taken as a keyword.

···

--
Brent Royal-Gordon
Sent from my iPhone

On May 8, 2016, at 2:58 PM, Ricardo Parada <rparada@mac.com> wrote:

The _" and "_ are a good alternative I think.

For some reason the underscore bothers me: it doesn't look as good aesthetically as others, and because it is already used for a couple of other things in Swift (to make large numbers readable and as a placeholder to discard a value).

On May 7, 2016, at 7:24 PM, L. Mihalkovic <laurent.mihalkovic@gmail.com> wrote:

Regards
(From mobile)

On May 8, 2016, at 12:49 AM, Ricardo Parada via swift-evolution <swift-evolution@swift.org> wrote:

It seems to me like this would take care of what is needed 99% of the time.

I've seen many who don't favor continuation quotes.

The other option could be triple quote """ and make the continuation quote optional. Not using the continuation quote would require the closing triple quote """

For having built a prototype, I've come to realize that there are more alternatives.

This is some of my own tests:
https://gist.github.com/lmihalkovic/718d1b8f2ae6f7f6ba2ef8da07b64c1c

The idea of these M/e or any other similar prefix remind me of my perl days (there were a lot of these), and IMO have little to do with the rest of Swift.

On May 7, 2016, at 9:48 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

// Something like:
let xml = M"<?xml version="1.0"?>
       "<catalog>
       "    <book id="bk101" empty="">
       "        <author>\(author)</author>
       "    </book>
       "</catalog>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Vladimir) #8

Btw, in c# we have @ to drop escapes:
@"c:\Docs\Source\a.txt" // rather than "c:\\Docs\\Source\\a.txt"
@"""Ahoy!"" cried the captain." // "Ahoy!" cried the captain.

and(!) also as 'marker' that allows to use keywords as identifiers:
class @class
{
    public static void @static(bool @bool) {..}
..
}

so, probably it is OK to have backtick also as 'special' string marker in Swift ?
`abc "def" \(hahaha /// \total-10`

Also, wanted to drop some alternatives:
* what about single quote? like
'abc "def" \(hahaha /// \total-10'
(if single quote appear in text - it should be doubled, so
'example '' - is a "single" quote'

* what about @ like in c# for string literals just to say "do not process escapes" (double quotes should be doubled) :
@"this just text \( \t \n but with ""double quotes"""

* what about $".."$ to mark a sting as-is, without escapes, without interpolation, allows double quote without escaping(putting twice)? Yes, "$ combination will not be allowed inside of such string.

···

On 09.05.2016 1:13, Brent Royal-Gordon via swift-evolution wrote:

By the way has the backtick or triple backtick been considered?

Backticks already have a meaning—they "quote" an identifier which would
otherwise be taken as a keyword.

--
Brent Royal-Gordon
Sent from my iPhone

On May 8, 2016, at 2:58 PM, Ricardo Parada <rparada@mac.com > <mailto:rparada@mac.com>> wrote:

The _" and "_ are a good alternative I think.

For some reason the underscore bothers me: it doesn't look as good
aesthetically as others, and because it is already used for a couple of
other things in Swift (to make large numbers readable and as a
placeholder to discard a value).

On May 7, 2016, at 7:24 PM, L. Mihalkovic <laurent.mihalkovic@gmail.com >>> <mailto:laurent.mihalkovic@gmail.com>> wrote:

Regards
(From mobile)

On May 8, 2016, at 12:49 AM, Ricardo Parada via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

It seems to me like this would take care of what is needed 99% of the
time.

I've seen many who don't favor continuation quotes.

The other option could be triple quote """ and make the continuation
quote optional. Not using the continuation quote would require the
closing triple quote """

For having built a prototype, I've come to realize that there are more
alternatives.

This is some of my own tests:
https://gist.github.com/lmihalkovic/718d1b8f2ae6f7f6ba2ef8da07b64c1c

The idea of these M/e or any other similar prefix remind me of my perl
days (there were a lot of these), and IMO have little to do with the
rest of Swift.

On May 7, 2016, at 9:48 AM, Brent Royal-Gordon via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

// Something like:
let xml = M"<?xml version="1.0"?>
       "<catalog>
       "    <book id="bk101" empty="">
       "        <author>\(author)</author>
       "    </book>
       "</catalog>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution