No navigation for Label made by LineNumber

[SMcNeill]

Ah! now I see, Menu Search > Go to line... say 23, in Editor, goes to the 23rd line of code that is marked 3 in sample code (with line numbers reversed). That is a problem if you wanted the line that starts with 23(space).

(Also I note the cursor is placed past the end of the line, whereas the cursor is placed at the start of the line when finding line labels with right mouse click on label name.)

Well, if desperate there is still search "23(space)" to find line labeled 23 and of course it will stop at every 23(space) on the way to the line label with a number 23.

So make your labels end with “:”

Then search for “23: “ — you’re not very likely to get too many false positives in that case.  ;)

[FellippeHeitor]

“Search > Go to line...” allows you to jump to actual lines of code, not arbitrary line labels.

If you want to see actual line numbers, switch them on in the View menu. And let us all stop using arbitrary line numbers and finally leave those behind.

[bplus]

I am so past using line number labels, I had heck of time just understanding what problem TempodiBasic was pointing to!

It would be a problem if one were spending allot of time updating old spaghetti code to a more modern format.

[TempodiBasic]

@Bplus

but have you never had spaghetti alla carbonara ? O spaghetti con vongole e pomodorini?   sorry but translation give no idea od what I'm saying....
(spaghetti carbonarahttps://it.wikipedia.org/wiki/Pasta_alla_carbonara? Or spaghetti with clams and tomatoes?https://ricette.donnamoderna.com/spaghetti-alle-vongole-e-pomodorini)

about

I had heck of time just understanding what problem TempodiBasic was pointing to!

if QB64 already checks the existence of number of line of code to what  a Jump instruction (like GOTO, GOSUB, ON KEY , ON  TIMER, ON... GOTO, IF GOTO, IF THEN number of line of code) points
&
if QB64 already puts labels into a list
&
if QB64 already checks for duplicates of labels and of number of line of code
perhaps QB64 can put also number of line of code into that list of labels in use in the code....

but I must remark that
this issue doesn't solve   any actual or previous problem about my code.
The solution of this issue can add only power for navigation into code typed in old fashion.

[STxAxTIC]

I wonder how we would use GOTO if

Code: QB64: [Select]

1. LET a = 50
2. LET b = 50
3.  
4. GOTO a+b
5.  
6. 100:
7. PRINT "This kind of program would work..."
8.  

[xra7en]

I haven't used line numbers and/or labels since the 80's So forgive me on this question:
But why would this topic exists about labels and line numbers?

I use various editors from Komodo (the best), notepad++ and genie to name a few, so use of finding line numbers (except the ones built in to the editor) and labels is moot.
Now I do use labels for DATA statements  - that was an amazing invention whoever came up with it, as in the old days you have to cycle through DATA to get to the spot you want, and even then - prone to errors.

Thanks to pascal early on, I just got used to top down programing (including SUBS/FUNCTIONS in QB) These days I pretty much settle on PHP/SQL and QB64 - and if you do modular programing, it is a simple matter to just hit F2 and find your SUB/FUNCTION and POOF your good to go. Just my 3c worth :P

And you don't get spaghetti sauce all over you.

IMHO!

[TempodiBasic]

Hi

Thanks to join to the discussion STxAxTIC

about your affirmation and code

I have no copy of old BASICA and any of  GWBASICA but I have a copy of old QBASIC, TurboBASIC 1.0, TSRBASIC....
Well making some try
Your suggestion is just a sophism because
1. in QB64 parser gives warning for synthax error
and in DOSBox emulation
2. Qbasic  gives warning for synthax error suggesting the statemente expected
3. TSRBASIC (a TSR interpeter) gives synthax error in the typing the statement GOTO a+b and after also when we press F5 and run program that stops at line of GOTO
4. TurboBasic 1.0 gives error 456: undefined label/line of code at runtime and stops the program


Thanks to read

[TempodiBasic]

Hi xra7en
fine to talk with you

about evolution of programming, from my point of view there is no to talk...

Past
-flow of program from START  to  END
- conditional statements (if goto, if then linenumber/label, if then else, + end if )
- loops (for..next,  while wend, do loop /+until/while)
- GOSUB RETURN (a first attempt to create blocks of  code)
- DEF FN / END DEF
- SUB /END SUB
- FUNCTION /END FUNCTION
- ON COM(n), ON ERROR, ON KEY(n), ON PEN , ON PLAY(n), ON STRIG(n) , ON TIMER(n) , ON UEVENT (a first attempt of programming on event, IMHO these statements use label/number of line of code)
- pointers and dinamic managing of RAM
- Object Oriented Programming
- somethingelse I don't know more actual
Today

the only spin to this thread is the backward compatibility also for navigation of the code...
no more

The solution of this issue can add only power for navigation into code typed in old fashion.

Thanks to share opinions

[STxAxTIC]

Thanks Tempodibasic for squashing that idea for me. I thought I saw it once before in a BASIC-like language, but perhaps not.

Maybe I've been in my own head too long...

Code: QB64: [Select]

1. let(a,50)          :
2. let(b,50)          :
3. print_`should'     :
4. goto_[a]+[b]       :
5. print_+` not'      :
6. anchor_+100.0      :
7. print_+` display'  :
8.  
9. : should display
10.  

[xra7en]

Hi xra7en
fine to talk with you

Hi there!!

You too!

Just thought I would interject,  again, it could just be me, it would seem like we are trying to figure out a way to attach a horses to a car to help with its mechanical isses - if the car doesn't work, we can use the horse (smrk) - Im one of those super-tech-nerds,  I don't have reverse hahah!!

the only spin to this thread is the backward compatibility also for navigation of the code...
no more

Ok so basically (no pun err...), this is so we can just plug in some David H. Ahl game and hopefully it will run right from the (qb4) box? This thread fascinates me for some weird reason.

[SMcNeill]

I wonder how we would use GOTO if

Code: QB64: [Select]

1. LET a = 50
2. LET b = 50
3.  
4. GOTO a+b
5.  
6. 100:
7. PRINT "This kind of program would work..."
8.  

I imagine we could do something like that easily enough, but do you really want to support the spaghetti code it’d generate?

10: CLS
20: CLS, Red
30: CLS, Blue
‘ Junk in between
400: GOTO BackgroundChosen * 10

Now, you let the user choose a color from 1 to 3(Black, Red, Blue) and store it in BackgroundChosen...

An error occurs in the program...

Now, this is has 10,000 lines of code...

How the BLEEP do you trace the error??

And who the FLEEP on the forums would be able to sort through the code provided to help you trace the error?


We can imagine we *could* do it, but I strongly feel that we shouldn’t.  :P

[Ed Davis]

... I thought I saw it once before in a BASIC-like language, but perhaps not.

You did!

Many of the old BASIC's supported "goto expression", where expression is any integer expression.
One for sure was Tiny BASIC, especially Tom Pittman's version.
I _think_ Northstar basic did too.
Also, DDS BASIC - obfuscated Tiny BASIC did - in only 25 lines of C source code!
And of course my slow/stupid BASIC interpreter (written just to run an old version of Star Trek) does too.

[STxAxTIC]

How the BLEEP do you trace the error??

I dunno, vWatch?

I'm feeling weird, like we should swap sides in this argument - shouldn't Steve be supporting the "just git er done" approach against the philosophical idealists like myself? Not that I'm *defending* the thing I suggested. It was just meant to cause people to think (or just plain react).

While we're reiterating that GOTO is potentially harmful, confusing, or redundant, I point out:

... so are global variables
... so is using the TAB character to make white space
... having too many number types (more than one) is confusing and anachronistic
... so are single quotes used as bracketing characters (QB64 is off the hook but I'm pointing at JS and PHP and many others)
... that the double quote as a string opener is overloaded as its closer, so strings cannot be self-embedded
... that we use GOTO all the time in a different guise: SELECT CASE, RETURN, EXIT FOR/DO ... these things are all GOTO moves
... line labels or numbers have no use without GOTO and are equally vestigial
... that QB64 does not inherently encourage proper layering, separation of mechanism from policy, and is a tool for creating spaghetti code with or without the explicit use of GOTO

We should talk more about coding style around here.

[Pete]

I wonder how we would use GOTO if

Code: QB64: [Select]

1. LET a = 50
2. LET b = 50
3.  
4. GOTO a+b
5.  
6. 100:
7. PRINT "This kind of program would work..."
8.  

We have that already, with ON GOTO. The difference is instead of adding variables you determine the possible variable values and assign those values to your GOTO statement. So if under one condition  a + b = 50 and under another a + b  =  100, you'd code...

ON a + b GOTO 50, 100

Now that limits values to between zero and two. You'd need to code a lot of null commas in that goto statement to reach 100!

Actually this reminded me a few times I wanted to just assign a string variable to a GOSUB statement. GOSUB mystring$. Of course this would drive the compiler batty. There's noting to connect the program flow to unless mystring$ was made a constant. So again, there is always ON GOSUB.

Pete

[STxAxTIC]

Ah, thanks Pete. ON <blah> GOSUB <label> didn't occur to me...

As for using run-time variables to mess with program flow, i.e., GOSUB whatever$, you *can* do this in QB64, provided you reinvent everything as a string.

*quickly makes sure his toy language demo's the point*

Ahh, there we go - even supports spaces in the name:

Code: QB64: [Select]

1. let(a,`moo')       :
2. let(b,` cow')      :
3. print_`should'     :
4. goto_[a]+[b]       :
5. print_+` not'      :
6. anchor_`moo cow'   :
7. print_+` display'  :
8.  
9. : should display