String literals more then 255 chars

[Uwe Raabe 2057]

28 minutes ago, Fr0sT.Brutal said:

Why the //s at the end?

Because they prohibit the formatter from concatenating the lines.

[Marco V 3]

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)

[emileverh 21]

They heard my voice ;-))

 

https://blogs.embarcadero.com/yukon-beta-blog-delphi-language-modernizing-string-literals/

[Vandrovnik 214]

7 minutes ago, emileverh said:

They heard my voice ;-))

 

https://blogs.embarcadero.com/yukon-beta-blog-delphi-language-modernizing-string-literals/

 

Multiline strings!

[dummzeuch 1505]

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

[Uwe Raabe 2057]

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.

[Kas Ob. 121]

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.

[Kas Ob. 121]

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.

[DelphiUdIT 176]

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.

[Anders Melander 1782]

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?

[Uwe Raabe 2057]

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.

[Uwe Raabe 2057]

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.

[Anders Melander 1782]

1 minute ago, Uwe Raabe said:

The docs contain more information than the blog post shows.

What docs?

[Uwe Raabe 2057]

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.

[dummzeuch 1505]

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.

[Uwe Raabe 2057]

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.

[Sherlock 663]

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.

[Lajos Juhász 293]

In my opinion it would be better to use:

 

blub:= "line1
   line2, indented
line3
;

[Attila Kovacs 629]

Speaking of code formatter, we need a flag in the built-in formatter to be able to exclude parts of the code formatting.

[Uwe Raabe 2057]

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

[Attila Kovacs 629]

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
    ''';

 

[Lajos Juhász 293]

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.

[Attila Kovacs 629]

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
    ''';

 

[dummzeuch 1505]

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

[dummzeuch 1505]

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.