QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: TempodiBasic on December 09, 2018, 09:31:32 am
-
Hi Guys
just playing with Labels....
in old BASIC (IMHO like BASICA and GWBASIC) linenumber is already a label to use for instructions like GOTO and GOSUB...
but also in QBASIC and QB of DOS time if you want to use a linenumber as label you must write it at beginning of the you must specify the number of the line (indeed you can use also as you will not sequential linenumber for this purpuse) also without : at the end for defining the label.
In the same QB if you use the menu command find Label it is able to find only linenumbers that have : after them!
But both onlyNumber of line of code both linenumber of code plus : works for GOTO and GOSUB instructions.
In a similar fashion QB64 IDE doesn't let us jump to a specific linenumber of code, also is used as label for a jump instruction, in the while it let us to jump to the other labels like Namelabel :
Moreover the DAV'sIDE let jump to any linenumber but then it depends from QB64 compiler for the other operations.
If you want to do this experience please copy this code into the QB64IDE
5 PRINT " Press ESCAPE for quitting" 7 PRINT "Press S to stamp message on screen" 9 PRINT "press C to clear message on screen" 10
11 start:
22
23 LOCATE 24, 2:
PRINT " You want this message on screen";
then goto on 21 line of code on the start: label and make rightclick... you can jump to start: label, but you cannot jump to
label 3: and to linenumber 23 also if they are used as labels too.
Is this a case to uniform the behaviour of navigation into code of QB64IDE?
Thanks
-
Line numbers are probably considered depreciated. Most coders use labels now. Maybe that's why it wasn't added to the QB64 IDE. rather than an oversight.
I thought this was smart in QB64 IDE...
ON a GOSUB start, go
So we have two labels, start and go. If you position the mouse on "start" and right click, it asks if you want to jump to the start label, but if instead you position the mouse cursor on "go" and right click, it asks if you want to jump to the go label.
If the developers wanted to add jump to line numbers, I don't think it would be very involved. Maybe you can convince one of them.
Pete
-
I am not seeing a problem?
-
No, no, no! Stop online shopping for skirts from Mars.com and pay attention. Temp is describing the actions of the IDE with the code, not running the code. The IDE has a right click function to jump to line labels, but not line numbers.
Pete :D
-
OK goto line # works too.
-
Oh he still doesn't get it!
1) Paste Temp's code in the IDE.
2) Left click line 24, "GOTO start"
3) Now RIGHT click "start"
... A selection window opens and one of the selections ask if you want to jump to the start label.
Now do the same on the line displaying "GOTO 23"
...If you RIGHT click on the "23" it won't give you the option, in the selection window, to jump to line 23. That's what Temp is discussing.
And yes, stick with basic black. It's after Labor Day, so the white Martian skirt is just simply out of the question. :D
Pete
-
The title of this thread says there is "No navigation for Label made by LineNumber" but there is. :D
OK must be having to type the line number in, that's the problem? ;-))
-
When QB64 parses your code it fills an array with information on labels created by the user. When I wrote the contextual menu in the IDE, I used the information in that array to offer a quick navigation to where the label is created.
Right click a label name next to a GOSUB/GOTO statement and the contextual menu will look like this:
[ This attachment cannot be displayed inline in 'Print Page' view ]
I did not make any effort to add the same functionality to line numbers because (i) they were already deprecated (what is it with you natives mistaking this with deprec*i*ated?) back in QBasic days, although supported, and are by far not recommended practice and also because (ii) it'd be much more work and would also involve having to parse every line of code with any type of math and literal numbers in it to check if such numbers eventually referred to a valid line number - that is, too much work to provide functionality for a *deprecated* method.
PS: You will also notice that right-clicking a label name when the program doesn't finish parsing (when an error is found and you don't have "OK" in the status bar) will probably not offer the contextual menu shortcut either because the array list stops being created once a syntax error is encountered.
-
It doesn't matter. Deprecated will be obsolete in a few years, anyway! :D
Pete
-
Hi
1. Thanks for attention
at this point of discussion we have reached the real issue about Linenumber as Label
please follow my experience
pasting my code posted above
1. right click on the 16th line of code in the SELECT CASE
GOTO 23
and you got no link to jump to 23 line of code used as label....
2. right click on the 18th line of code in the SELECT CASE
GOTO 3
and you got link to jump to line 3 of code used as label....
What I want to note is that the only difference between line of code 3 and line of code 23 is the : used in QB to define a label.
Must the IDE use a one method of manage labels?
@Fellippe
my intention is not to increase your work in QB64 implementation
only to say that the jump instructions are very few... GOTO, GOSUB, ON variable GOTO...
I don't remember if IF condition GOTO is correct in QB...
Thanks again
-
I'd like to see a screenshot of that. We are definitely not seeing the same thing.
Right clicking the 18th line of code that says "GOTO 3" I still get no link to jump to line 3, regardless of it having a colon (:) or not.
-
I don't see it either, and I tried the current and two older versions. All treated 3: or 23 the same. The colon made no difference and no "Jump to..." selection was displayed in right click menu. I would think QB64 was made to ignore colon(s) placed directly after a line number. So yes, a screen shot and the version number of the IDE would help us see what Temp is seeing.
Pete
-
Hi
1.
I must agree with you (nothing rises up in either the situations...and because I am not able to reproduce also i again these results... sob!? What can do a glass of good wine like Vulka! Just 12° ) and I'm sorry...
2.
Just to not waste your time and your efforts to answer me I go on with linenumber issue but it is no a my need.
thinking about the list of labels already made by QB64 parser ...
I must imagine that to get no error no linenumber or label there must be in the code a linenumber (a number with/without :) or a label (descriptor + :) that the parser can find...
in this case linenumber (in the parser view) is just a label with exception of : at the end of the name
if it is so... we can use linenumber with value inverse to their position and the code works in the same manner....
21 PRINT " Press ESCAPE for quitting" 19 PRINT "Press S to stamp message on screen" 17 PRINT "press C to clear message on screen" 16
15 start:
4
3 LOCATE 24, 2:
PRINT " You want this message on screen";
2
and it seems to work in the same manner....
so I can argue that parser already does this work to check the being of the label or linenumber pointed by a Jump instruction...
and when it puts a label into the list, it is already able to put linenumber of Jump instruction
from wiki the jump instructions are:
ON COM(n) (event statement) executes when there is a value in the serial port specified. NOT IMPLEMENTED!
ON ERROR GOTO (event statement) executes when a program error occurs
ON KEY(n) (event statement) executes when a keypress or keypress combination occurs.
ON PEN (event statement) executes when a PEN event occurs. NOT IMPLEMENTED!
ON PLAY(n) (event statement) executes when the background music queue is low. NOT IMPLEMENTED!
ON STRIG(n) (event statement) executes when a joystick button event occurs. NOT IMPLEMENTED!
ON STRIG(n) (event statement) directs program flow upon a button press event of a game controller device.
ON TIMER(n) (event statement) executes when a timed event occurs. QB64 can use multiple numbered timers.
ON UEVENT (event statement) executes when a user event occurs. NOT IMPLEMENTED!
ON...GOSUB (event statement) branches to a line number or label according to a numerical ordered list of labels.
ON...GOTO (event statement) branches to a line number or label according to a numerical ordered list of labels.
IF conditionStatement GOTO lineLabel
and of these only 9 are implemented!
and just to close with a smile here my spaghetti code...
1600
LOCATE 3, 2:
PRINT " press I for IF..GOTO or O for ON...GOTO";
21 PRINT " Press ESCAPE for quitting" 19 PRINT "Press S to stamp message on screen" 17 PRINT "press C to clear message on screen"
15 start:
100
4
3 LOCATE 24, 2:
PRINT " You want this message on screen";
2
101
PRINT "Press 1 for quitting" PRINT "Press 2 to stamp message on screen" PRINT "press 3 to clear message on screen"
33 LOCATE 24, 2:
PRINT " You want this message on screen";
Try it! It must be good, spaghetti is italian food!
:-)
-
Actually spaghetti is Chinese but when Italians make it, you're not still hungry afterwards!
Well, that's not exactly true... although spaghetti is Sicilian, and being part Sicilian I can tell you that has almost nothing to do with being Italian! The Chinese did have a form of pasta though.
Anyway "Italian pasta is different from the Chinese one, ingredients and way of preparing." taken from a website article.
Don't worry about the line number thing. It was an interesting conversation.
Pete
-
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.
-
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. ;)
-
“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.
-
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.
-
@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 (https://it.wikipedia.org/wiki/Pasta_alla_carbonara)? Or spaghetti with clams and tomatoes?https://ricette.donnamoderna.com/spaghetti-alle-vongole-e-pomodorini (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.
-
I wonder how we would use GOTO if
100:
PRINT "This kind of program would work..."
-
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!
-
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
-
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
-
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...
print_`should' :
goto_[a]+[b] :
anchor_+100.0 :
print_+` display' :
: should display
-
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.
-
I wonder how we would use GOTO if
100:
PRINT "This kind of program would work..."
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
-
... 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.
-
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.
-
I wonder how we would use GOTO if
100:
PRINT "This kind of program would work..."
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
-
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:
print_`should' :
goto_[a]+[b] :
anchor_`moo cow' :
print_+` display' :
: should display
-
@ Ed Davis
Hi
I think that
yes you're right about some BASICs do this jump but not QB (that is the goal of emulation of QB64) and not Dartmouth BASIC (the original BASIC) do this kind of jump with GOTO, so IMHO those are mutant BASICs (GOTO variable) in the family of BASIC (GOTO fixpoint by label or line of number).
https://www.dartmouth.edu/basicfifty/basic.html (https://www.dartmouth.edu/basicfifty/basic.html)
see here original manual of Dartmouth BASIC.