PureBasic Forums - English

Is there a possibility to write an instruction on several lines - as people say , "continuation line" in PureBasic?

horia wrote:Is there a possibility to write an instruction on several lines - as people say , "continuation line" in PureBasic?

No. This question seems to come up now and then, search the forum to read more what's been said earlier...

horri:
EDIT:you beat me after hours!

8O Thanks,

as a r u l e y o u do n ot pu t sp
a
c es in side o f w o r d s. right?

So why would you want to haphazardly put spaces or new lines into terms and commands -- just to prove that you can? That serves no purpose, and onlyh makes it harder to read and maintain your code. In addition, it also makes the files bigger and puts a much greater demand on the compiler. which has to make sence of whether

end
if

is suppose to be an "EndIf" or and "End" command that preceeds an "If".

And if it's decision does not agree with your intent, then how are you going to find the line that is being misconstrued?

What we have discussed on other threads,
is to take the natural break
between words and terms, and
allow
us
to
spread them
over consecutive lines.

But while you can read the above well enough, since your mind makes the connection that this is a single statement, the compiler does not have the luxury of always knowing what you meant, only what you signify by the text you enter. For it to deal with this correctly, _
it _
may require _
some continuation _
symbol, such as an underscore _
on the current line, or a preceeding
_ symbol, such as an underscore,
_ to show that this line joins to the one above.

Such techniques become ever more important as you attempt to make the
text more readable, and lables or terms get longer and longer. Now in C/C++, spaces, tabs, and newlines are all treated as white space. That imposes some penalty on the language as to when a statement actually ends, which means a lot of right parens or curly brackets running around trying to join up with a leading left paren or curly bracket somewhere above in the code. Not so easy or read or structure.

I see the need for a continuation method. I fail to see the advantage of b re a k
in
g up t
erm s
wi
thout
due
thought.

Too much noyse for just nothing.Forget it .It was a simple question , not a request.The spirit of this forum begins to alterate.Good bye.

It is not my intent to offend. I just failed to see the benefit of this request, and tried to make it apparent to others why I found it objectionable. The fundamental rule of current writing is that white space separates symbols into groups, just as the words on this screen do. I've seen ancient text that runs continuously without a break, and the ancient eqyptians were known to put a box around a group of symbols to create a unique name. Ifyousaidlet'sjusteliminatespacesbetweentermsIwouldhavebeenjustasadementinmyobjections. At the very lease, I feel that some reason should be given for making such as request, just as I try to explain the reasons I have against it.

It was question about very long instructions , not about
i
f
...
t h
e
n
...
Every programming language has this facility.Nobody is such idiot to play with words , especially after nearly 30 years of experience in programming languages

Which is, say what you mean, but mean what you say.

> I just failed to see the benefit of this request

Because sometimes a line can be too long to view without scrolling. I had
this problem recently when using long Registry paths in my app -- they're
just way too long to view on my 1024x768 monitor.

On one hand, someone advocated breaking up words by allowing spaces or
returns to be placed in them (at least that is what his example showd). I. on the other hand, pointed out that a line continuation symbol was needed in order to allow lines, rather than words, to lap over to other lines. That is where I showed the use of a separate underscore (_) character at the end (or the beginning) of a line. (Because of some side effects, at the line is actually better than at the beginning).

You seem to think I am against line continuation, but you misconstrue my remarks. Go back are read what I have said, and you will see that never once did say anything to that effect. But unlike normal text, we do not have the convenienct of using a period (.) to indicate where a line ends. Nor do we have the pleasure of knowing that words are principally lower-case letters without embedded punctuation or digits. Nor do we see that words are only occasionally preceeded by a capital letter, and then only at the start of a new sentance or for formal names or to Emphasize something. And the use of all capatal letteres is NEVER done, unless we intend to exaggerate something.

Knowith this, or at least somewhataware of this, we see that the way we compose source code is somewhat different. BASIC syntax is that you have one statement per line,. Later, the use of the colon (:) was added so that you could have more than one statement per line, in the interest of compressing programs even more (memory was short, and it generally too an additional 5 bytes to mark a new line and line number).. But the need for a line continuation character has not been universally established, because old habits die hard, and most programmers prefer short names for their variables and lables, and relatively terse code. That means that most statements tend to be short, and even long ones are not overly long.

MicroSoft changed that with its Windows API constants and functions. Now the names had to be long, case sensitive, and somewhat self-documenting. It still allowed you to use short local names with the "Alias" convention, but increasingly, programmers have decided that it was generally better to use the original name, so that as they became familiar with the Windows APIs, they did not need to try to remember any local names for those functions as well. But long procedure , constant, and variable names introduced a new problem: Lines became longer and longer, and there was no line wrap capability in the editors or viewers. In fact, these had been tried on occasion, but the results were often less readability. The preference was to have one line viewed as one line.

The final compromise seems to be the emerging need for a line continuation character. A couple of languages have used the underscore (_) character, and I myself find this works very well. (Actually, it is the use of a whitespace_underscore_whitespace sequence, making it different from the leading underscore_name or underscore used in names such as this_could_be_a_name construct).

So this _
could represented a line continuance. Now a line continuance has to be
used properly. For instance, it cannot be used in the middle of a word or te_
rm, because this could change the meaning of the word or term. Should Else_
If
be recognized as ElseIf or Else_If, a legal name construct?


Nor do you break up number sequences, such as
123 _
4567
since the combined result would be 123 4567 with a whitespace included, and would be parsed as two different numbers (usualling resulting in an error as well)

In fact, the only place where you could use the continuation character has to be where a space, tab, or line feed, or enter key could be used without altering the reconstruction of the line in any way. So, for instance, you could take a statement like this:

Total=subtotal+shipping_and_handling+tax
and insert a (whitespace+underscore+whitespace) immediately before or after the equals (-) sign, immediately before each of the operators (+), or even after the tax (if you really want the next line joined to this one), but not anywhere else.

People that do not like long lines can break them up into lines of more or less the same length. By peeking the whole within the editor window, they fine it easy to read it. The editor or viewer know knows exactly where to
wrap the line at. or whether to wrap it at all. It is a pretty good way of handling an awkward problem.

But the real question is, should a given syntax use the whitespace+underscore+whitespace method, or should some other symbol be adopted? Some argue that a comma at the end of a line would do as well, but what about the comma that needs to be there to separate
parameters in a procedural call? Would you require that two commas be
used there, or just one and that the compiler then have to spend more time examining the syntax to see if the comma were needed in the context given, or if it should be discarded or not? And if your compiler is smart enough to allow two consecutive commas (,,) to signify null parameters, would the last comma be for the purpose of signifying a null parameter, a line continuation, or both?

That is the problem with other symbols as well. Taken individually, they may have other meanings or purposes, or they may be reserved against a future need. And the symbols need to be reproducable on any keyboard using any font. The underscore was a particularly good choice because it was only defined for use in names, and if you use it outside of names (by surrounding it by whitespaces), it clearly stood out and had no other purpose. You could have chosen something like (~) I suppose, but in mathematics, this might mean similar or approximately equal to, and who is to say that someone doesn't want to use that method of evaluating results as an added feature in the future? Thje vertical bar (|) is often used to represent a bit-wise OR function, so it would not be a good choice. You can use the curly-brackets I suppose, but they work as a pair, to taking one away renders the other less useful. Besides, they are hard to recognize, since they resemble parens so closely, and there may be a future need for a pair of wrap symbols that are uncommitted at this time.

In other words, there is a need, it is an emerging need, and there are few candidates for the job. But whitespace (which includes spaces, tabs, carriage returns, and line feeds) do not provide a means of signalling a line continuation condition, since their scope and use serves for other purposes. You need a specific symbol and method for making line continuation recognizable, to you, to others, and to the compiler/editor.

> should a given syntax use the whitespace+underscore+whitespace
> method, or should some other symbol be adopted?

Visual Basic has used " _" (without quotes) for years and without problem
for thousands and thousands of VB source codes on the net, so I say, use
that. In fact, I wrote a little app that converts a PureBasic source with
those codes to long lines before compilation, and it works 100% perfectly.
Perhaps Fred would like to use it for PureBasic?

I tuned in late, but it seems the discussion is bypassing the most important points.
- It's quite academic to think about dividing keywords
- a continuation character is a kludge, a very low level solution, which may be the simplest to implement but has no other advantages.
- long lines are easily prevented for my own stuff, but not for Windows:
is orders of magnitude worse to read than:

and I dislike introducing additional variables just to get some of the computations out of the oversized function call.


The Python programming language, for example, is line oriented too: Typically every statement is in a line of its own, closely coupled statements may be compressed into one line, for which a separation character is required. So far same as PB. The interesting difference comes now: If the statment is not syntactically complete (typical case: closing parenthesis missing), the next line is considered a continuation line.

How about that?

guido

Guido wrote:The interesting difference comes now: If the statment is not syntactically complete (typical case: closing parenthesis missing), the next line is considered a continuation line.

How about that?

Wouldn't that make a mess of bug hunting?!?
I mean.. then the error could point to 30 lines below the actual equation (coz that's where the next parenthesis is)?!? :roll:

Or am I way off here?!

-Lars

LarsG wrote: Wouldn't that make a mess of bug hunting?!?
I mean.. then the error could point to 30 lines below the actual equation (coz that's where the next parenthesis is)?!?

Actually it's not so much of a problem, because something has to fill these 30 lines. Any <b>statement</b> (like: if, repeat) is unlikely to be legal within a procedure call. The most probable is, that one assignment could be misinterpreted as comparison. But after that a comma would be necessary before the next argument....

And 30 lines of comments are easy to catch.

guido