[swift-evolution] multi-line string literals

[Jacob Bandes-Storch]

Lua has an interesting solution to this, where the delimiters can be
extended as much as you want, to avoid conflicts with string content.

[[ This ]] and [=[ This ]=] are allowed, and [===[ These [[ are part of the
string ]], since they don't conflict with the outer delimiters. ]===]

http://stackoverflow.com/questions/21246668/whats-the-point-of-nesting-brackets-in-lua

Jacob

On Fri, Dec 11, 2015 at 3:21 PM, Travis Tilley via swift-evolution <
swift-evolution at swift.org> wrote:

> If you're writing a block of github flavored markdown, I can absolutely
> see someone wanting to write out 3 backticks in a multi-line string
> literal. ::shrug::
>
>
>
> On Fri, Dec 11, 2015 at 6:08 PM, Kametrixom Tikara <kametrixom at icloud.com>
> wrote:
>
>> Why don't we just use the back ticks  " ` ", making it similar to markup:
>>
>> let code =
>> ```
>> main = interact id
>> ```
>>
>> I believe nobody would ever want to put three back ticks inside a string.
>>
>> Also I think one doesn't actually want/need interpolation, because every
>> char should be the same in the string as it appears in the code. We can do
>> something like instead (just concat the strings together):
>>
>> let myString = "Hello!"
>> let code =
>> ```
>> main = p "``` + myString + ```"
>>   where p = putStrLn
>> ```
>>
>> (Shorter would be to drop the "+" with some compiler magic, but that's
>> meh)
>>
>> I don't think the use for such literals isn't too common so that it's not
>> necessary to provide string interpolation just for these few cases.
>>
>>
>> On 11 Dec 2015, at 18:29, Travis Tilley via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> My updated thoughts, after some feedback about JSON and escaping, would
>> be to wrap an escaped multi-line literal with triple quotes, and to wrap an
>> unescaped multi-line literal with single quotes... Then, to make the
>> overall syntax consistent, to do the same for single-line strings. In
>> either case, quotes of any kind other than a triple quote would not need to
>> be escaped in a multi-line string literal. So:
>>
>>
>> let foo = """
>>   hell yeah, escapes! \n\n
>>   \(sound) like a "\(animal)"
>>   this is another completely random line
>> """
>>
>> Would have a foo variable containing (note the stripped indentation, as
>> that seems to be the popular request in this thread):
>>
>>> hell yeah, escapes!
>>>
>>> moo like a "cow"
>>> this is another completely random line
>>
>>
>> But if wrapped by ''' then none of the interpolation or escape processing
>> happens (and quotes still don't need to be escaped).
>>
>> Come to think of it, I don't see why a ''' syntax would -have- to be
>> multi-line. No reason why '''/"moo"/"cow"/g''' should be invalid from a
>> technical perspective. (note that swift has no native regex literal, though
>> you can create your own and this triple single-quote syntax might make that
>> less painful)
>>
>>
>> - Travis Tilley
>>
>>
>> On Fri, Dec 11, 2015 at 12:01 PM, John Siracusa via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> Sorry about the lack of a subject on this message originally. I was
>>> replying to the email digest and forgot to add one. It should be part of
>>> the "multi-line string literals" thread.
>>>
>>> -John
>>>
>>> On Fri, Dec 11, 2015 at 11:52 AM, John Siracusa <siracusa at gmail.com>
>>> wrote:
>>>
>>>>
>>>> Chris Lattner wrote:
>>>>
>>>>> When introducing a feature like this, I think it would be useful to
>>>>> survey a range of popular languages (and yes, even perl ;-) to understand
>>>>> what facilities they provide and why (i.e. what problems they are solving)
>>>>> and synthesize a good swift design that can solve the same problems with a
>>>>> hopefully simple approach.
>>>>
>>>>
>>>> Travis Tilley wrote:
>>>>
>>>>> ​Perl and Erlang are unique in that valid code in either language
>>>>> looks essentially like line noise. I'd rather take inspiration from
>>>>> languages like ruby, python, and elixir.​
>>>>
>>>>
>>>> Jokes aside, the ability to choose delimiters for strings and other
>>>> language constructs that surround some value is a huge boon to code
>>>> readability.
>>>>
>>>> For example, RegExp literals in JavaScript:
>>>>
>>>> var regex = /^\/usr\/local\//; // gross
>>>>
>>>> An even simpler example, which applies to many languages: a string
>>>> literal that contains all of your possible string delimiters within it.
>>>> This is not an exotic thing in English.
>>>>
>>>> message = "\"I don't like this,\" she said."; // nope
>>>> message = '"I don\'t like this," she said.';  // still nope
>>>>
>>>> Then, of course, there's your escape character itself:
>>>>
>>>> escapes = "Some escapes: \\n, \\t, \\a"; // sigh
>>>>
>>>> There are many time-tested solutions to these syntactic/cosmetic
>>>> problems.
>>>>
>>>> * Different delimiters with different interpolation rules (e.g., single
>>>> quotes not honoring any backslash escapes and not doing variable
>>>> interpolation)
>>>>
>>>> * Matched-pair delimiters that don't require anything to be escaped as
>>>> long as the delimiters are absent or matched within the string. (These
>>>> alone solve a huge range of problems.)
>>>>
>>>> * Heredocs for long literals where you get to pick the end token.
>>>>
>>>> * Heredocs modified by delimiters around the end token to control
>>>> interpolation within the long literal.
>>>>
>>>> Which language looks like line noise now?
>>>>
>>>> $messasge = q("I can't believe how nice this is," she said (quietly).);
>>>>
>>>> $regex = qr(^/usr/local/);
>>>>
>>>> $escapes = 'Some escapes: \n, \t, \a';
>>>>
>>>> My take: once you use a language where you pretty much never have to
>>>> backslash-escape a character you can easily type to get it into a string,
>>>> it's really hard to go back.
>>>>
>>>> -John
>>>>
>>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151211/fa31c45b/attachment.html>