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 <operato...@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? >
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
