Recent

Author Topic: Idea of multi-line strings, mantis 35827  (Read 9940 times)

circular

  • Hero Member
  • *****
  • Posts: 4181
    • Personal webpage
Re: Idea of multi-line strings, mantis 35827
« Reply #30 on: December 28, 2020, 01:55:57 pm »
No you load them by constant name/key from the compiled .po (.mo).
Oh ok, that sounds convenient. Is there a tutorial on that?
Conscience is the debugger of the mind

440bx

  • Hero Member
  • *****
  • Posts: 3921
Re: Idea of multi-line strings, mantis 35827
« Reply #31 on: December 28, 2020, 02:08:39 pm »
On contrary, it introduces something very dirty to Pascal language -- significant whitespaces at the end of line.
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.
But that supposes that Akira's proposal is a replacement for what is already in the language and that is simply not the case.

The multi-line string proposal is a feature that does a great job in _some_ cases.  As such, just like all Pascal features, it should be used for the problem it solves, e.g, 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. 

It isn't about where the line ends, what's important is that the feature matches the visual structure of a string to its function, i.e, one or more spaces or newlines will be present where they are expected while removing visual clutter that obfuscates what the resulting string should be.

(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Idea of multi-line strings, mantis 35827
« Reply #32 on: December 28, 2020, 02:33:11 pm »
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 SQL commands do not need linefeeds in the text (they can have, but do not need).

So the gain is minimal
Code: Pascal  [Select][+][-]
  1. sql := 'select foo, bar '+
  2.        'from t1 '+
  3.        '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 only bother is in the very few cases where you drastically shorten the sql and want to join lines.


Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Idea of multi-line strings, mantis 35827
« Reply #33 on: December 28, 2020, 02:44:46 pm »
Most examples show only the least intrusive side of the multiline string.  (As a constant declaration)

But they can occur anywhere in the code too (using ` in the example)
Code: Pascal  [Select][+][-]
  1.   if (DataLineRetrieved = `Lorem ipsum dolor
  2.  sit amet, consectetur adipiscing elit,
  3.  sed do eiusmod tempor incididunt
  4.  ut labore et dolore magna aliqua.`) and
  5.      (NextLineToSend = `Ut enim ad minim
  6.  veniam, quis nostrud exercitation
  7.  ullamco laboris nisi ut aliquip ex ea
  8.  commodo consequat.`) then
  9.   begin
  10.     DoSomething(`Lorem ipsum dolor `, `sit amet, consectetur
  11.  adipiscing elit, sed do eiusmod`, ` tempor incididunt
  12.  ut labore et dolore
  13.  magna aliqua. `, `Ut enim ad minim veniam, `, `quis
  14.  nostrud exercitation ullamco
  15.  laboris nisi ut aliquip ex ea commodo consequat.`);
  16.   end;
  17.  

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.

And how much fun, if the `` were to contain a lengthy fragment of Pascal source... (maybe even with embedded escaped ` inside)
« Last Edit: December 28, 2020, 02:47:16 pm by Martin_fr »

Zoran

  • Hero Member
  • *****
  • Posts: 1824
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: Idea of multi-line strings, mantis 35827
« Reply #34 on: December 28, 2020, 04:29:24 pm »
But that supposes that Akira's proposal is a replacement for what is already in the language and that is simply not the case.

It means that you no more can rely on that Pascal source file cannot have significant white space characters at the end of line.

In this topic I already mentioned two Lazarus' code editor's great features which rely on this:
- Trimming of white spaces from the line endings when saving. If multiline strings get into language, this feature will have to be removed unless made smarter - to first parses the code to determine if the line belongs to some string.
- Caret can be put anywhere beyond the end of line, behaving as if there are indefinite spaces there -- I find it very convenient when moving up-down through code, but it relies on that you should never care if there are spaces or not.


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.

Of course, you cannot turn off the feature, as I said in another topic, saying "if you don't like this feature, you don't have to use it" is just very wrong.
It's wrong for the reasons I gave there:

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.

440bx

  • Hero Member
  • *****
  • Posts: 3921
Re: Idea of multi-line strings, mantis 35827
« Reply #35 on: December 28, 2020, 07:00:56 pm »
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 minimal
Code: Pascal  [Select][+][-]
  1. sql := 'select foo, bar '+
  2.        'from t1 '+
  3.        'where foo > bar';

It really is just 3 chars per line ',',+
It's more than that.  Using your example and using Akira's multi-line strings, that can be rewritten as:
Code: Pascal  [Select][+][-]
  1. sql := '
  2.         select foo, bar
  3.         from t1
  4.         where foo > bar
  5.        ';
Not only is that easier to read, additions can be made without being encumbered with ' and + thereby lowering the possibility of errors.

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.

Another example using your own post:
Code: Pascal  [Select][+][-]
  1.   if (DataLineRetrieved = `Lorem ipsum dolor
  2.                            sit amet, consectetur adipiscing elit,
  3.                            sed do eiusmod tempor incididunt
  4.                            ut labore et dolore magna aliqua.`
  5.      ) and
  6.      (NextLineToSend =    `Ut enim ad minim
  7.                            veniam, quis nostrud exercitation
  8.                            ullamco laboris nisi ut aliquip ex ea
  9.                            commodo consequat.`
  10.     ) then
  11.     begin
  12.        DoSomething(`Lorem ipsum dolor `,
  13.                     `sit amet, consectetur
  14.                      adipiscing elit, sed do eiusmod`,
  15.                     ` tempor incididunt
  16.                       ut labore et dolore
  17.                       magna aliqua. `,
  18.                     `Ut enim ad minim veniam, `,
  19.                     `quis
  20.                      nostrud exercitation ullamco
  21.                      laboris nisi ut aliquip ex ea commodo consequat.`);
  22.   end;
  23.  
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.

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.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6646
Re: Idea of multi-line strings, mantis 35827
« Reply #36 on: December 28, 2020, 07:19:36 pm »
Code: Pascal  [Select][+][-]
  1. sql := 'select foo, bar '+
  2.        'from t1 '+
  3.        'where foo > bar';
  4.  
It really is just 3 chars per line ',',+

Elsewhere, there's currently discussion about these lines in FPC

Code: Pascal  [Select][+][-]
  1.       msg_errorparsingparametersatpos = ^C'Error parsing parameters line at line position %d.';
  2.       msg_cantinstallmoretools = ^C'Can''t install more tools...';
  3.  

which we're told parse the same as

Code: Pascal  [Select][+][-]
  1.       msg_errorparsingparametersatpos = Chr(3) + 'Error parsing parameters line at line position %d.';
  2.       msg_cantinstallmoretools = Chr(3) + 'Can''t install more tools...';
  3.  

Hence if concatenation really is implicit your example becomes the even less arduous

Code: Pascal  [Select][+][-]
  1. sql := 'select foo, bar '
  2.        'from t1 '
  3.        'where foo > bar';
  4.  

MarkMLl

MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Idea of multi-line strings, mantis 35827
« Reply #37 on: December 28, 2020, 07:43:02 pm »
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.
IMHO, that is terminating each string on its own line. ;)
For example it makes leading/trailing whitespace more apparent. I do not need to look out, what the compiler may have been told to do with them and what not. (Not that they matter for SQL)


Code: Pascal  [Select][+][-]
  1. sql := 'select foo, bar '+
  2.        'from t1 '+
  3.        '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. 
Code: Pascal  [Select][+][-]
  1. sql := 'select foo, bar
The IDE can be configured so that - upon pressing enter - it will insert
Code: Pascal  [Select][+][-]
  1. ' +
  2.  '
and place the caret.


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.
I do read both of our statements the same.
At least with SQL, I find it (in my own experience) rather rare that I need to join 2 existing lines.
Usually its add or remove lines. Add/Remove is easy to do with quotes per line.

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

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.


Code: Pascal  [Select][+][-]
  1.   if (DataLineRetrieved = `Lorem ipsum dolor
  2. ...
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.
"That said, your example is also contrived"
Exactly. Or rather, as of now: Exactly.

Luckily, the current string syntax discourage such abhorrent usage. Multiline strings will make this easier to write, and more likely to happen.


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.
Why not have it in its own file, added as resource. Much more flexible.


Zoran

  • Hero Member
  • *****
  • Posts: 1824
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: Idea of multi-line strings, mantis 35827
« Reply #38 on: December 28, 2020, 08:29:29 pm »
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.

You mean that the string like this:
Code: Pascal  [Select][+][-]
  1. 'abcd   ' + LineEnding + 'efgh' // has spaces in the first line
will not be possible to represent in new multiline form?

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.

As I said, I justify that claim with what I said in the other thread.
Please read again my post above, including the post I not only linked to, but quoted there.

440bx

  • Hero Member
  • *****
  • Posts: 3921
Re: Idea of multi-line strings, mantis 35827
« Reply #39 on: December 28, 2020, 09:18:54 pm »
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 insert
Code: Pascal  [Select][+][-]
  1. ' +
  2.  '
and place the caret.
That'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.



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:
Code: Pascal  [Select][+][-]
  1. 'abcd   ' + LineEnding + 'efgh' // has spaces in the first line
will not be possible to represent in new multiline form?
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.



As I said, I justify that claim with what I said in the other thread.
Please read again my post above, including the post I not only linked to, but quoted there.
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.
« Last Edit: December 28, 2020, 09:20:48 pm by 440bx »
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6646
Re: Idea of multi-line strings, mantis 35827
« Reply #40 on: December 28, 2020, 09:47:25 pm »
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
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Idea of multi-line strings, mantis 35827
« Reply #41 on: December 28, 2020, 10:28:01 pm »
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
The original statement here was not related to SQL. (It was about inlining other source code as text)

Zoran

  • Hero Member
  • *****
  • Posts: 1824
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: Idea of multi-line strings, mantis 35827
« Reply #42 on: December 29, 2020, 12:20:15 am »
You mean that the string like this:
Code: Pascal  [Select][+][-]
  1. 'abcd   ' + LineEnding + 'efgh' // has spaces in the first line
will not be possible to represent in new multiline form?
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.

If so, I'm not against it. For me, that was the fundamental problem with it.
Okay, I still wouldn't need it, but I would not oppose it.
But I doubt it is so. Restricting its usage to only text whose lines cannot end with spaces is hardly the idea.

As I said, I justify that claim with what I said in the other thread.
Please read again my post above, including the post I not only linked to, but quoted there.
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.

You asked me with what I justified the claim that the argument "Just do not use it if you don't like it" is never valid when talking about language features.
To that question I answered, there I did not comment whether it is more readable or not.
« Last Edit: December 29, 2020, 12:22:08 am by Zoran »

lainz

  • Hero Member
  • *****
  • Posts: 4449
    • https://lainz.github.io/
Re: Idea of multi-line strings, mantis 35827
« Reply #43 on: December 29, 2020, 02:56:57 am »
In my opinion the multi line string is really good.

But as well there is the interpolation feature to add variables inside.

Var myint:integer;

...

Mystring := """my age
                         is $myint""".trimmwhitespace()

Prints

my age
is 31

And about leading whitespace in kotlin there is a method to remove whitespace from left and right

PascalDragon

  • Hero Member
  • *****
  • Posts: 5444
  • Compiler Developer
Re: Idea of multi-line strings, mantis 35827
« Reply #44 on: December 29, 2020, 11:37:51 am »
But as well there is the interpolation feature to add variables inside.

Definitely no.

There better be a switch to turn this OFF!

The multiline string feature is coupled to a modeswitch that's off by default.

But even then: the feature being enabled won't affect your code in any way if you don't use it. And you can't do anything against third party developers that do use the feature and where you use these units (as modeswitches are per-unit).

 

TinyPortal © 2005-2018