Numeric Line# vs. Actual Line Statement counts

[Mike Luther]

What are the restrictions for the use of numeric line numbers as related to the actual statements that can be written between two numeric line numbers? For example, If we write source as:

10000 ' A discrete line number in source
DMY1% = 1
DMY2% = 2
DMY3% = 3
DMY4% = 4
DMY5% = 5
DMY6% = 6
10005 PRINT DMY1%'semicolon' DMY2%'semicolon' DMY3%

That example has six 'lines' of source code between two discrete numeric line numbers in the source which are only five numeric digits apart.

At what point do we get into trouble relative to the number of statements in the source code between two discrete numeric line numbers?

Sure, I realize that we could write the above code as

DMY1% = 1'colon'DMY2% = 2:'colon'DMY3% = 3 ...

But at what point do we get in trouble between, for example, if we choose numeric line # 10000 then choose the next numeric line # to be, say 10001 in the example above? Or must we actually guarantee that we never have discrete line numbers in the souce which are less than the actuall number of 'statement' lines that are present between two discrete numeric line numbers in the souce?

Inquiring mind wants to know.

[Eric Pearson]

Mike --

If I understand your question, the answer is "none of the above".

Line numbers and labels are 100% arbitrary. They do not even have to be in numeric order. There is no requirement for them to align with the "physical" line number or anything else. They must be unique, but that's it.

-- Eric

[Michael Mattias]

Line numbers and labels are 100% arbitrary. They do not even have to be in numeric order.

I could not recall if that was accurate for PB/DOS, so I looked it up. I could not find it in the help file, so I dug out the printed manuals for v 3.5.

It's on page 71 of the "User Guide" (not the "Reference Manual").

What you say is correct, except there is one additional restriction that "no one line may have both a line number and a label," whatever that means.

MCM

[Mel Bishop]

..."no one line may have both a line number and a label,"...

That means the syntax:

100 ConvertToUpperCase te$ = ucase$(te$)
-or-
ConvertToUpperCase 100 te$ = ucase$(te$)

Will cause the compile process to go west.

Mike, just out of idle curosity, why are you using line numbers when they are not needed? The last time I used line numbers was when I was programming in GWBasic. (Remember the RENUM command? What a headache refinding the subroutines.)

Please don't misunderstand, you can use line numbers if that floats your boat but I can see no real purpose for them any more.

[Michael Mattias]

>last time I used line numbers was when I was programming in GWBasic

Mr. Luther is the proud owner of some kind of huge MS-DOS legacy application, one which is the very contradiction of the word "legacy" in that it is under continous upgrade, maintenance and enhancement. He has posted requests for ideas and assistance on a fairly regular basis for a pretty long time. (Note the 1998 'join date'. And if I not mistaken he posted on Compuserve's PCVENB prior to that.)

As you know Mel, maintaining a large suite of programs of considerable age and much prior maintenance is not quite the same thing as starting with a empty "*.bas" file.

That is, lots of 'druthers' have already been taken.....

[Mel Bishop]

Point taken. Apologies.

[Bob Zale]

This is illegal:


100 LABEL27:

GOTO 100
GOTO LABEL27

[Michael Mattias]

>This is illegal:

I like direct statements like this.

I am pretty well fed-up with software vendors who would have automatically included the word "currently" in that statement.

MCM