1. Can we say that X and Y from above have identical content?
2. Can we say that if we compile on Windows then line endings would be CRLF and if we cross compile to Linux then it will be LF?
3. Could you explain {$MultiLineStringLineEnding RAW}?
4. What about {$MultiLineStringTrim 99} to trim 99 spaces from both left and right? And {$MultiLineStringTrimRight 99}?
Its ugly ...
What if I wanted to create a constant with multiple words in it and like columnize them?
Const = '
One [options ]
Two [options ]
three
Four
Ect'
Maybe you could suggest for the IDE/Editor code tools to have a popup option that would generate the v
visible line endings for you ?
I would go for that but please , this isn't a single line language!
I find it very strange and disturbing that a source file going through some version control system can change content of it's multi line strings based on line ending changes in it self. Pretty unexpected and confusing. I would rather have {$MultiLineStringLineEnding PLATFORM} as a default setting, and {$MultiLineStringLineEnding RAW} as optional. I also find word RAW not intuitive enough in this case. SOURCE sounds a little better to me.3. Could you explain {$MultiLineStringLineEnding RAW}?...
This is the least intrusive approach, and also what people would usually expect and want I believe, and thus I made it the default setting.
You do as you please,. I'll never ever ever enable that feature if that is, it ever gets considered...
If such a feature is hard coded I'll leave fpc and spend the money for the latest Delphi, even though its
expensive. I need something that actually produces exactly what I tell it to in any manner I select of editing
style..
Like I said, if you have that much ambition there are much better ideas to implement in the compiler...
and one at the top of my list is Anonymous Records within Record defines.
I find it very strange and disturbing that a source file going through some version control system can change content of it's multi line strings based on line ending changes in it self. Pretty unexpected and confusing.
I also find awkward to have something like {$MultiLineStringTrim 99} in many of my sources, when I actually want something like {$MultiLineStringTrimAll} since {$MultiLineStringTrim} is already occupied for completely different use. I would then expect {$MultiLineStringTrimAll} to be default setting, which does not seam to be the case.
I also find awkward to have something like {$MultiLineStringTrim 99} in many of my sources, when I actually want something like {$MultiLineStringTrimAll} since {$MultiLineStringTrim} is already occupied for completely different use. I would then expect {$MultiLineStringTrimAll} to be default setting, which does not seam to be the case.
What you seem to want here could be solved by having a directive or command-line option that worked globally instead of locally, I think, which is certainly possible.
I find it very strange and disturbing that a source file going through some version control system can change content of it's multi line strings based on line ending changes in it self. Pretty unexpected and confusing.
This is literally how single-line strings work currently, though. The compiler just uses whatever is actually present when reading them.
Most editors show expected code layout no matter what line endings are in the code, and no matter what platform you're on. They handle it properly and do not force you to do a conversion. Therefore I do not mind if GIT/SVN/CVS change line endings in my sources since currently it can not affect output of my code. However with {$MultiLineStringEnding RAW} as default, it is easy to overlook that my code might have strings that have line endings not compatible with target platform and therefore produce unexpected and wrong result. That is the reason why I see {$MultiLineStringEnding PLATFORM} much more appropriate as default. And GIT/SVN/CVS are not the only ones who can change line endings in the source. Let's say I give source of some program to someone who opens just one file in an editor that tries to be smart and changes line endings on saving. After that user compiles my program but program does not work properly. Can you see how much of a problem that can be? Do I have to start making notes what are line endings in my sources? Do I have to put {$MultiLineStringEnding PLATFORM} in all files just because anyone can accidentally change line endings in my sources and by doing that make output of my program completely different?I find it very strange and disturbing that a source file going through some version control system can change content of it's multi line strings based on line ending changes in it self. Pretty unexpected and confusing.This is literally how single-line strings work currently, though. The compiler just uses whatever is actually present when reading them. It's also how text and textfiles in general work, in all cases...
Perhaps {$MultiLineStringTrim}, without parameter, should be made to mean "Trim All"?{$MultiLineStringTrim All} sounds ok.
Maybe not the best implementation
Can you see how much of a problem that can be? Do I have to start making notes what are line endings in my sources? Do I have to put {$MultiLineStringEnding PLATFORM} in all files just because anyone can accidentally change line endings in my sources and by doing that make output of my program completely different?
I don't really like this feature (too many possible "unexpected" behaviours) but I see why someone may want to use it.
Maybe not the best implementation
I'm happy to hear any suggestions you might have!
As I posted in the link, I think multilines string could be:
s='hello world'
I've attached an image (that I also posted earlier) of what it looks like with a patched version of SynEdit in Lazarus.
What do you see as unexpected, exactly? You type in text. The compiler reads the text. The end. It's a very, very, simple feature.
After all it's almost only a "want-to type-less" feature.Personally, I think it's not even "almost", that's exactly what it is.
Akira, thank you for working on this feature.
I saw a problem. It could be the way I applied the patch, as I was eager to test it so I was not careful enough. So just in case, this code:
program example; {$modeswitch MultiLineStrings} {$MultiLineStringTrimLeft 5} const Test = `ThisSpace>>>> <<<<diappeared`; begin Write(Test); end.
Removed the space in the middle and gave me:
ThisSpace>>>><<<<diappeared
Do you get the same result?
Most likely the editor in the options list is setup to remove the trailing spaces, so basically it broke the
string up and there you...
I am not fond of the need to have a new token in the language (presumably "(#") and, I like even less the need to have directives to control the trimming of the strings. Most, if not all the savings in typing, go out the window with those directives.
I like even less the need to have directives to control the trimming of the strings
Most likely the editor in the options list is setup to remove the trailing spaces, so basically it broke the
string up and there you...
Where are you getting the pound sign from? The syntax is exactly what's written in my example.I admit to having lost track of how you've implemented the feature. At the time I wrote that, I was thinking about the discussion in FPC-devel which used "(##" (if I'm not mistaken again.)
I personally don't even think there is a need so to speak. I added that because people seemed to really be concerned about maintaining "pretty" indentation while not having spaces actually appear in the string when displayed / written to file / e.t.c. at runtime.I understand. The one thing that concerns me, if I've understood the description correctly, is that with that construct, there is no way to have fixed-length multi-line strings. I think the ability of having fixed-length multi-line strings should not be lost (it can be done using current syntax but, obviously more typing and more clutter but, it's there, it's available if you need it.)
Akira, thank you for working on this feature.
I saw a problem. It could be the way I applied the patch, as I was eager to test it so I was not careful enough. So just in case, this code:
program example; {$modeswitch MultiLineStrings} {$MultiLineStringTrimLeft 5} const Test = `ThisSpace>>>> <<<<diappeared`; begin Write(Test); end.
Removed the space in the middle and gave me:
ThisSpace>>>><<<<diappeared
Do you get the same result?
Oh no! That is in fact a bug. Looking at my FPC-test-suite tests now, that particular manner of "single-line-like" use seems to be the one thing I overlooked, syntactically speaking. I will fix that literally right now. Thanks for the report, and for testing!
I admit to having lost track of how you've implemented the feature. At the time I wrote that, I was thinking about the discussion in FPC-devel which used "(##" (if I'm not mistaken again.)
I understand. The one thing that concerns me, if I've understood the description correctly, is that with that construct, there is no way to have fixed-length multi-line strings. I think the ability of having fixed-length multi-line strings should not be lost (it can be done using current syntax but, obviously more typing and more clutter but, it's there, it's available if you need it.)
That was quick, thank you!!
I think I hit another bug. It doubles the line ending.
Are you saying that people using GIT or SVN is an overstated scenario? I do not expect compiler to babysit my strings, I expect it to be in line with current behavior. Current behavior is that if you have String1 in SomeStringList and add String2 to SomeStringList, then SomeStringList will have different line endings in Windows and Linux, and SomeStringList will be printable on both without any changes. I expect the same behavior form this new feature, and anything else is in collision with what are we used to. Otherwise we will have a code that might produce unusable strings on some platforms unless we tell it explicitly to the compiler that we don't want that. And it doesn't matter if we have to put a project wide switch or unit wide switch. Both are bad.Can you see how much of a problem that can be? Do I have to start making notes what are line endings in my sources? Do I have to put {$MultiLineStringEnding PLATFORM} in all files just because anyone can accidentally change line endings in my sources and by doing that make output of my program completely different?I think you're vastly overstating the amount of scenarios where this would be a problem, and also expecting the compiler to essentially babysit your revision control configuration. The compiler directives are directives. Use them as you wish, like you would any existing directive.
Here is a thought, it's a small variation on the concept Akira has presented, using current Pascal syntax:This would mean that the parser would need to handle new lines which it currently is totally ignorant of. The multiline string implemented by Akira1364 is solely implemented inside the scanner which is already dealing with lines and such. Thus your idea is much more intrusive for the compiler and thus harder to maintain in the long run and thus much less likely to get accepted than Akira1364's idea.
const s = 'hello ' + 'world' ; // would print "hello world" (just as it does now.) {$LINEBREAKS ON} b = 'hello' + 'world' ; // would print (imagine "// " is the beginning of the line) // hello // world
{$LINEBREAKS would be active ONLY for 1 string, the very next one, to prevent having unintended line breaks in other strings. I think this is a feature that is used rarely enough that having to type {$LINEBREAKS ON} for each one of them is within reason.
Basically, teach a new "trick" to the "+" pony.
No you didn't miss understand me, I screwed that one up, I guess the editor in your case makesYou are aware that the feature replaces more than just the +?
no difference but control characters and UTF8 need to be tested.
For me all this is going to do is remove the use of the '+ at the end of the line.
that is all I'll ever use it for.
The problem here is that allowing multi lines for strings building is great, most editors allow it and most
compilers allow it but I don't like the idea of it changing the content of the string I specify..
Changing the content means removing left spaces, inserting CR etc... that isn't ideal..
Having PLATFORM as the default would be much less expected IMO, and likely frustrating for anyone who did not want the compiler to impose a certain line ending that may have been not what was actually written.Considering that the idea is to replace StrConst = 'Foo' + sLineBreak + 'Bar' making PLATFORM the default might indeed be the most sensible approach.
Considering that the idea is to replace StrConst = 'Foo' + sLineBreak + 'Bar' making PLATFORM the default might indeed be the most sensible approach.
Do I understand correctly that this then wouldn't be trimmed at all, because the first line doesn't have any spaces?
I think I hit another bug. It doubles the line ending.
I get your expected results with an LF encoded file, but not with a CRLF one. Let me take a closer look at what's going on there. Thanks for really digging in to the testing!
I'm fairly confident that I know what the best way to remedy this is, but I might not have a chance to do so until later today (am at work right now, haha.) As soon as I can though, I'll fix it, push the changes to github, and upload another new pair of patches.Take your time. I am sure you can find the best way to correct it. Thank you for putting all that effort into this nice feature.
This would mean that the parser would need to handle new lines which it currently is totally ignorant of. The multiline string implemented by Akira1364 is solely implemented inside the scanner which is already dealing with lines and such. Thus your idea is much more intrusive for the compiler and thus harder to maintain in the long run and thus much less likely to get accepted than Akira1364's idea.First, most important, you may very well be right since I have not spent any real amount of time analyzing the ways the feature can be implemented.
You can't solve bad programming with a compiler switch.That's true but, this feature isn't about solving a "bad programming" problem.
For once Thaddy actually said something that I can agree with..When that happens, the probability of being wrong is infinitesimally close to being 1.
I would gladly use something like :would be interpreted by the scanner as :
const Str2 = `SELECT o.*, C.Company from Orders O join Customer C on o.CustNo=C.ID where O.saledate=DATE '2001.03.20'`; or const Str2 = `SELECT o.*, C.Company from Orders O join Customer C on o.CustNo=C.ID where O.saledate=DATE '2001.03.20'`;
Str2 = 'SELECT o.*, C.Company' + LineEnding + 'from Orders O' + LineEnding + 'join Customer C' + LineEnding + ' on o.CustNo=C.ID' + LineEnding + 'where' + LineEnding + ' O.saledate=DATE ''2001.03.20''';
I like the idea, didn't read all the opinions btw.
Also I like the backtick usage, is like is done in JavaScript for example.
Keep going and get it bug free in time. :)
Multi lines is a great idea for the compiler to read but I want it to assemble exactly what it see's …Where did you get this idea from? This feature does *not* affect any strings in your old source code, and will not change strings in your new source code. Moreover, it is turned off by default. To turn it on, you need to use {$modeswitch MultiLineStrings}. Even then, it will *not* change the strings that you already have.
Akira's syntaxYou don't need to escape the apostrophe if used in between two backticks. But you do need to escape the backtick if you need it in this text:
const HelpText = `I''m not sure if it is even possible to have such a long line. This is some example text like it may look like in a help text. There is no content here, you don''t need to go on reading. Just a string that doesn''t fit into one line. Now this is a new line.`;
BUT, in the cases a singleline is not enough for me, I often don't want a line break to be inserted.
So this new syntax wouldn't cover my cases.
Several people have mentioned wanting a "no newlines at all" option for {$MultiLineStringLineEnding} (which would mean whatever is written would be interpreted as one long horizontal string), which would not be difficult to add, and so I may very well do so. The option would most likely be called NONE, I think.
Doesn't that quite defeates the whole purpose of this feature? An it can already be done very easily:
MyString = 'This, of course, will appear all' + ' in the same line (provided your' + ' terminal is wide enaough)';
Do people really find that sintax so unuseable that they need another?
This is pure curiosity...
why the backtick (which is slightly awkward to reach on the keyboard) and not simply a double quote ? (which is really easy to reach)
The only reason I can see for not choosing the double quote is that it could potentially be a source of confusion for programmers migrating from another language.
This is pure curiosity...
why the backtick (which is slightly awkward to reach on the keyboard) and not simply a double quote ? (which is really easy to reach)
I just press a single key both on windows and mac, english and spanish keyboard as well.
Michael proposed it (https://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg38347.html).Thanks. The rational for it, know that I know it, seems quite reasonable.
<snip>
Probably escaping double quote would be more frequent if it were to be used instead of backtick:
Sample = """It is unfair"" he said.";
Doesn't that quite defeates the whole purpose of this feature?
Also, " is already known in the (Pascal) programming universe as a string delimiter of strings containing escaped characters. (E. g. the GNU Pascal compiler allowed that.)Michael proposed it (https://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg38347.html).Thanks. The rational for it, know that I know it, seems quite reasonable.
<snip>
Probably escaping double quote would be more frequent if it were to be used instead of backtick:
Sample = """It is unfair"" he said.";
That works just as you've written it already, BTW:Maybe a {$MultiLineStringTrimLeft auto} would be convenient. It would decide, based on the position of the first backtick, what is the count of character to consider in the {$MultiLineStringTrimLeft n_characters}. It could also check that there aren't any characters under/left of the initial backtick.
Ah, then it's not what I expected, but what I hoped for. ;)Do I understand correctly that this then wouldn't be trimmed at all, because the first line doesn't have any spaces?
You do not I'm afraid. It is trimmed like you'd expect (so, in that case, completely trimmed such that there is no leading space left anywhere.)
I.E. it would look like this if displayed with WriteLn:
A B C D
That works just as you've written it already, BTW:Looking at this I wonder if some {$MultiLineStringTrimLeft Auto} would be useful, so that it would simply automatically trim both statements to look the same...
program SQL; {$modeswitch MultiLineStrings} {$MultiLineStringTrimLeft 10} const Str1 = `SELECT o.*, C.Company from Orders O join Customer C on o.CustNo=C.ID where O.saledate=DATE '2001.03.20'`; {$MultiLineStringTrimLeft 5} const Str2 = `SELECT o.*, C.Company from Orders O join Customer C on o.CustNo=C.ID where O.saledate=DATE '2001.03.20'`; begin WriteLn(Str1); WriteLn(Str2); end.
That said, the idea behind {$LINEBREAKS ON} is to direct the scanner to a new routine that handles multiline strings. What Akira triggers with a ` (backtick), I would trigger with a directive. Just as simple, just a different path to getting to the same place.No, it's definitely not that simple, because the + operator could be overloaded and as I said all the operator stuff is handled inside the parser not inside the scanner where strings are handled.
At least at first blush, there doesn't seem to be anything preventing such an implementation and it would not require adding new elements (such as the backtick) to the language.
I still don’t understand, why we just don’t introduce a new compiler switch, that’ll eliminate theYeah, sure, a string line with a length of thousands of characters is soo much easier to read... ::)error. No need for new syntax and achieved our goal with minimal efforts.
Fatal: String exceeds line
No, it's definitely not that simple, because the + operator could be overloaded and as I said all the operator stuff is handled inside the parser not inside the scanner where strings are handled.You're right. I didn't think about the fact that the "+" operator might be overloaded which forces the processing of the construct to be done by the parser.
Looking at this I wonder if some {$MultiLineStringTrimLeft Auto} would be useful, so that it would simply automatically trim both statements to look the same...
I'm unsure if there is precedent in the compiler for directives that take both numeric values and "string" values, such as would be the case here, however.Take a look at for example dir_align.
Apart from that, do you have any particular thoughts on my implementation as it exists so far? E.G, is there anything that stands out to you as obviously "wrong" / e.t.c? Very interested in any input at all I can get on this to make sure it's as useful as possible in the long run.Sorry, I've been too busy with the reintegration of attributes, so I haven't looked at your patch. Maybe I'll find the time tomorrow, but no promises!
Take a look at for example dir_align.
Sorry, I've been too busy with the reintegration of attributes, so I haven't looked at your patch. Maybe I'll find the time tomorrow, but no promises!
test the feature, and report any other bugs you might find! (Which of course is hopefully few, or even better none, haha.)Finding a bug is much harder now, but I did manage to find one more, probably this is the last one.
When left-side trimming is enabled, and a string starts with anything but a backtick, it should not trim. Here are a few examples:
Doesn't that quite defeates the whole purpose of this feature? An it can already be done very easily:
MyString = 'This, of course, will appear all' + ' in the same line (provided your' + ' terminal is wide enaough)';
Do people really find that sintax so unuseable that they need another?
I already have an editing tool that will build that for me, I just paste it in afterwards.
I can think of something else to be using this valuable time on for compiler enhancements.
I third it …!I hear you.
I already have an editing tool that will build that for me, I just paste it in afterwards.Why not make it part of Lazarus?
The tool even reads it back for re-editing..
And this is a HUGE advantage if you write SQL/HTML/JS/LUA/..etc inside your code.
The only thing I can see that maybe an advantage is for the compiler to carry to the next line looking
for the closing " ' ".
Not sure what you mean here. This is even simpler, as you do not need to escape apostrophe. Simple test:
But I can see that getting complicated with the ability of inserting quotes etc..
You make it sound like everyone is working on this feature, this is not the case. Here is a list of new features:
I can think of something else to be using this valuable time on for compiler enhancements.
Yes, but the discussion to replace this syntax with backtick-strings only came later. The feature that is really talked about would replace this:Second. This syntax is simple and readable.
Doesn't that quite defeates the whole purpose of this feature? An it can already be done very easily:
MyString = 'This, of course, will appear all' + ' in the same line (provided your' + ' terminal is wide enaough)';
Do people really find that sintax so unuseable that they need another?
Also keep in mind that Akira1364 is an independant developer who's not a core developer (I'm not trying to belittle his contribution, just to clear up his relationship with the core team to avoid any misunderstandings)You make it sound like everyone is working on this feature, this is not the case. Here is a list of new features:
I can think of something else to be using this valuable time on for compiler enhancements.
https://wiki.freepascal.org/FPC_New_Features_Trunk
Akira spent more time arguing with people than coding. He coded it amazingly in a very short time, and bugs are fixed very quickly.
Yes, but the discussion to replace this syntax with backtick-strings only came later. The feature that is really talked about would replace this:A string operator could be introduced that combines the "+ sLineBreak +" for example using the "/":
MyString = 'This, of course, will appear all' + sLineBreak + ' in the same line (provided your' + sLineBreak + ' terminal is wide enaough)';
Several people have mentioned wanting a "no newlines at all" option for {$MultiLineStringLineEnding} (which would mean whatever is written would be interpreted as one long horizontal string), which would not be difficult to add, and so I may very well do so. The option would most likely be called NONE, I think.In case of trimming a space would have to be inserted for each new line.
{$MultiLineString[...]}I would suppose not to use too many mode switches, i.e. not to provide too many options. Trimming on or off should be enough.
AUTO, however, is based on the column position of the opening backtick of the current multi-line string in the source file, as some people had suggested would be what they'd want."
Having PLATFORM as the default would be much less expected IMO, and likely frustrating for anyone who did not want the compiler to impose a certain line ending that may have been not what was actually written.Considering that the idea is to replace StrConst = 'Foo' + sLineBreak + 'Bar' making PLATFORM the default might indeed be the most sensible approach.
Using PLATFORM as default seems logical to me.
Not a replacement for Akira's very nice work, but perhaps an option for some:
operator/ (const a, b: string): string; begin result := a + LineEnding + b; end; procedure TForm1.Button1Click(Sender: TObject); var s: string; begin s := 'Hello' / 'World'; Memo1.Append(s); end;
That works, but I would just... not recommend that you do it, ever. It's adding a non-trivial amount of runtime overhead to your application for no reason (as opposed to single-line or multi-line string concatenation with either the '+' operator or the actual Concat intrinsic function, which is always resolved entirely at compile time and results in a single constant string.)
Also, " is already known in the (Pascal) programming universe as a string delimiter of strings containing escaped characters. (E. g. the GNU Pascal compiler allowed that.)
Using PLATFORM as default seems logical to me.
This seems to be the consensus, or something close to one at least. Will probably change it over to PLATFORM sometime tonight.
I also plan to re-use the variable that tracks the column position of the opening backticks for AUTO to add a multi-line-string specific error, shown in the event that one is "unbalanced" or "unterminated", that tells you where exactly it started (as opposed to the more general syntax error you'd get in that case currently.) Probably the last real addition to the feature I'll do for the time being.Not a replacement for Akira's very nice work, but perhaps an option for some:
operator/ (const a, b: string): string; begin result := a + LineEnding + b; end; procedure TForm1.Button1Click(Sender: TObject); var s: string; begin s := 'Hello' / 'World'; Memo1.Append(s); end;
If I understood what you're proposing correctly, that is, use "/" (without quotes of course) to indicate a line continuation, that seems to have the same problem as using "+" for the same purpose. The possibility of overloading the operator would force the entire construction to be parsed instead of just scanned.
operator/ (const a, b: string): string; begin result := a + LineEnding + b; end; procedure TForm1.Button1Click(Sender: TObject); var s: string; begin s := 'Hello' / 'World'; Memo1.Append(s); end;
<snipped>
So you could slightly reconsider the syntax using kupferstecher / VTwin formulation.
If I understood what you're proposing correctly, that is, use "/" (without quotes of course) to indicate a line continuation, that seems to have the same problem as using "+" for the same purpose. The possibility of overloading the operator would force the entire construction to be parsed instead of just scanned.
Refer to post #34 by PascalDragon, in this thread, for a more complete explanation of the problems it would create.
This would mean that the parser would need to handle new lines which it currently is totally ignorant of.I understand that sentence that the problem is the Parser can't distinguish, if the tokenized "+" is at the end of a line which would result in a inserted linebreak or it is between two strings in the same line, which wouldn't result in a inserted linebreak. Making fpc able to distinguish both cases of course would be intrusive.
But with a new operator "/" this is not necessary.The problem is "/" is not a new operator, it is currently used to indicate division and it is legal, though it would look a bit strange, to define division between two strings. There is nothing stopping/preventing a programmer from doing that which would cause an ambiguity, i.e, is it a division or a line continuation ?.
But : we have only JEDI code formatter to salvage strangely indented code and this I need more than this new feature.
Now just a slightly more complicated SQL script straight out of a text file with the back tick idea, would it pass ?
I understand that sentence that the problem is the Parser can't distinguish, if the tokenized "+" is at the end of a line which would result in a inserted linebreak or it is between two strings in the same line, which wouldn't result in a inserted linebreak. Making fpc able to distinguish both cases of course would be intrusive.
But with a new operator "/" this is not necessary. The token "/" is just passed to the parser, the lexer perhaps may be even untouched (But I don't know). It's actually desirable that the parser deals with it, because then it also can treat string variables, not only source strings.
The result is a clean syntax without mode switches, different types of strings, trimming mechanisms etc.
The problem is "/" is not a new operator, it is currently used to indicate division and it is legal, though it would look a bit strange, to define division between two strings. There is nothing stopping/preventing a programmer from doing that which would cause an ambiguity, i.e, is it a division or a line continuation ?.The same holds for "+".
It doesn't really work like you think it does.I didn't assume any different. My comment was about the claim, that a "/" would be intrusive.
FPC uses exactly one completely context-free procedure (tscannerfile.readtoken) to do basically all reading of strings (whether they be initialized variables, or "true constants", or resourcestrings, or a standalone literal in a function call, and so on.)
This is why multiline strings "just work" everywhere single-line strings do: it boils down to doing exactly the same thing, except between two backticks instead of between two single-quotes, and without intentionally stopping when it hits a newline character.
A) The mode switch was laid out as an explicit requirement for this feature to ever be considered at all, by the core team.Well a mode switch for enabling a feature is one thing. I was talking about configuration mode switches: trim 5, trim auto...
B) This feature doesn't introduce a new type of string. It just enables the compiler to read strings the way it always has, but across multiple lines.New delimiters, new syntax. The syntax issue I guess is what BrunoK meant with "JEDI code formatter". Tools and syntax highlighters may stumble over the new syntax. (But thats evolution...)
C) IMO the "/" operator thing is just not really any better than the "+" we've always had, and provides none of the advantages that real unseparated multi-line string constants do.As said before, this doesn't contradict to your proposal, they could coexist.
D) At this point I simply have no intention of changing the core way the feature works, regardless.Thats clear. And I can understand that its not very motivating to get contra. But such implementations have an effect on all freepascal users, so it should be discussed.
Well a mode switch for enabling a feature is one thing. I was talking about configuration mode switches: trim 5, trim auto...
New delimiters, new syntax. The syntax issue I guess is what BrunoK meant with "JEDI code formatter". Tools and syntax highlighters may stumble over the new syntax. (But thats evolution...)
A freepascal programmer then has to learn both the standard strings and multiline strings.
As said before, this doesn't contradict to your proposal, they could coexist.
Thats clear. And I can understand that its not very motivating to get contra. But such implementations have an effect on all freepascal users, so it should be discussed.
- The RAW option for MultiLineStringLineEnding is now called SOURCE.Thank you.
- PLATFORM is now the default MultiLineStringLineEnding option.
- I've implemented the multi-line-string-specific error message that I mentioned in an earlier comment.
I was wondering if we really have to stick with the backtick, or we can keep the "old school" single quote instead?This was a requirement from the core team to even remotely consider this for inclusion. The normal strings stay untouched. Period.
Akira, just want to let you know. Not hearing from me, means I did not find another bug. :)
I gave it a try and it did not compile in 3.2.0
I gave it a try and it did not compile in 3.2.0 and it compiles in trunk. I used fpcupdeluxeThe first step after applying a patch is to check whether all changes applied cleanly. In this case you would have noticed that adding m_multiline_strings to the modeswitch enum failed. For a solution see Akira1364's remark about adding it manually.
I used fpcupdelux to build compiler I never build compiler myself. And patching happens there automatically.I gave it a try and it did not compile in 3.2.0 and it compiles in trunk. I used fpcupdeluxeThe first step after applying a patch is to check whether all changes applied cleanly. In this case you would have noticed that adding m_multiline_strings to the modeswitch enum failed. For a solution see Akira1364's remark about adding it manually.
Then this should be considered a bug in fpcupdeluxe if it starts building after applying the patch failed.I used fpcupdelux to build compiler I never build compiler myself. And patching happens there automatically.I gave it a try and it did not compile in 3.2.0 and it compiles in trunk. I used fpcupdeluxeThe first step after applying a patch is to check whether all changes applied cleanly. In this case you would have noticed that adding m_multiline_strings to the modeswitch enum failed. For a solution see Akira1364's remark about adding it manually.
I wonder if all latin keyboards even have this character.
I found that I actually have two very similar characters on my keyboard -- "`" (right-alt+7) and "´" (right-alt+9), which makes further confusion.
I wonder if all latin keyboards even have this character.It's an ASCII character (https://en.wikipedia.org/wiki/ASCII#Printable_characters) and thus it's very likely that all keyboards have it available somewhere.
The problem is "/" is not a new operator, it is currently used to indicate division and it is legal, though it would look a bit strange, to define division between two strings. There is nothing stopping/preventing a programmer from doing that which would cause an ambiguity, i.e, is it a division or a line continuation ?.The same holds for "+".
Because the "+" operator is already used, thus it's not far-fetched to use "/" as well.
What has "+" to do with strings? Well, it "adds" them together.
What has "/" to do with strings? It "devides" them to two lines.
Quite intuitive, I'd say.
Anyways, that was only a suggestion.
I am surprised that, no one noticed that there is an old Pascal feature which gets broken with introducing these multiline strings -- until now, in Pascal sources, all trailing spaces at the end of each line have always been insignificant.
Introducing these multiline strings breaks this rule.
Beside the different internationale keyboard layouts:
The backtick is eye powder! Not everyone has good eyes. Or a monster screen!
Winni
It's like, exactly the same size as the single-quote we've all been happily using for years (and will happily continue to use.)
Yes, but then we got two different types of fruit flies.
@Akira1364
Ok, I got your point of view. Accepted.
It's just about the eye powder.
I've got bad eyes and glasses. I know the problem to distinguish the back tick and the apostroph from a lot of working with the bash. If it's your own stuff then you can avoid the problem, but if it's system stuff or from other person, I really have always to look twice what kind of nothing that is.
So - I just wanted to avoid that problem. Nothing more.
Winni
It's an ASCII character (https://en.wikipedia.org/wiki/ASCII#Printable_characters) and thus it's very likely that all keyboards have it available somewhere.
I am surprised that, no one noticed that there is an old Pascal feature which gets broken with introducing these multiline strings -- until now, in Pascal sources, all trailing spaces at the end of each line have always been insignificant.
Introducing these multiline strings breaks this rule.
I'm sorry, but this makes no sense whatsoever. That is absolutely not an "old Pascal feature" or "rule" by any sense of the term (more like a random, insignificant detail that you're pointing out), nor is introducing multiline strings going to "break" anything.
Hah, really! I wouldn't expect this to be ascii.
Perhaps tilde ("~" -- also ASCII)?
I am very surprised that you don't see that syntax which allows trailing spaces affects readability of code. These spaces are literally invisible, so how readable that can be?
Readability is an important language feature.
Some different syntax which would require some (visible) character to mark the end-of-line and continuation on the next line would be much better way to implement this.
In Lazarus you can enable whitespace to be shown as most editors allow. It's also very useful to find out if a tab was smuggled in somewhere...
I am surprised that, no one noticed that there is an old Pascal feature which gets broken with introducing these multiline strings -- until now, in Pascal sources, all trailing spaces at the end of each line have always been insignificant.
Introducing these multiline strings breaks this rule.
I'm sorry, but this makes no sense whatsoever. That is absolutely not an "old Pascal feature" or "rule" by any sense of the term (more like a random, insignificant detail that you're pointing out), nor is introducing multiline strings going to "break" anything.
I am very surprised that you don't see that syntax which allows trailing spaces affects readability of code. These spaces are literally invisible, so how readable that can be?
Readability is an important language feature.
Some different syntax which would require some (visible) character to mark the end-of-line and continuation on the next line would be much better way to implement this.That would prohibit another purpose of this feature: to be able to copy some piece of code (e.g. some SQL script) and insert it without having to worry about adjusting it (aside from maybe escaping backticks, but that would be necessary with apostrophe as well).
There is literally no connection between multi-line strings and any hypothetical reason you would have cared in the slightest about "invisible spaces" in the first place (which is, none I can think of.) I don't understand why you think this is significant at all, let alone something that profoundly "affects readability".
if any one has issue they should avoid using it.
Of course, one could always answer;: "In those situations, use standard strings" :)
Hah, really! I wouldn't expect this to be ascii.
...What? Of course it is. Character number 96.
Perhaps tilde ("~" -- also ASCII)?
Oh, so I can waste even more time arguing with all of the Nitpick McGees out there who would definitely be very vocal with regards to complaining about how "weird" it looks to them or whatever? Yeah, no thanks.
Again, this is a moot point, now, anyways: I have literally zero intention of making that kind of fundamental change at this stage. It's not gonna happen. I've based my implementation around what was discussed (at length!) on the mailing list, and that's how at the very least the core of it is going to stay.
Do note also:
Once this functionality gets merged to FPC, I then intend to submit a patch I have for Lazarus SynEdit which makes it highlight multi-line strings much the way it does multi-line comments right now.
(Of course, I know not everyone uses Lazarus, but it's something.)
Akira, there is no need for this tone. I want to say what I think, that is all.
You are the one who took the effort to implement this, so from the moment I entered this topic, I have understood quite well that it is you and the core team who will decide what syntax will enter the language, it won't be me.
I hope you will also take care of "Trim trailing spaces" IDE option, which has always been safe to use with Pascal source, but now it will have to take care not to brake new style string literals.
Will both strings be the same?
And you have to recognize that the multiline string is much less readable
how many spaces are there?
- snip -
That IDE option does not need to change in any way at all. I don't understand why you think it would "break" multi-line strings.
This general idea that I've implemented the multi-line strings functionality in some fragile way full of "gotchas" that's ready to fall apart at any moment is rather annoying.
For example, I am 100% sure that if, for some reason, we were actually planning on using the tilde character to denote multiline strings, the amount of controversy around the whole thing would be an order of magnitude larger than it is now.
I would expect it to trim trailing spaces from the first line of two-line string literal.
I am sorry to annoy you. I just would really expect this IDE option to trim all trailing spaces from the source, even when they finish the line inside multiline string.
I would never say a small "gotcha" like this could lead the whole new feature to fall apart. ;)
I would expect it to trim trailing spaces from the first line of two-line string literal.
It does. Why wouldn't it?
My point was that this does not "break" the appearance of the multi-line string when displayed at runtime and is overall essentially irrelevant, because you can't actually visually tell if there are or are not trailing spaces in it regardless.You say when you display string on the screen, it does not matter if trailing spaces are cut off, it appears the same.
If you actually wanted trailing spaces, for some reason, as it stands now you would just turn that IDE option off, as has always been the case.If for some reason I actually want trailing spaces in the multiline string literal, I will surely not use the new style syntax. But someone will.
If for some reason I actually want trailing spaces in the multiline string literal, I will surely not use the new style syntax. But someone will.
And some day I will open some unit from some library written by someone -- a unit which has a new syntax string literal with trailing spaces, and the IDE will just change this string. I will open that unit to see some other code, some function far from that string, I will not be aware of the string existence.
And of course that could seriously affect the programme behaviour.
I think these feature is very nice.
if any one has issue they should avoid using it.
But we should encourage people who contributing to FPC development.
More contribution to FPC means much much better PROGRAMMING LANGUAGE/PLATFORM
it benefit to EVERYONE.
+1.if you feel I am being childish about this, I think you're in for a rude awaking. I am only posting what many others are thinking. I wasn't brought up to be politically correct just to appease those that would go against
the many to please a few.
If we are all not "being politically correct to please people" here, then I'm just going to straight up say that EVERYTHING you have said in this thread makes you sound like a fucking idiot. All of your comments are embarrassing, and anyone who agrees with you is equally stupid. You are NOT "the many".
People like you are DIRECTLY what causes FPC's slow, inevitable decline in popularity. It's the same fucking thing every fucking time anybody wants to introduce anything new: a bunch of illiterate morons spouting off conspiracy-theory nonsense about how the sky is falling, who are ALWAYS, ALWAYS, ALWAYS clearly wrong in hindsight. You can go wayyyyy back on the developer mailing list for FPC and find people who unironically argued against the introduction of for-in loops the same fucking way you're arguing against this strings feature, back in like 2006. I'm not kidding. For-in loops! How fucking insane does that sound now that they've been a normal part of the language for years? Very!
So yeah, for the love of god stop fucking driving away smart people who both want to improve FPC and can also actually do the work themselves, or sometime real soon there won't be anyone left working on it at all.
Came across another area today where I think multi-line strings would be quite helpful to a lot of people: writing tests!There is no doubt that the feature you're adding makes multiline strings significantly more readable and easier to insert in code.
Keep pascal as pascal.could you explain how this feature leads to not "keep pascal as pascal" ?
Pascal as itself don't have this multiline feature. But have mechanic to use multiline strings by standard way.Yes, multiline strings can be done in Pascal without the feature Akira is adding but, that doesn't mean that adding a mechanism that makes multiline strings easier to read and code is detrimental to the language, on the contrary.
i not sure what this feature making pascal better and easier. at least coz many people uses editors which cut trailing spaces which can be part of these multiline strings. and it makes harder to recognize "occasional strings" when you just wrote wrong (quote) char. 100% we will got some new problems with existing editing frameworks if this thing will be implemented. I'm not against language changes but if it really helpfull, necessary and don't makes new problems. but not this case (anyway, it just my personal opinion)
People like you are DIRECTLY what causes FPC's slow, inevitable decline in popularity. It's the same fucking thing every fucking time anybody wants to introduce anything new: a bunch of illiterate morons spouting off conspiracy-theory nonsense about how the sky is falling, who are ALWAYS, ALWAYS, ALWAYS clearly wrong in hindsight. You can go wayyyyy back on the developer mailing list for FPC and find people who unironically argued against the introduction of for-in loops the same fucking way you're arguing against this strings feature, back in like 2006. I'm not kidding. For-in loops! How fucking insane does that sound now that they've been a normal part of the language for years? Very!Absolutely agree, absolutely.
So yeah, for the love of god stop fucking driving away smart people who both want to improve FPC and can also actually do the work themselves, or sometime real soon there won't be anyone left working on it at all.
i not sure what this feature making pascal better and easier. at least coz many people uses editors which cut trailing spaces which can be part of these multiline strings. and it makes harder to recognize "occasional strings" when you just wrote wrong (quote) char. 100% we will got some new problems with existing editing frameworks if this thing will be implemented. I'm not against language changes but if it really helpfull, necessary and don't makes new problems. but not this case (anyway, it just my personal opinion)As Akira1364 wrote, there are already enough more critical features in Object Pascal that allows a user to shoot himself in the foot if they're not careful (and more spectacular as well). There are always ways to abuse or misuse a feature, so to simply use that to outweigh the potential uses of this feature feels like the easy way out.
Came across another area today where I think multi-line strings would be quite helpfulSpeaking of ideas, would something like this be possible eventually:
Look here (https://bugs.freepascal.org/view.php?id=25536).Came across another area today where I think multi-line strings would be quite helpfulSpeaking of ideas, would something like this be possible eventually:where template1.pas would be regular pascal file without opening and closing multilinestring character at the beginning and end of file?
const MultiLineTemplateStr = {$i '/codegen/template1.pas'};
Of course, probably with something new replacing $i from given example.
Look here (https://bugs.freepascal.org/view.php?id=25536).Nice! I missed it somehow... :-X
i not sure what this feature making pascal better and easier. at least coz many people uses editors which cut trailing spaces which can be part of these multiline strings.
And am already testing testing this feature using Lazarus and it works quite nice. And yes there are some hiccups like if I write word "type" inside new construction Lazarus will protest that type can't be there. But still it is not reason to not implement this feature.
I don't see much point in spending a lot of time on it until the actual language feature is merged to FPC trunk.Just curious... how is the "future" of that feature looking like ?... has a decision been made on whether or not it will eventually be added ?
I really don't see the point.That is no surprise.
It is already supported as many people explained.You must be very happy driving your Model T, it supports everything a car is supposed to do.
My hunch is - and I would support that - a big no.
I only take exception to code like this:Okay, the range for c should start from '0' as other directives allow leading zeros as well, but that's all we're talking about here: detecting leading zeros. The complete number is read by readval.Both the range and the limit. See if you can spot what I mean :o
if (c in ['1'..'9']) then // <------ sigh begin count:=current_scanner.readval; if (count<0) or (count>65535) then // <------- sigh some more
In my view the functionality is already covered by the string helper in sysutils and without an artificial limit. Let alone the meaning of "word"..
I only take exception to code like this:
Okay, the range for c should start from '0' as other directives allow leading zeros as well, but that's all we're talking about here: detecting leading zeros. The complete number is read by readval.
And using High(Word) instead of the literal 65535 would indeed be nice as well.
- snip -
"c" is one character, Thaddy. (As in, the first character of what may or may not be a valid number.) "readval" then attempts to read an actual complete number into the "count" variable.Well, Sven knew what I meant... :D
- snip -
Read my previous comment as to why I fundamentally disagree with you.
Nevertheless, I still hope for a little common sense...What I'm going to state isn't associated with the feature being discussed here, just a truism which is, common sense is the least common of all senses. (as clearly evidenced in a number of threads completely unrelated to this new feature.)
Nevertheless, I still hope for a little common sense...
This is a dirty feature.
Don't you understand -- in Pascal, trailing spaces at the end of a line have always been insignificant.
...
@SvenIt's about compiler related code, so of course I'll bite. And Akira1364 said that he'd make some adjustments...
You were not supposed to bite...
And as far as the helper goes, look at the interface. You can achieve the same with few lines of code. (syshelph.inc)I still don't get though what you're trying to get at with the helpers...