I don't see how the usage you do in scripting languages interferes here. It is not the same interpreter.
Better load them from resources, easier to post compilation translate themHow would you do that actually?
Better load them from resources, easier to post compilation translate themHow would you do that actually?
Better load them from resources, easier to post compilation translate themHow would you do that actually?
But there is already a solution to that that works perfectly fine in current fpc:A hint, if I may: better shut off macros or undefine "ln" when it's no longer needed; otherwise you might find all your WriteLn()'s converted to "Write+LineEnding()" ;D[... etc ...]
{$Macro on} {$Define ln:=+ LineEnding} const mls = 'multi'ln + 'line'ln + 'string';
select
p.proj_id,
case when p.team_leader = e.emp_no then 'project leader' else '' end as is_leader,
e.full_name,
p.proj_name, p.proj_desc, p.product
from project p
inner join employee_project ep on ep.proj_id = p.proj_id
inner join employee e on e.emp_no = ep.emp_no
order by 1, 2 desc
Lazarus editor also provides an easy way to paste multiline string -- right click in place where you want to insert it and chose "Multi paste" (not actually a self-explaining name for that option).
Lots of ways, for example:Ok well I know those ways but they are not really making it simpler.
- use a resourcestring section, though that posses the same problem with multi-line strings as any other code;
- go down to basics and write your strings in an rc script as a string table, reading them back with a TStringTableResource, which has the advantage than some (most?) resource compilers allow you to use C-like scapes in the rc script;
- ... etc ...
Lazarus editor also provides an easy way to paste multiline string -- right click in place where you want to insert it and chose "Multi paste" (not actually a self-explaining name for that option).That's good to know. In a way that solves the question.
That's good to know. In a way that solves the question.A few things are worth noting...
Comparing the example @Zoran posted (see previous page) which uses "+ LineEnding" with using the backtick (see https://forum.lazarus.freepascal.org/index.php/topic,46050.msg326901.html#msg326901), the result using the backtick method proposed by @Akira1364 is substantially cleaner and easier to read, specifically because there are no "+" and "LineEnding" poking the eye of the reader. In addition to that, changing the text is much simpler because the programmer doesn't have to concern him/herself with possibly having to add or delete "+ LineEnding".
On the other hand, the "backtick" is a small glyph and somewhat difficult to see when you're eye-scanning the text and making modifications at three a.m. and you are looking through a mental fog and irritated, tear-strained eyes.That's true and, it is likely a significant reason why the code looks so clean. Everything has its pros and cons, backtick included. ;)
https://bugs.freepascal.org/view.php?id=35827One thing I just rembered, if runtime code is not a problem (which it is for like consts), the following works:
I only want to suggest a syntax for multi-line strings:
case1)
var s = 'begin'/ 'mdl'/ 'end.' ;
Here we use / which is not defined for strings.
A hint, if I may: better shut off macros or undefine "ln" when it's no longer needed; otherwise you might find all your WriteLn()'s converted to "Write+LineEnding()" ;DThis was more of an example, if one thinks this more through, probably ln is also not the best name (probably a lot of people including me use ln as name for temporary variables containing lines). Something that is highly unlikely to be used, maybe something starting or ending on underscore, something line "_ln" or "_endl" or so.
But thats not a good solution.Not a bad one either to me. At least it serves the purpose, other overloadable symbolic operators are only - and *, which is way worse than /, while the rest are identifier operators. Nah, I wouldn't define AND for it.
the backtick method proposed by @Akira1364 is substantially cleaner and easier to read,
So, please do not introduce significant whitespaces at line endings in Pascal.+1
Better load them from resources, easier to post compilation translate themHow would you do that actually?
I don't do much enduser ready stuff in Lazarus, mostly internal tooling. But in my companies main (Delphi) app, I edit everything with GORM (poedit equivalemet made in Delphi), and then embed the .po's into the binary.Ok. Interesting, though that doesn't make it easier to add multiline strings, does it? You still need to add them as string constant.
I suppose we can say the lines are R-trimmed.So, please do not introduce significant whitespaces at line endings in Pascal.+1
I don't do much enduser ready stuff in Lazarus, mostly internal tooling. But in my companies main (Delphi) app, I edit everything with GORM (poedit equivalemet made in Delphi), and then embed the .po's into the binary.Ok. Interesting, though that doesn't make it easier to add multiline strings, does it?
You still need to add them as string constant.
No you load them by constant name/key from the compiled .po (.mo).Oh ok, that sounds convenient. Is there a tutorial on that?
On contrary, it introduces something very dirty to Pascal language -- significant whitespaces at the end of line.But that supposes that Akira's proposal is a replacement for what is already in the language and that is simply not the case.
Inside these multiline strings, it is not obvious where the line ends. It is a very dirty feature.
<snip>
So, please do not introduce significant whitespaces at line endings in Pascal.
multi-line strings such as embedded SQL commands. There are cases when it is _not_ the right solution, that doesn't mean it "dirties" the language.
But that supposes that Akira's proposal is a replacement for what is already in the language and that is simply not the case.
And save yourself the repeated "But you do not have to use it that way". The day will come where any of us will have to decipher something like this.
I think,nobody is forced to use inline variables in C++.
Please never use this argument.
Programming is not only writing new code, but also reading and understanding code written by others.
And in the end it is much more maintaining (often other people's) code, than writing new code.
This is not about "inline variables", but generally, saying "if you don't like this feature, you don't have to use it" is just very wrong.
But SQL commands do not need linefeeds in the text (they can have, but do not need).As your statement above clearly indicates, the presence or absence of a line feed in that case makes no difference. Therefore the solution that produces the less clutter is preferable.
So the gain is minimalIt's more than that. Using your example and using Akira's multi-line strings, that can be rewritten as:
sql := 'select foo, bar '+ 'from t1 '+ 'where foo > bar';
It really is just 3 chars per line ',',+
And they can be inserted by the IDE when you first write the sql.The IDE cannot achieve the above which is, increasing legibility and lowering the inclusion of errors during maintenance.
The only bother is in the very few cases where you drastically shorten the sql and want to join lines.The "bother" is when the sql statements need to be modified. The multi-line string facility makes that easier and less prone to errors.
And how much fun, if the `` were to contain a lengthy fragment of Pascal source... (maybe even with embedded escaped ` inside)Sounds more like that would be an ideal use of the multi-line string facility. The code could simply be copied and pasted between two backticks. Much simpler than tediously adding "+" and LineEnd at the end of every line of code.
It means that you no more can rely on that Pascal source file cannot have significant white space characters at the end of line.multi-line strings don't introduce significant white space at the end of the line. The line end itself acts as a separator as it always has.
saying "if you don't like this feature, you don't have to use it" is just very wrong.nice sound bite but, how do you justify that claim ? IOW, what is wrong about deciding _not_ to use a feature in the language ? just because a feature is present, it doesn't mean it _has_ to be used.
It really is just 3 chars per line ',',+
sql := 'select foo, bar '+ 'from t1 '+ 'where foo > bar';
IMHO, that is terminating each string on its own line. ;)But SQL commands do not need linefeeds in the text (they can have, but do not need).As your statement above clearly indicates, the presence or absence of a line feed in that case makes no difference. Therefore the solution that produces the less clutter is preferable.
The IDE cannot achieve the above which is, increasing legibility and lowering the inclusion of errors during maintenance.It really is just 3 chars per line ',',+
sql := 'select foo, bar '+ 'from t1 '+ 'where foo > bar';
And they can be inserted by the IDE when you first write the sql.
I do read both of our statements the same.The only bother is in the very few cases where you drastically shorten the sql and want to join lines.The "bother" is when the sql statements need to be modified. The multi-line string facility makes that easier and less prone to errors.
"That said, your example is also contrived"The code above is much more readable and easier to maintain. That said, your example is also contrived. It is rare to perform operations on multi-line strings and, it could be one of those cases where using the "+" and LineEnd may be justified.
if (DataLineRetrieved = `Lorem ipsum dolor ...
Why not have it in its own file, added as resource. Much more flexible.And how much fun, if the `` were to contain a lengthy fragment of Pascal source... (maybe even with embedded escaped ` inside)Sounds more like that would be an ideal use of the multi-line string facility. The code could simply be copied and pasted between two backticks. Much simpler than tediously adding "+" and LineEnd at the end of every line of code.
It means that you no more can rely on that Pascal source file cannot have significant white space characters at the end of line.multi-line strings don't introduce significant white space at the end of the line. The line end itself acts as a separator as it always has.
saying "if you don't like this feature, you don't have to use it" is just very wrong.nice sound bite but, how do you justify that claim ? IOW, what is wrong about deciding _not_ to use a feature in the language ? just because a feature is present, it doesn't mean it _has_ to be used.
IMHO, that is terminating each string on its own line. ;)I believe you are right about that. I don't see a problem with it whenever having a string on its own line doesn't affect the semantics, as is the case in an SQL statement (as you pointed out too.)
The IDE can be configured so that - upon pressing enter - it will insertThat's not a very desirable solution. the IDE has to be configured to do it (that requires work) and adding those characters upon pressing <enter> isn't always desired. In addition to that, whether those characters are inserted automatically or not, they still clutter text. IOW, in the best case, the IDE can provide a limited amount of help (I'd say even calling it help is questionable) yet still be unable to really increase the legibility.and place the caret.
' + '
Usually its add or remove lines. Add/Remove is easy to do with quotes per line.True but, it's even easier if quotes are not needed.
I do not dispute that it saves (up to?) 2 or 3 keypresses (per line). But are those worth the potential downsides? Other things that would have saved many more keystrokes have been rejected as syntactical sugar (and rightfully so).My position on that feature is _not_ based on saving keystrokes (I'm not afraid of typing a lot), I support that feature because when used appropriately it results in greater readability and increase ease of maintenance. That's more than syntactic sugar.
Mind also: In the above, I merely reject the "sql" example, as an example for multiline strings. IHMO the sql example does not show any real meaningful savings.The statement is much cleaner and easier to read. IMO, that's a meaningful improvement particularly considering that in a program that does a lot of database access, the improvement will take place in every SQL statement. As they say in the U.S Congress, a billion here, a billion there and pretty soon, you're talking about real money.
Luckily, the current string syntax discourage such abhorrent usage. Multiline strings will make this easier to write, and more likely to happen.it will be a good day for programming when the most abhorrent thing seen in a program is the misuse of the multi-line string feature.
Why not have it in its own file, added as resource. Much more flexible.Not really sure if that is more flexible. Another file to manage and, all the statements are in a "big bucket" instead of being defined where they are needed, i.e, no context locality.
You mean that the string like this:I believe that to be correct that such a line could not be represented using Akira's mult-line string feature. That said, that's an "educated guess" on my part. Akira could authoritatively answer your question.will not be possible to represent in new multiline form?
'abcd ' + LineEnding + 'efgh' // has spaces in the first line
As I said, I justify that claim with what I said in the other thread (https://forum.lazarus.freepascal.org/index.php/topic,42271.msg387933.html#msg387933).I did and, as far as reading and understanding other people's code, the less cluttered the code is, the easier it is to read and understand.
Please read again my post above, including the post I not only linked to, but quoted there.
Why not have it in its own file, added as resource. Much more flexible.
The original statement here was not related to SQL. (It was about inlining other source code as text)Why not have it in its own file, added as resource. Much more flexible.
Quite frankly the place for SQL is inline with the code that provides parameters and parses the result.
MarkMLl
You mean that the string like this:I believe that to be correct that such a line could not be represented using Akira's mult-line string feature. That said, that's an "educated guess" on my part. Akira could authoritatively answer your question.will not be possible to represent in new multiline form?
'abcd ' + LineEnding + 'efgh' // has spaces in the first line
As I said, I justify that claim with what I said in the other thread (https://forum.lazarus.freepascal.org/index.php/topic,42271.msg387933.html#msg387933).I did and, as far as reading and understanding other people's code, the less cluttered the code is, the easier it is to read and understand.
Please read again my post above, including the post I not only linked to, but quoted there.
But as well there is the interpolation feature to add variables inside.
There better be a switch to turn this OFF!
But as well there is the interpolation feature to add variables inside.
Definitely no.
And about leading whitespace in kotlin there is a method to remove whitespace from left and right
And about leading whitespace in kotlin there is a method to remove whitespace from left and right
What do you mean?
There are functions in fpc as well (in SysUtils - Trim, TrimLeft, TrimRight (https://www.freepascal.org/docs-html/current/rtl/sysutils/trim.html), which are also provided as String helper routines (https://www.freepascal.org/docs-html/current/rtl/sysutils/tstringhelper.trimleft.html)). Plus, with LazUtils dependecy, in LazUTF8 unit there is UTF8Trim (https://lazarus-ccr.sourceforge.io/docs/lazutils/lazutf8/utf8trim.html) function with more possibilities...
I mean thisThis is not possible in Pascal due to the strict runtime and compiletime separation, which Kotlin simply does not have.
https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.text/trim-indent.html
To use runtime code, like a Trim function, you need to in the implementation block of your function, program, whatever and not in the definition block (where variables, constants, etc. are defined).
Allowing types to have attributes e.g. "is trimmed on assignment" would probably fix this, but unless the language were completely reengineered to be extensible they'd have to be agreed on in advance.Yeah, I mean compiler magic is always a solution that could be implemented, but I think such things are way to specific to justify having custom compiler makros or so for them. A more general approach, used in other languages like Java, is the defining of custom annotations that influence the code generation during compiletime. E.g.
var MyLogger: TLogger initialize MyLogger := TLogger.Create(Output) finalize MyLogger.Free;
Another option would be compiletime functions. C++ allows for constexpr functions, these are functions of whoom all inputs are constants available during compiletime, that will be evaluated during compiletime. A constexpr TrimIndent could there be implemented that way.
But to be honest, Pascal is probably not the kind of language where such features are going to be implemented. While they can be very neat with regards to usability (like the getter and setter example from above), they add a whole new dimension to the language, where the behavior of every line of code can be completely altered with such annotations, which need to be understood by the maintainer in the first place (and looking at some enterprise Java source, these annotations can look like black magic).
Something that might be more interesting would be if runtime code could be used in the definition segment. I think the ugliest part of pascal that always create really bad code is the use of the initialization and finalization segment.
No. With this you're mixing declarations and code, something that we're already against with Delphi's inline variables and this would simply be the other way round.But then the question arises, is a strict distinction between declaration and code a good thing in this circumstance. Because I don't see any value in purism just for purisms sake. Just because in some circumstances this distinction produces better code, does not mean that in all circumstances it does and should be enforced in all circumstances. If it produces worse code, there is no reason to enforce this.
J. Gareth Moreton is working on a concept called pure functions which is essentially constexpr for Pascal.This is great news. With the not so pascallian I meant more like the java like annotations. Because they always look like black magic to me, and I hope something like this never comes to pascal
It's more than that. Using your example and using Akira's multi-line strings, that can be rewritten as:Not only is that easier to read, additions can be made without being encumbered with ' and + thereby lowering the possibility of errors.
sql := ' select foo, bar from t1 where foo > bar ';
I agree with this concept. What should be avoided is having to add something line by line, versus simply being able to paste some text. Looks like a matter of just agreeing on something distinct. I would like to see something like below.