Uwe Raabe 2057 Posted March 24, 2023 28 minutes ago, Fr0sT.Brutal said: Why the //s at the end? Because they prohibit the formatter from concatenating the lines. 3 Share this post Link to post
Marco V 3 Posted April 13, 2023 On 3/23/2023 at 2:41 AM, Joseph MItzen said: Fine, I'll do it in Lazarus/FreePascal... guess what? They're limited to 255 characters too, which is bizarre. It's like they artificially limited themselves to match Delphi's limitations! (Free Pascal started life as a Turbo Pascal compatible compiler) Share this post Link to post
emileverh 21 Posted September 19, 2023 They heard my voice ;-)) https://blogs.embarcadero.com/yukon-beta-blog-delphi-language-modernizing-string-literals/ 1 Share this post Link to post
Vandrovnik 214 Posted September 19, 2023 7 minutes ago, emileverh said: They heard my voice ;-)) https://blogs.embarcadero.com/yukon-beta-blog-delphi-language-modernizing-string-literals/ Multiline strings! Share this post Link to post
dummzeuch 1505 Posted September 19, 2023 3 hours ago, emileverh said: They heard my voice ;-)) https://blogs.embarcadero.com/yukon-beta-blog-delphi-language-modernizing-string-literals/ Not quite the implementation I would have liked though. Triple quotes '''? Who came up with that? Is that copyied from another programming language? I mean, Pascal is said to be very verbous, so why not somehing more explicit like: blub := multiline(' line1 line2, indented line3 '); People who don't like verbosity would complain of course, but these would complain about Pascal syntax anyway. (Goes away, silently weeping and anticipating yet another long night trying to adapt the GExperts Source Formatter to yet another string syntax ...) 1 1 Share this post Link to post
Uwe Raabe 2057 Posted September 19, 2023 I actually prefer the new syntax over the suggested one, as that is already occupied by a call to function multiline taking a string parameter - and fails because of the line-breaked string literal. Instead of teaching the compiler that a function call to multiline (what happens if I already have a similar named function in the scope?) to accept line breaks in the only sting literal parameter, the new syntax keeps the available parsers intact. They will just fail on the new multiline syntax as any Delphi compiler version before does. The new syntax is pretty simple to detect: Quote It is introduced by a triple quote (’’’) and a new line (so no text following the triple quotes on the same line) It can encompass multiple lines of the source code file (with no limitation) It ends with a closing triple quote (’’’) in a line without any text preceding it This makes tweaking the parser not too complicated, as the start and end tokens are easy to recognize. While the triple quote alone resembles still valid syntax in previous versions, the mandatory new line would fail to parse. That is the condition where the new parser should intercept until the end condition is met. It still seems unclear how one has to escape a triple quote with no text preceding it inside a multiline string. 1 Share this post Link to post
Kas Ob. 121 Posted September 19, 2023 16 minutes ago, Uwe Raabe said: It still seems unclear how one has to escape a triple quote with no text preceding it inside a multiline string. Not only, but what if the multiline string was Pascal script code that have triple quote encapsulating a literal belongs to the script, and after that what about a semicolon following a triple quote in .... uhh... my head start to multifunction with the variants that can go wrong. That parser must have hundreds of test cases to pass, or as Thomas suggested, i like the idea to simplify the whole multiline strings by restricting it to resource string declaration or something new but similar, instead of a new intrinsic function. Share this post Link to post
Kas Ob. 121 Posted September 19, 2023 Delphi/Pascal survived decades without multiline strings, also introducing them now will break things, but by restricting their usage in one dedicated place, will make adding compatibility backward easier with IFDEF directives and revert to the old style when needed without messing with the code itself. Share this post Link to post
DelphiUdIT 176 Posted September 19, 2023 I think the new syntax is simply an opportunity, not an obligation. And I see no reason to include IFDEF... just don't use it. Share this post Link to post
Anders Melander 1783 Posted September 19, 2023 5 hours ago, emileverh said: They heard my voice ;-)) https://blogs.embarcadero.com/yukon-beta-blog-delphi-language-modernizing-string-literals/ Nice! And about bloody time too! But surely there's more to the CoffeeScript-like syntax than this: Quote There are a few more syntax rules for a multiline string : It is introduced by a triple quote (’’’) and a new line (so no text following the triple quotes on the same line) It can encompass multiple lines of the source code file (with no limitation) It ends with a closing triple quote (’’’) in a line without any text preceding it Like, how does one differentiate between preserve or trim leading white space and preserve or ignore newline? Share this post Link to post
Uwe Raabe 2057 Posted September 19, 2023 Exactly! Nobody is forced to use this new feature. Also, I don't see anything breaking except tools parsing new code using that feature. Obviously that is always the case with new language features. The only way to avoid that is not allowing new language features in the first place. Share this post Link to post
Uwe Raabe 2057 Posted September 19, 2023 1 minute ago, Anders Melander said: how does one differentiate between preserve or trim leading white space and preserve or ignore newline? The docs contain more information than the blog post shows. Share this post Link to post
Anders Melander 1783 Posted September 19, 2023 1 minute ago, Uwe Raabe said: The docs contain more information than the blog post shows. What docs? Share this post Link to post
Uwe Raabe 2057 Posted September 19, 2023 The docs that comes with the beta installer. You don't expect beta testers to discover how to use new features by blind guesses, do you? Of course, one has to participate in the beta to get access to both, but everyone with an active subscription can ask for it. Share this post Link to post
dummzeuch 1505 Posted September 19, 2023 1 hour ago, Uwe Raabe said: I actually prefer the new syntax over the suggested one, as that is already occupied by a call to function multiline taking a string parameter - and fails because of the line-breaked string literal. That "multiline(...)' example was just the first thing that came into my mind. I just wanted to show something easier to recognize than these three quotes. 1 hour ago, Uwe Raabe said: This makes tweaking the parser not too complicated, as the start and end tokens are easy to recognize. Unfortunately the parser is quite complicated as it is now (I wouldn't have written it that way, but I also don't want to take the time to rewrite from scratch), so I wouldn't bet on the tweak being not too complicated. We'll see. Share this post Link to post
Uwe Raabe 2057 Posted September 19, 2023 18 minutes ago, dummzeuch said: Unfortunately the parser is quite complicated as it is now If the parser is too complicated by itself, it probably doesn't matter which syntax change is actually chosen. 1 Share this post Link to post
Sherlock 663 Posted September 19, 2023 17 minutes ago, dummzeuch said: (I wouldn't have written it that way, but I also don't want to take the time to rewrite from scratch) Surprisingly (or not), this argument leads to spending more time with legacy code over time than rewriting from scratch. At least that has been my observation for the past 20 years. Share this post Link to post
Lajos Juhász 293 Posted September 19, 2023 In my opinion it would be better to use: blub:= "line1 line2, indented line3 ; Share this post Link to post
Attila Kovacs 629 Posted September 19, 2023 Speaking of code formatter, we need a flag in the built-in formatter to be able to exclude parts of the code formatting. Share this post Link to post
Uwe Raabe 2057 Posted September 19, 2023 4 minutes ago, Lajos Juhász said: In my opinion it would be better to use: blub:= "line1 line2, indented line3 ; What if you want a line with a single semi-colon inside the string literal? With the current implementation your example would be written this way: blub := ''' line1 line2, indented 3 spaces line3 '''; // the ending triple quotes are aligned with the no-indentation position Some background for this discussion: Raw string literal 1 Share this post Link to post
Attila Kovacs 629 Posted September 19, 2023 8 minutes ago, Uwe Raabe said: With the current implementation your example would be written this way: Will this throw an error then? blub := ''' line1 line2, indented 3 spaces line3 '''; Share this post Link to post
Lajos Juhász 293 Posted September 19, 2023 1 minute ago, Attila Kovacs said: Will this throw an error then? I bet the beta testers cannot answer this question without violating the NDA. Earlier it was not allowed even to write about a fact that somebody is a beta tester. Share this post Link to post
Attila Kovacs 629 Posted September 19, 2023 1 minute ago, Lajos Juhász said: I bet the beta testers cannot answer this question without violating the NDA. Earlier it was not allowed even to write about a fact that somebody is a beta tester. My apologies. Another question. Would this throw an error in the dreams of a rainbw unicorn? blub := ''' line1 line2, indented 3 spaces line3 '''; Share this post Link to post
dummzeuch 1505 Posted September 19, 2023 1 hour ago, Sherlock said: Surprisingly (or not), this argument leads to spending more time with legacy code over time than rewriting from scratch. At least that has been my observation for the past 20 years. Yes, I know. But I also know that rewriting something from scratch takes a lot more time than one initially thinks. And may projects that start out as "This legacy code is cr*p, let's rewrite it" get cancelled due to time and budget overrun. Since my time is severely limited, I'm not going to rewrite that parser as long as it kind of works. And if it terminally breaks, I'm going to remove the code formatter for newer Delphi versions instead. There is a built in code formatter in the IDE after all, even though I don't really like it. Btw: I hope the built in code formatter was tested with multi line strings ... Share this post Link to post
dummzeuch 1505 Posted September 19, 2023 1 hour ago, Uwe Raabe said: If the parser is too complicated by itself, it probably doesn't matter which syntax change is actually chosen. It definitely does. Share this post Link to post