'Here-Documents' for easier multilinestrings to avoid #CRLF$

[Lebostein]

In my projects, I use a macro for this:

Code: Select all

Macro V
+ #CRLF$ + 
EndMacro

text$ = "Hello!" V "My name is Thomas," V "and this is a test!"

MessageRequester("TEST", text$)

..but the /n is standard in all program languages and simple to use...

[blueznl]

Hey fr34k, you can still rant and we still don't care

Or... how dare you! Calling my code not aesthetically pleasing!

Look how nice:

Code: Select all

  debug "Fr34k is
  _ absolutely the best"
  ;
  debug "After Fred, " + _    ; truth to be told
    "of course..."            ; yes, I know it's difficult

[Mistrel]

What about something like this?

Code: Select all

LStringVar=%"This is a long 'string' that
             can contain quotes, '"',
             spaces, line feeds And
             Chr(34) Until these two
             special characters are found
             at the End.%"

Although this looks pretty I don't see how it can be formatted like that^. The long spaces will be captured as well.

It's not the #CRLF$ that I have a problem with. It's having to escape mass amounts of double-quotes if I want to add html or PB code to a string. When this happens the string becomes unreadable very fast.

PHP can escape double-quotes by using two quotes together '""' but somehow that doesn't feel like it fits PB-syntax because there are no escape characters currently.

[blueznl]

At that level I guess one would need to put it into the compiler, in which case I fear it's mostly a wish

Pretty tough to do it using a preprocessor. How would you deal with the additional indents in front of the 2nd to last line?

[Mistrel]

Like I said, it looks pretty but there would need to be a solution without indentations like that.

I thought about this

Code: Select all

LStringVar=%"
The string starts here.%"

But that would leave a carriage return at the top. And I agree that there would be no way to identify formatting from a space or a tab.

[Dare]

Like I said, it looks pretty but there would need to be a solution without indentations like that.

I thought about this

Code: Select all

LStringVar=%"
The string starts here.%"

But that would leave a carriage return at the top. And I agree that there would be no way to identify formatting from a space or a tab.

To add to this purely academic discussion ..

In an earlier post I suggested that there could be a setting (flag) for compiler/ide to collapse leading spaces to one on line continuations (for the lines following the first).

Would that not be a solution?

[Mistrel]

I think it would be awkward because it would not be visibly apparent whether a trailing space has been left at the end of the last line to keep spaces between words.

[Dare]

Could be.

Perhaps ignore all leading white space on following lines ..

Code: Select all

Please.s = "Continue this _
            on the next line."              ; Renders "Continue this on the next line"

; versus

Please.s = "Continue this     _
            on the next line."              ; Renders "Continue this    on the next line"

; and

Please.s = "Continue this_
            on the next line."              ; Renders "Continue thison the next line"

Gives some visualisation.

As we are inside a string the _ is not a part of a symbol in the last example.

However underscores are legit chars in names, so - in our purely hypothetical discussion - what would be a good continuation character or symbol?

[Demivec]

@Dare: I like your idea for dealing with indent tabs/spaces for a continued line.

Regarding the inclusion of DoubleQuotes in a string I favor the use of "" for each double quote included. I've used this in other programming languages and found it readable and usable and simple.

Code: Select all

LStringVar="This is a long 'string' that _
             can contain quotes, '""', _
             spaces, line feeds And "_
             +Chr(34)+" Until the doublequote _
             at the End."

This includes the idea of long strings, long lines, and quotes and would be interpreted as this:

Code: Select all

LStringVar="This is a long 'string' that can contain quotes, '"', spaces, line feeds And "+Chr(34)+" Until the doublequote at the End."

The format for DoubleQuotes would give you these variations:

Code: Select all

"" = Null string
"""" = A single doublequote
"""""" = Two doublequotes

At the risk of being verbose, this means that for a quoted string it would always start with a doublequote and end with a doublequote and anywhere there was a pair of doublequotes withing it would include a single doublequote as a character in the string.

In dealing with the underscore character '_' used to show line continuation, it's rules would be as follows: If a string has been started with a doublequote then a underscore at the end of a line would show a continuation of the string or line (this would be interpreted as removing the underscore + CRLF + whitespace on next line, then appending the following line to this one). If while continuing a string a underscore character(s) is desired in the string this could be done by simply including the desired characters plus one more to show continuation.
In dealing with CRLF inclusion in a string, this could be down by using the continuation character at the beginning of a line (after indentation) and before the ending doublequotes appear.

To combine this jumble of rules together into a sample, it would appear thus:

Code: Select all

SstringVar = "This is the first ""short"" string."
LstringVar1 = "This is the first string, just _
               long."
LstringVar2 = "This is a long string with an _
               ""_"" in it."
LstringVar3 = "This is a long string with an ""__
               "" in it,
               _and a carriage return."
LstringVar4 = "This is long string #" + str_num _
               + " with a
               _carriage return and an ""_"" in _
               it for the
               _variable str_num."
avg_length = (82 / (78 + 4)) * total_string_lengths _
              / (str_num + 5 - (2 + 3))

It would produce the equivalent of:

Code: Select all

SstringVar = "This is the first "short" string."
LstringVar1 = "This is the first string, just long."
LstringVar2 = "This is a long string with an "_" in it."
LstringVar3 = "This is a long string with an "_" in it,
and a carriage return."
LstringVar4 = "This is long string #"+str_num+" with a
carriage return and an "_" in it for the
variable str_num."
avg_length = (82 / (78 + 4)) * total_string_lengths / (str_num + 5 - (2 + 3))

And to ramble on further, the caveats to these rules would be: no comments on a line that will be have the continuation character at the end (its long enough already!). If a variable name is present just before the continuation character, there must be a space between it and the continuation character (if an underscore is being used). Indentation will most likely be set for the continued lines, which means they may be difficult to read if no additional indentation is provided for them. When a continuation character is used at the end of a line, all tabs/spaces between it and the CRLF for that line have to be removed.

The rules mentioned IMHO would deal with most of the issues mentioned thus far. These being: CRLF in strings, long strings, continuation of lines, comments, included doublequotes (and in small part the "ugly" problem).

Exisiting code would still function fine with these rules implemented, thus allowing the use of existing code with no updates being made. Along the same lines, you can use any existing method such as macros, "line"+CRLF$+"next line", or extremely long lines with no penalty.

[kenmo]

Just to add my two cents - I like simple inline escape characters, as in Java, C, and countless others. "\n" for newline, "\q" for double quote, etc. Of course then you would also need "\\" for slashes, and these would have some backwards incompatibility problems with old code, but I'd prefer it over + #CRLF$ +. (I just thought - using backslash might cause big problems with Windows filenames.... hmm.)

Code: Select all

St.s = "Does anyone else here like escape character?\n"
St + "\qNo!\q\n"
St + "Well alright then."

[#NULL]

@kenmo
this has been already discussed. you can find it with the forum search.