[fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

[Ben Grasset]

General implementation question:

The version of this feature I currently have working introduces something
of a chicken-and-egg problem while bootstrapping:

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.

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.)

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.

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)?

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.

So it's more a matter of just what people think the overall best way to go
about it is.

On Wed, Jul 3, 2019 at 9:29 AM Ben Grasset <operator97 at gmail.com> wrote:

> 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 *comments* of any length, while having no such
> multi-line equivalent for string literals.
>
> 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:
>
> const MultiLineString = (##
>   'The
>    line
>    endings
>    would
>    be
>    implicit
>    here.
>    This
>    is
>    significantly
>    cleaner
>    looking
>    overall
>    IMO!'
> ##);
>
> 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.
>
> (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.)
>
> So the grammar rules would be:
>
> Any instance of (## *must* 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 *must *be immediately
> followed by ##) and then finally a semicolon to "terminate" everything.
>
> Note that in Lazarus, for example, everything from the opening (## to the
> closing ##) would be highlighted in blue just as multi-line comments and *unbroken
> *string literals currently are, making them stand out nice and clearly.
>
> To compare that directly to the current way of doing multi-line strings:
>
> const SingleLineString =
>   'No' + sLineBreak +
>   'implicit' + sLineBreak +
>   'line' + sLineBreak +
>   'endings' + sLineBreak +
>   'are' + sLineBreak +
>   'currently' + sLineBreak +
>   'available.' + sLineBreak +
>   'I' + sLineBreak +
>   'fail' + sLineBreak +
>   'to' + sLineBreak +
>   'see' + sLineBreak +
>   'how' + sLineBreak +
>   'this' + sLineBreak +
>   'syntax' + sLineBreak +
>   'is' + sLineBreak +
>   'preferable' + sLineBreak +
>   'in' + sLineBreak +
>   'any' + sLineBreak +
>   'way.';
>
> I simply don't, personally, see any argument in *favor* 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.)
>
> Thoughts?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190704/b0b980e2/attachment-0001.html>