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

[AND51]

Hello!

I'm currently working with CGI/Perl when I have this idea. Here-Documents allow the coder to build multi-line strings without \n etc.

In Perl, there are 2 possibilities to build a string with line breaks:

Code: Select all

$string="Hello World!\n\nThis was an empty line\n4th line\n5th line...":

$string=<<TEXT;
Hello World!

This was an empty line
4th line
5th line...
TEXT

In Perl, TEXT is a string terminator that tells the interpreter where the multi-line ends. You can name the string terminator as you want.


In PureBasic, this could be a possibility:

Code: Select all

Define string$="Hello World!"+#CRLF$+#CRLF$+"This was an empty line"+#CRLF$+"4th line"+#CRLF$+"5th line..."

Define string$=<<"Hello World!

This was an empty line
4th line
5th line..."

My intention is to avoid #CRLF$ all the time. Have you ever built a MessageRequester() with a veeery long text? I have and many of those requesters contained line breaks.
With Here-Documents in PureBasic you might build also MessageRequester() or TextGadget() in an easy way.

If this feature will be implemented, we can discuss together, how we will do it.
This could be a possibility:

Code: Select all

MessageRequester("Multiline Information", <<"This is a demonstration
of how to use here-
documents in PureBasic.
Thanks for reading.", #MB_ICONINFORMATION)


TextGadget(#PB_Any, <<"This is a complex example of multiline strings
that should contain variables.
My name is "+name$+<<" and
I'm "+Str(age)+<<" years old.")

You can imagine that << is the place where the following string should be inserted. The text itself, surreounded by duoble-quotes can be handled as usual, so it is still possible to insert variables, etc.

As I said, there are many opportunities where this feature could be helpful. Currently I'm working with CGI/Perl and so on. So I need to work with HTTP-Requests too and this feature could help me in this special situation. But also to fill gadgets and requesters, as well as variables, this feature would be helpful.


I hope you understand what my intention is.

[Trond]

Why on earth do you want such an obtuse syntax when all you need is this?

Code: Select all

MyString-s = "Hello, this is a message that spans
multiple
lines"

Alternatively:

Code: Select all

MyString-s = "Hello, this is a message that spans" _
"multiple" _
"lines"

[AND51]

Well, when I posted my idea, I was inspired by CGI/Perl.

If you want to implement this feature, it is cler that you need an indicator, so that you (rhe coder) and the compiler can recognize that a multiline-string starts.

I appreciate your idea to replace the dot by a minus good:

Code: Select all

Define mystring-s="hi"
Define mystring.s=<<"hi"

In spite of that, I finde the <<-solution better. Think of mystring$, what would you to thi case? Moreover, you don't consider how to insert multi line text into a requester, for example.

That's why I suggest <<.
Of course, I'm willing to listen to your ideas, together we will fin a good solution, I think. I'd also appreciate the PB team to post its opinion here.

By thw way, Trond, your alternative idea is IMHO insufficient, because you must write 2 double quotes per line plus the underscore. Don't get me wrong, but my intention is to reduce the amount of charcters you have to type. And I can't imagine how to insert variables into your alternative code.

[freak]

this is just ugly...

[Trond]

I appreciate your idea to replace the dot by a minus

That was just a typo.

If you want to implement this feature, it is cler that you need an indicator, so that you (rhe coder) and the compiler can recognize that a multiline-string starts.

That's not necessary if all strings are multiline.

[AND51]

this is just ugly...

Please, tell me more why you do/don't appreciate this idea.

That's not necessary if all strings are multiline.

Hm... But you don't always need multiline strings. I think, single line strings will be dominant in the future. This feature should be an alternative, for the more less case that a coder needs multi line strings.

[Trond]

That's not necessary if all strings are multiline.

Hm... But you don't always need multiline strings. I think, single line strings will be dominant in the future. This feature should be an alternative, for the more less case that a coder needs multi line strings.

But it's simpler to just make normal strings multiline.

Code: Select all

MessageRequester("Title", "Single-line string")
MessageRequester("Title", "Multi-line
string")

[AND51]

But it's simpler to just make normal strings multiline.

OK, this would also be a solution.
I didn't think of that, because I don't know, if it's easy to implement and easy enough to handle.
That's why I'd like to listen to the PB team.

[blueznl]

Not sure if Fred ever promised multiline support (I think at one time he did, but I'm a bit too lazy to look it up )

Basic's often use the following approach:

a.s = "1234" _
+ "abcd" _
+ "defg"

But, when you think about it, it's the wrong way of doing it, as it's not a total efficient multiline construction, and makes things complicated, for example when dealing with comments:

Code: Select all

a.s = "1234" _    ; more stupid code
  + "abcd" _      ; oh dear, the underscore is no longer the last char
  + "defg"

Codecaddy preformats code using the listed rules above, however it cannot do this for include files.

Now, an alternative way (which I haven't tried myself yet) would be to put the underscore AT THE START of a line:

Code: Select all

a.s = "1234
  _ abcd
  _ defg"

This would leave code very clean and very readable, and shouldn't be too hard on the compiler. It would not conflict with any other PureBasic statements, comment lines, whatsoever.

Things would get somewhat 'hairy' when doing comments:

Code: Select all

a.s = "1234"      ; again another test
  _ +"abcd" +     ; will this never end
  _ "defg"

... but when you think about it carefully, it's not that hard. What would be necessary is to do a little 'look ahead' and smart deduction.

1. read a line source
2. strip the comments (who needs them anyway )
3. check if the next line starts with an underscore
4. if so, add it verbatim to the current line, then go back to step 2
5. if not, compile current line

The only nasty part is that you have to 'look ahead' a little. Something that conflicts somewhat with the 'single pass compiler' concept. (Which, to be honest, is a little confusing, I mean, I jumped with joy with my old two pass 6502 compilers, so in a way it's back to the dark ages )

I could easily write a little preprocessor to handle this (as CodeCaddy does) but I haven't got a clue how to pre-process includes.

[freak]

this is just ugly...

Please, tell me more why you do/don't appreciate this idea.

Its ugly, what more is there to say ?

I've seen it in php. In my opinion it just creates a big mess.

[Mistrel]

I've gotten used to doing this

Code: Select all

n.s="this"+#CRLF
n.s+"and"+#CRLF
n.s+"that"

The only time I have a problem with this is if I want to embed a chunk of html. That's hard.

I do agree with freak. All of the suggestions I've seen so far are ugly.

[AND51]

> Its ugly, what more is there to say
I expected some more arguments. This feature request subforum is to post new ideas. Those people want to know, wheter their ideas are good or not. Therefore you need arguments and not just half of a sentence.

> In my opinion it just creates a big mess
So you prefer long one-liners and messagerequesters with 1 KB Test in just one line?

You're right, the thing with << and/or the string terminator makes the code unclear. I think Trond's idea is the best. What do you say to his idea?

// Edit:
@ Mistrel:
I know your workaround. But it's annoying to initialize a variable for every multi line string. Furthermore, you didn't get the title correctly: I'd like to avoid the
" + #CRLF$
at the end of every line.

[Dare]

Well,

I support anything reasonable that allows multi-line.

The _ (or whatever as last character on the line for breaks between tokens)
The =<<" (or whatever or no token at all to indicate that line breaks are ignored until the next " [quote] is encountered).

With the second idea I would suggest (were this a democracy) that leading white space on the following line is collapsed to one space so you can have:

Code: Select all

multiLine = thisThing + thatThing _
            * theOtherThing

myString = <<"This is a 
              multi-line
              string. It is
              the same as:"

myString = "This is a multi-line string. It is the same as:"

myString = "This is a 
            multi-line
            string. It is
            the same as:"

BTW - beauty is in the eye of the beholder!
* agitates for democracy then runs away *

[Mistrel]

How would you make the distinction of ending in LF, CR, or CRLF?

[Dare]

How would you make the distinction of ending in LF, CR, or CRLF?

Surely these variations are already recognised by the IDE and compiler?

I think for the compiler, dealing with multi-line is pretty straightforward. It is batch and linear.

But for the IDE it probably involves some jumping around, being dynamic.

Mind you, once multi-line statements are possible, block comments are halfway there!

BTW, multi-line strings without some sort of symbolic clue, like the = <<" could lead to problems like:

Code: Select all

Oopsie = "I forgot to terminate.
SoThis = PartOfTheString
AndThis = "bad code because the preceding quote terminated the string!"

(Perhaps even with symbolic clues).

Worth it though.

Then with block comments we could 'rem' out the above:

Code: Select all

;+; Darn, something bad here.

Oopsie = "I forgot to terminate.
SoThis = PartOfTheString
AndThis = "bad code because the preceding quote terminated the string!"

I will look at this later! ;-;