<div dir="ltr">General implementation question:<div><br></div><div>The version of this feature I currently have working introduces something of a chicken-and-egg problem while bootstrapping:</div><div><br></div><div>The initial version of the compiler being used for the build of course has no knowledge of multi-line strings. Thus, all instances of single-character backtick literals must appear like single-quote-literal / backtick literal / single-quote-literal.</div><div><br></div><div>However, once "ppc1" is built, it no longer accepts that, and instead requires the backtick equivalent of the current single-quote-literal syntax (by which I mean, four backticks.)</div><div><br></div><div>Currently, I've solved this via an ifdef, however, as there are indeed a number of source files in the FPC codebase besides the compiler where currently single-quote-literal / backtick literal / single-quote-literal appears, it seems like an unwieldy solution.</div><div><br></div><div>Would it be better to continue to allow single backticks to appear specifically (and only) inside of *single-line* strings (that is, at any point between two apostrophes)?</div><div><br></div><div>I could implement that just as easily, so that's not a concern, and it still would not change the behavior of strings overall in any breaking way.</div><div><br></div><div>So it's more a matter of just what people think the overall best way to go about it is.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 3, 2019 at 9:29 AM Ben Grasset <<a href="mailto:operator97@gmail.com">operator97@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">This has been discussed I think several times in the past, but I thought I'd bring it up once more as it has never made sense to me that FPC happily supports multi-line <b>comments</b> of any length, while having no such multi-line equivalent for string literals.<div><br></div><div>I was fiddling around with what the clearest, easiest-to-parse, and most similar-to-existing-syntaxes way of doing it would be, and came up with this:</div><div><br></div><div>const MultiLineString = (##<br> 'The<br> line<br> endings<br> would<br> be<br> implicit<br> here.<br> This<br> is<br> significantly<br> cleaner<br> looking<br> overall<br> IMO!'<br>##);</div><div><br></div><div>The rationale being: round-bracket-plus-double-pound-sign is an uncommon enough combination of characters that it is highly unlikely to conflict with anything anyone currently has written inside of a string literal, and also relatively similar to the classic round-bracket-plus-apostrophe multi-line-Pascal-comment syntax.</div><div><br></div><div>(It could even be reduced to just one pound sign after the opening bracket and before the closing bracket if that was deemed "safe" to do, but I was just trying to play it safe here.)</div><div><br></div><div>So the grammar rules would be:</div><div><br></div><div>Any instance of (## <b>must</b> be immediately followed by a single apostrophe. After that, a string is parsed, line by line, until another single apostrophe is hit. That second apostrophe <b>must </b>be immediately followed by ##) and then finally a semicolon to "terminate" everything.</div><div><br></div><div>Note that in Lazarus, for example, everything from the opening (## to the closing ##) would be highlighted in blue just as multi-line comments and <b>unbroken </b>string literals currently are, making them stand out nice and clearly.</div><div><br></div><div>To compare that directly to the current way of doing multi-line strings:<br><br>const SingleLineString =<br> 'No' + sLineBreak +<br> 'implicit' + sLineBreak +<br> 'line' + sLineBreak +<br> 'endings' + sLineBreak +<br> 'are' + sLineBreak +<br> 'currently' + sLineBreak +<br> 'available.' + sLineBreak +<br> 'I' + sLineBreak +<br> 'fail' + sLineBreak +<br> 'to' + sLineBreak +<br> 'see' + sLineBreak +<br> 'how' + sLineBreak +<br> 'this' + sLineBreak +<br> 'syntax' + sLineBreak +<br> 'is' + sLineBreak +<br> 'preferable' + sLineBreak +<br> 'in' + sLineBreak +<br> 'any' + sLineBreak +<br> 'way.';<br></div><div><br></div><div>I simply don't, personally, see any argument in <b>favor</b> of the current way. (Much more "line noise" due to all the apostrophes, addition signs, and "sLineBreaks", and of course no consistent blue syntax highlighting in IDEs, as well as the fact that it's much more difficult to make use of already-formatted-like-you-want-it text that way, and so on.)</div><div><br></div><div>Thoughts?</div></div>
</blockquote></div>