Author Topic: The 65 BASIC Interpreter  (Read 828 times)

Offline Pete

  • Forum Resident
  • Posts: 1982
  • Cuz I sez so, varmint!
Re: The 65 BASIC Interpreter
« Reply #15 on: July 05, 2020, 10:11:59 AM »
Name it: QB60_More. Hey your fault, you asked for a pun.

Pete

Online SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 2594
    • Steve’s QB64 Archive Forum
Re: The 65 BASIC Interpreter
« Reply #16 on: July 05, 2020, 10:28:34 AM »
Name it: QB60_More. Hey your fault, you asked for a pun.

Pete

Asked for a pun, not a punishment...
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline bplus

  • Forum Resident
  • Posts: 4589
  • B+ nots
Re: The 65 BASIC Interpreter
« Reply #17 on: July 05, 2020, 12:58:46 PM »
WOW man ...!
That is great ...i like it !

Ha! I was wondering if shadow man would show up for this!

Offline Pete

  • Forum Resident
  • Posts: 1982
  • Cuz I sez so, varmint!
Re: The 65 BASIC Interpreter
« Reply #18 on: July 05, 2020, 01:40:05 PM »
Asked for a pun, not a punishment...

Oh come on, Steve. Everyone knows you can't spell punishment without pun... unless, of course, you spell it wrong.

Why I put up with wiseacres from Green Acres, I'll never know. ;D

Pete
« Last Edit: July 06, 2020, 01:15:13 PM by Pete »

Offline Pete

  • Forum Resident
  • Posts: 1982
  • Cuz I sez so, varmint!
Re: The 65 BASIC Interpreter
« Reply #19 on: July 05, 2020, 01:41:16 PM »
Oh, Okay. How about...

Q-Beat64. It has a nice beat, and you can debug to it.

Pete

Offline +KZ

  • Newbie
  • Posts: 20
  • an ugly avatar :)
Re: The 65 BASIC Interpreter
« Reply #20 on: July 05, 2020, 02:10:42 PM »
if name it "46BQ"? :P
google translate :0

Offline Ashish

  • Forum Resident
  • Posts: 623
  • The joy of coding is endless.
Re: The 65 BASIC Interpreter
« Reply #21 on: July 06, 2020, 03:15:57 AM »
Good job on this @luke
I'm liking it!
The 65 source code looks complicated. ;D
if (Me.success) {Me.improve()} else {Me.tryAgain()}


My Projects - https://github.com/AshishKingdom?tab=repositories
OpenGL tutorials - https://ashishkingdom.github.io/OpenGL-Tutorials

Offline luke

  • QB64 Developer
  • Forum Regular
  • Posts: 164
Re: The 65 BASIC Interpreter
« Reply #22 on: July 10, 2020, 08:29:26 AM »
After much pain and suffering, we now support the dreaded GOTO (only line numbers for now - no labels). This doesn't really work in the interactive mode, so if you want to try it you'll need to write your program in a file. Also added are CLS and SYSTEM, to make life a little easier.

Huge thanks to Ashish for finding bugs upon bugs and pointing out my sloppy coding!

Offline johnno56

  • Forum Resident
  • Posts: 789
  • Live long and prosper.
Re: The 65 BASIC Interpreter
« Reply #23 on: July 10, 2020, 09:55:44 AM »
How about a more 'classical' name? QBorNotQB... lol or simply: QB65
Logic is the beginning of wisdom.

Offline johnno56

  • Forum Resident
  • Posts: 789
  • Live long and prosper.
Re: The 65 BASIC Interpreter
« Reply #24 on: July 10, 2020, 10:15:17 AM »
In reference to GOTO, please forgive my forwardness, but why? I thought 'that' bane of spaghetti-basic had been 'put down' years ago... Just the thought of a loop performing its function and told part way through to leave the loop and probably never come back... is almost 'cringeworthy' (probably not a real word - but you get what I mean). Let's not talk about how we noobs (ok me) find it difficult to translate goto's into 'basics' that no longer use line numbers... I was just getting used to using subroutines and functions and easy to follow structured listings...

But, that's just my opinion, for what it's worth... lol

Anyway, besides what I think, I hope that you can implement both line numbers 'and' labels without too many headaches...

I need more coffee... I think I'm babbling again...
Logic is the beginning of wisdom.

Offline bplus

  • Forum Resident
  • Posts: 4589
  • B+ nots
Re: The 65 BASIC Interpreter
« Reply #25 on: July 10, 2020, 11:05:09 AM »
In reference to GOTO, please forgive my forwardness, but why? I thought 'that' bane of spaghetti-basic had been 'put down' years ago... Just the thought of a loop performing its function and told part way through to leave the loop and probably never come back... is almost 'cringeworthy' (probably not a real word - but you get what I mean). Let's not talk about how we noobs (ok me) find it difficult to translate goto's into 'basics' that no longer use line numbers... I was just getting used to using subroutines and functions and easy to follow structured listings...

But, that's just my opinion, for what it's worth... lol

Anyway, besides what I think, I hope that you can implement both line numbers 'and' labels without too many headaches...

I need more coffee... I think I'm babbling again...

Ideology goes too far when it bans practicality.

The decision that branches execution flow fundamentally requires a GOTO way down in the machine level. It would be too ironic to ban such a basic thing from Basic. But just because it's not banned doesn't give license to use it in place of ELSE,  LOOP or even EXIT (ha! to Cobalt ;-)) structure because that is not practical either.
« Last Edit: July 10, 2020, 12:10:34 PM by bplus »

Online SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 2594
    • Steve’s QB64 Archive Forum
Re: The 65 BASIC Interpreter
« Reply #26 on: July 10, 2020, 11:13:08 AM »
I, for one, think of GOTOs as an essential part of my coding toolkit.  For many, many things, they just make sense.

Where do you see me use them a ton??

In SUB/FUNCTIONs, as a means to clean up/restore settings before exiting.

For example, I might have a routine which tosses colored text on the screen..

FUNCTION ColoredTextAtPos (foreground, background, font, text$, xpos, ypos)

Now, the first things I want to get is:

D =_DEST: S =_SOURCE
F =_FONT
Oldx = POS(0): OldY = LOC
DC =_DEFAULTCOLOR:  BG = _BACKGROUNDCOLOR

All the current settings to affect my screen...

Then I do my main process, which might have multiple exit points...  If text$ = "", settings for SCREEN 0, 256 color graphic modes, and 32-bit color graphic modes, if the font is monospaced, unicode, or not....

Now some folks might sit down and scheme out some method to include/exclude all those various settings, but I tend to find it easiest to just handle them linearly one by one, myself.

IF text$ = "" THEN GOTO exit_point
IF xpos < 0 OR ypos < 0 THEN GOTO exit_point

I can't always just EXIT FUNCTION, as I may need to reset those initial values I captured, so a label called exit_point makes perfect sense a few lines before the END FUNCTION, so I can do those value resets afterwards.

It's not confusing.  It's not spaghetti code.  Nobody scratches their head reading it, and has a hard time understanding it.  In fact, I'd argue that with proper use of a descriptive label, like exit_point above, that it's *more* readable and self-documenting than many other ways you might write the same code.

GOTO isn't inherently bad.  It's just bad when it's used improperly, and then it's *really* bad.
« Last Edit: July 10, 2020, 11:14:28 AM by SMcNeill »
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline Aurel

  • Newbie
  • Posts: 86
Re: The 65 BASIC Interpreter
« Reply #27 on: July 10, 2020, 11:23:20 AM »
I, for one, think of GOTOs as an essential part of my coding toolkit
...i agree
//////////////////////////////////////////////////////////////////
https://aurelsoft.ucoz.com
//////////////////////////////////////////////////////////////////

Offline johnno56

  • Forum Resident
  • Posts: 789
  • Live long and prosper.
Re: The 65 BASIC Interpreter
« Reply #28 on: July 10, 2020, 07:23:10 PM »
Ok. I will concede that there are pros and cons to including goto... It was not my intention to cause problems. Just voicing an opinion...

Luke. You stated, "(only line numbers for now - no labels)"... But, aren't line numbers, labels? If not what is the difference? Just curious

Logic is the beginning of wisdom.

Offline luke

  • QB64 Developer
  • Forum Regular
  • Posts: 164
Re: The 65 BASIC Interpreter
« Reply #29 on: July 10, 2020, 08:36:12 PM »
For what it's worth, my implementation of GOTO is quite slow compared to the regular control flow constructs so let that be a reason to avoid it :)

There's no avoiding that it's a used statement and so needs to be implemented.

Luke. You stated, "(only line numbers for now - no labels)"... But, aren't line numbers, labels? If not what is the difference? Just curious
The difference is in recognition. Consider this code:
Code: [Select]
10 PRINT X$
lbl: PRINT Y$
It's really easy to recognise 10 as a line number - we just say if we're at the start of the line and see an integer, it's a line number.

With the label, it's just a string of characters. If, instead of "lbl" I had used "BEEP", it would have not been a label but two statements joined by a colon. So far I haven't implemented the extra logic to recognise a label from a command.