String literals more then 255 chars

[Stefan Glienke 1905]

2 hours ago, Anders Melander said:

how does one differentiate between preserve or trim leading white space and preserve or ignore newline?

The closing quotes dictate the alignment, lines inside the string thus cannot be more left than the closing quotes, the last line does not have a trailing line break, if you want a trailing line break, add an empty line

[Uwe Raabe 1890]

18 minutes ago, Stefan Glienke said:

The closing quotes dictate the alignment

BTW, I like the fact that it is the closing quotes instead of the starting one. Imagine you need to adjust the indentation of the whole literal just because you decide to change the name from blub to something with not the same length.

[Anders Melander 1639]

33 minutes ago, Stefan Glienke said:

The closing quotes dictate the alignment, lines inside the string thus cannot be more left than the closing quotes, the last line does not have a trailing line break, if you want a trailing line break, add an empty line

By Ignore newline I meant from this:

  Lorem

  ipsum

  dolor

produce this:

  lorem ipsum dolor

[Stefan Glienke 1905]

A multiline string is multiline - simple as that.

[timfrost 73]

2 hours ago, dummzeuch said:

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.

Could you not just have an option to leave things the way they are, and still support Yukon?  For people like me, long time users of GExperts formatter, who find it an  absolutely essential tool and who will have no problem in resolving never to use a triple quote for its new purpose.

[Remy Lebeau 1260]

7 hours ago, dummzeuch said:

Not quite the implementation I would have liked though. Triple quotes '''? Who came up with that? Is that copyied from another programming language?

Influenced by C# (like several features in Delphi have been):

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-11.0/raw-string-literal

Edited September 19, 2023 by Remy Lebeau

[Brandon Staggs 185]

4 hours ago, dummzeuch said:

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.

I immediately understood the new syntax at first glance. The syntax you proposed looked like broken code. Honestly I doubt there is any possible solution to this that would not cause someone to complain, but I am glad they didn't decide to override the function call syntax for this.

 

Personally I am glad we are finally able to move beyond the 255 character limit and have a viable option for pasting in multiline content to be used as a string literal.

[dummzeuch 1392]

25 minutes ago, timfrost said:

Could you not just have an option to leave things the way they are, and still support Yukon?  For people like me, long time users of GExperts formatter, who find it an  absolutely essential tool and who will have no problem in resolving never to use a triple quote for its new purpose.

I wasn't talking about Yukon. I can live with the formatter not supporting multi line strings, if (!) it turns out the change is too complicated. But these not supported language features add up over time and once they reach a certain threshold it simply doesn't make much sense use the GExperts. In an ideal world I or somebody else would start implementing support for new language features during the beta phase. But I'm not participating in the Beta and of some other Beta tester has made those adaptions, I don't know about it (he wouldn't be allowed to tell me).

Btw. you could still use that feature, simply enclose those constructs in {(*} and {*)} so the formatter will leave that code alone.

[Uwe Raabe 1890]

@dummzeuch I haven't had a look at it for quite some time, but is the formatter free/open source or are there any restrictions to it?

[Joseph MItzen 243]

9 hours ago, Remy Lebeau said:

Influenced by C# (like several features in Delphi have been):

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-11.0/raw-string-literal

Quite possibly. But triple quotes for multiline strings are also in Python. Python gained multiline strings with triple quotes in 2001.

 

[Joseph MItzen 243]

12 hours ago, Stefan Glienke said:

The closing quotes dictate the alignment, lines inside the string thus cannot be more left than the closing quotes, the last line does not have a trailing line break, if you want a trailing line break, add an empty line

Now the next step is to get escape characters like \n for a line break!

 

[Darian Miller 336]

15 hours ago, Uwe Raabe said:

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.

I don't buy that it is 'always the case'.  The way to avoid that is to develop the IDE support with the new language feature at the same time so they are released at the same time.  The IDE is obviously there to assist the user with the language - if the language outpaces the IDE, then the user cannot properly utilize the IDE.  It is a self-defeating scenario.  And when the IDE support is many years behind language features it also becomes a real credibility problem.  

There can be some excuse to release experimental language features without full IDE support - but the gap between language feature release and IDE support should not be measured in 5 to 10 year spans (unless it is a special/edge case that hardly anyone utilizes.)
 

 

[dummzeuch 1392]

9 hours ago, Uwe Raabe said:

@dummzeuch I haven't had a look at it for quite some time, but is the formatter free/open source or are there any restrictions to it?

It has been donated by its original author to the GExperts project, so it has the same license as GExperts itself. The source code is part of the GExperts sources, but lives in a subdirectory of its own with few dependencies to any outside code.

[dummzeuch 1392]

2 hours ago, Darian Miller said:

I don't buy that it is 'always the case'.  The way to avoid that is to develop the IDE support with the new language feature at the same time so they are released at the same time.  The IDE is obviously there to assist the user with the language - if the language outpaces the IDE, then the user cannot properly utilize the IDE.  It is a self-defeating scenario.  And when the IDE support is many years behind language features it also becomes a real credibility problem.  

You are missing the point. We are not talking about missing/incomplete/buggy IDE features here (or at least I am not) but the pain in the lower back any new language features poses for third party tools that parse the source code, in particular the GExperts sources formatter, where the code isn't really well structured.

Edited September 20, 2023 by dummzeuch

[Uwe Raabe 1890]

1 hour ago, dummzeuch said:

the pain in the lower back any new language features poses for third party tools that parse the source code

That is exactly my own experience with MMX. When I took over the project it already was way behind the current language and it needs quite some time to catch up.

 

4 hours ago, Darian Miller said:

to develop the IDE support with the new language feature at the same time so they are released

While that may be possible for the IDE itself, as the owner has at least some control over the release date, this fails completely for 3rd party tools even if their maintainers participate in the beta (at least everyone willing can opt for that). A lot of enhancements are not ready early in the beta and often changed in between due to the ongoing discussion. Usually there is only a small time left before release where a feature is stable enough to support it in ones tool. Unfortunately the effort to design and implement that while staying compatible with older Delphi versions needs way more time as is left.

[Darian Miller 336]

10 hours ago, dummzeuch said:

You are missing the point. We are not talking about missing/incomplete/buggy IDE features here (or at least I am not) but the pain in the lower back any new language features poses for third party tools that parse the source code, in particular the GExperts sources formatter, where the code isn't really well structured.

Yes, I was referring to IDE, not 3rd party components.  

 

3rd party parsing of Delphi code may be improved with an official language definition perhaps.

[Rollo62 502]

On 9/19/2023 at 5:33 PM, Stefan Glienke said:

A multiline string is multiline - simple as that.

Then I would suggest to introduce 4 quotes, for this case when you want including CrLf: 

LStr  = ''''
            A one
            A two
            A three
            A four
        '''';

I wonder at how many quotes this might end ( Default-No-line-feed = 3 quotes, CrLf = 4 quotes, Lf = 5 quotes, Cr = 6 quotes, any chinese Lf = 7 quotes, .... ) 🤔

This syntax definition might go on until 64-Bit ends.

[Uwe Raabe 1890]

On 9/19/2023 at 5:14 PM, Anders Melander said:

By Ignore newline I meant from this:

  Lorem

  ipsum

  dolor

produce this:

  lorem ipsum dolor

There already exists a syntax to achieve this:

const
  blub = 'Lorem' +
         ' ipsum' +
         ' dolor';

 

[Anders Melander 1639]

56 minutes ago, Uwe Raabe said:

There already exists a syntax to achieve this:

const
  blub = 'Lorem' +
         ' ipsum' +
         ' dolor';

 

I can't tell if this was an attempt at humor because that's exactly the syntax I want to avoid.

[Uwe Raabe 1890]

55 minutes ago, Anders Melander said:

that's exactly the syntax I want to avoid

I have difficulties to understand your intention here. Why would you want to enter a multiline string literal to declare a single line string literal? The whole purpose of the new multiline string literal is to get line breaks into a string literal. There is no need to have line breaks when they are later ignored anyway.

[Anders Melander 1639]

33 minutes ago, Uwe Raabe said:

There is no need to have line breaks when they are later ignored anyway.

So you don't format your source code with line breaks? - Because the Delphi compiler will ignore them anyway.

 

It's not something I often do, but once in a blue moon I need to have a largish block of text in the source and that's just the way it is. Let's assume that there are reasons for this and that I know what I'm doing.

[Rollo62 502]

9 hours ago, Anders Melander said:

It's not something I often do, but once in a blue moon I need to have a largish block of text in the source and that's just the way it is. Let's assume that there are reasons for this and that I know what I'm doing.

and like, said, if you want "line" breaks, you should be able to define what kindof ( None, Space, CrLf, Lf, Cr, ...).

I don't care much about the ugliness of the ''' approach, but would like to see a bit more flexibility here, to define how it shall behave.

 

Maybe as proposal, this would limit the ugliness to an acceptable level:

LStr  = '''  //Default TBD
            A one
            A two
            A three
            A four
        ''';

LStr  = '''( TMultiLine.Crlf )    // Specific, maybe TMultiLine.None, TMultiLine.Space, TMultiLine.Crlf, TMultiLine.Cr, TMultiLine.lf, TMultiLine.SystemLineBreak
            A one
            A two
            A three
            A four
        ''';
        
LStr  = '''( TMultiLine.Custom, #0#1#2 )    // or even custom specification
            A one
            A two
            A three
            A four
        ''';

And how about the desired behavior of leading spaces ?? Another universe.

 

And how about the desired behavior of leading / trailing separators ??

 

And how about codepage conversion, oh my ??

 

The whole thing could be a kind of text processor IMHO, maybe like RegEx, to avoid the necessity for later re-structuring.

The whole sense is to paste in a format at design time from any source format, which is immediately compiled into the final output.
While at runtime you got it handed in the format and structure you intended to have, no more copy or format needed.

That would be on my whishlist.

 

Edited September 21, 2023 by Rollo62

[Kas Ob. 91]

Few days ago i was ..well digging in the Delphi XE8 compiler refreshing my memories from Delphi 2010, i was was looking for how to find a way to enforce the compiler to resolve intrinsic function, why Addr(SetString) is resolved handled fine by the parser to @LStrFromPChar but refuse to compile it, but if you tried to use System.@LStrFromPChar in assembly block it will compile fine, meaning the compiler differ to specific parsing code to keep Pascal code intact introducing assembler parser BASM.

 

Anyway, Delphi compiler is a big loop parser forward, but it will switch to different loop inside asm..end block, where semicolon is not needed or not obligatory and can handle instructions in different way, this simplify the code greatly and keep the speed of compilation intact for Pascal code, so if such multiline string format introduced everywhere then it might not be hindering the speed per se, but it will be the last !, no more string evolution forever, as any adjusting in the future will be the most ugly format and inconsistent has been existed.

 

As Rollo62 pointed for the codepage and the very needed line breaks, it would be great if you can paste python code or Java or whatever strings and keep it with minimum modification as you found it, a bash script for Linux that doesn't need /r/n or just paste it as you found it, i really want to use both very long string like a whole X.509 base64 Encoded certificate with outline break but over multiline, also want to have to put Pascal script in whole in its readable format over multiline reserving line breaker CRLF. 

 

For that the above i suggested to move and restrict such implementation to defined block, as example we can have CppString (block just like resourcestring) that behave like C++11 with all its features, specially that the CBuilder already have the needed parser and it is working fine.

By limiting such new string extension to well defined block(s), any number of strings format can be added in the future if not now, we can have multiline strings where new line can be new line is in source code as it or by /n, you can copy the lets paths from MSDN where the slash is double \\ without the need to adjust it to comply with Pascal, well in specific place of course.

[Attila Kovacs 617]

3 minutes ago, Kas Ob. said:

As Rollo62 pointed for the codepage and the very needed line breaks, it would be great if you can paste python code or Java or whatever strings and keep it with minimum modification as you found it, a bash script for Linux that doesn't need /r/n or just paste it as you found it, i really want to use both very long string like a whole X.509 base64 Encoded certificate with outline break but over multiline, also want to have to put Pascal script in whole in its readable format over multiline reserving line breaker CRLF. 

I don't think the intention of these blocks is to put every piece of trash you can find into them. I'm laughing my pants off at your suggestion to support multiple encodings and line endings in one text file. It's already pretty strange, and I'm sure it would have never happened if C# didn't implement it first. I'm still skeptical that they didn't do it on April 1st.

[Kas Ob. 91]

33 minutes ago, Attila Kovacs said:

I'm laughing my pants off at your suggestion to support multiple encodings and line endings in one text file.

I think you missed mu codepage point, yes we can't use multi encoding in one text file, but we can control the compiler to handle the encoding as literal in the generated binary, if i want a ansistring Chinese with multiline without CRLF or with CRLF or simple one long string, followied by long Uniocde text, then the compiler will have no problem and it will be doable, instead of using resource files, also remembered the resource file rc, https://learn.microsoft.com/en-us/windows/win32/menurc/stringtable-resource 

Is that a multi encoding in one text file ?