BASLOAD

Stefan
Posts: 448
Joined: Thu Aug 20, 2020 8:59 am

Re: BASLOAD

Post by Stefan »

Version 0.2.4 released.

It removes REM statements from the output, and fixes DATA statement handling.
User avatar
ahenry3068
Posts: 1082
Joined: Tue Apr 04, 2023 9:57 pm

BASLOAD. Feature request.

Post by ahenry3068 »

I have a feature request that might be easy to implement.

Quite often in my code I will have a statement like

100 GET X$:IF X$<>"" THEN 100 : REM FLUSH ALL KEYBOARD INPUT 110 GET X$:IF X$="" THEN 110 : REM GET A KEY 120 IF MB<>0 THEN 120 :REM WAIT UNTIL MOUSE BUTTONS ARE RELEASED


Using BASLOAD this now becomes.
FLUSH1: GET X$:IF X$<>"" THEN FLUSH1 GET1: GET X$:IF X$="" THEN GET1 WAITMOUSE1: IF MB<>0 THEN WAITMOUSE1

Thats not so bad for short programs. But in a longer program I might do that several times. And since labels are global I have to use GET2:, WAITMOUSE2, ...etc. It could get confusing. I've already run into this in HANGMAN to a certain extent.

I would suggest a construct to loop back on the same line. Kind of a cross between a BASIC Keyword and a label. I actually thought of REPEAT but that's used as a loop constructor on other versions of BASIC. It could cause confusion. My suggestion is the Keyword THIS

Its not a BASIC Keyword and its not apt to be often used as a label, (at least I can't think of a reason. :))

So the above in BASLOAD if you implemented this feature would be.

Using BASLOAD this now becomes.
GET X$:IF X$<>"" THEN THIS GET X$:IF X$="" THEN THIS IF MB<>0 THEN THIS

Something like REPLINE wouldn't be to bad either, but I think THIS makes for cleaner looking code. :)

EDIT: Might also make it THISLINE if you think thats clearer.
voidstar
Posts: 445
Joined: Thu Apr 15, 2021 8:05 am

Re: BASLOAD

Post by voidstar »

Maybe HERE instead of THIS?

THIS just reminds me of Java. Although C++ has this->foo also.

As a habit I've always put GOTO after the IF, since it is required in all cases except when a line number is used. So it reads
IF X$<>"" THEN GOTO HERE
User avatar
ahenry3068
Posts: 1082
Joined: Tue Apr 04, 2023 9:57 pm

Re: BASLOAD

Post by ahenry3068 »

MarkTheStrange on DISCORD suggested the same keyword "HERE".

Personally, and after thinking about it quite awhile. I'm in favor of PREVLINE,THISLINE,NEXTLINE. Because they are a matched set and in my opinion would contribute to code readability. That being said, I'm not dogmatic about this. This is Stefan's program and he has the final word. I'm finding it very useful right now even without this proposed feature.
Stefan
Posts: 448
Joined: Thu Aug 20, 2020 8:59 am

Re: BASLOAD

Post by Stefan »

BASLOAD version 0.2.5 published.

It fixes the issues with REM removal, I hope.

Some of the tests I've put it through:
  • Load HANGMANB.BAS
  • Add lines with only REM statements at the beginning of the file and in between other lines
  • Add REM statements at the end of line where there are other statements; the colon before the REM statement must be removed
Stefan
Posts: 448
Joined: Thu Aug 20, 2020 8:59 am

Re: BASLOAD

Post by Stefan »

BASLOAD 0.2.6 published.

It's contains bug fixes for the REM statement removal mechanism. After quite a lot of testing by me and Voidstar, I think it now might actually work solidly.
Martin Schmalenbach
Posts: 135
Joined: Tue Jul 21, 2020 10:08 pm

Re: BASLOAD

Post by Martin Schmalenbach »

Stefan wrote: Thu Nov 02, 2023 5:23 am BASLOAD 0.2.6 published.

It's contains bug fixes for the REM statement removal mechanism. After quite a lot of testing by me and Voidstar, I think it now might actually work solidly.
NICE JOB!!

I've just thrown my TinyPascal source code at it, which I just finished turning in to a BASLOADable text file... it's about 1400 lines of source, many of which are REM statements - just over 50% in fact.

BASLOAD 0.2.6 handled them expertly - I've just had the BasLoaded version run and correctly compile my test program with no issues at all.

Sweet!!! :D
mortarm
Posts: 279
Joined: Tue May 16, 2023 6:21 pm

Re: BASLOAD. Feature request.

Post by mortarm »

ahenry3068 wrote: Sat Oct 21, 2023 12:24 am 100 GET X$:IF X$<>"" THEN 100 : REM FLUSH ALL KEYBOARD INPUT 110 GET X$:IF X$="" THEN 110 : REM GET A KEY 120 IF MB<>0 THEN 120 :REM WAIT UNTIL MOUSE BUTTONS ARE RELEASED


Using BASLOAD this now becomes.
GET X$:IF X$<>"" THEN THIS GET X$:IF X$="" THEN THIS IF MB<>0 THEN THIS
I'm not seeing any real net benefits except for a few less characters, and even if you had several these, relative to the whole program, it wouldn't amount to much.
User avatar
ahenry3068
Posts: 1082
Joined: Tue Apr 04, 2023 9:57 pm

Re: BASLOAD. Feature request.

Post by ahenry3068 »

mortarm wrote: Sat Nov 04, 2023 6:47 pm
ahenry3068 wrote: Sat Oct 21, 2023 12:24 am 100 GET X$:IF X$<>"" THEN 100 : REM FLUSH ALL KEYBOARD INPUT 110 GET X$:IF X$="" THEN 110 : REM GET A KEY 120 IF MB<>0 THEN 120 :REM WAIT UNTIL MOUSE BUTTONS ARE RELEASED


Using BASLOAD this now becomes.
GET X$:IF X$<>"" THEN THIS GET X$:IF X$="" THEN THIS IF MB<>0 THEN THIS
I'm not seeing any real net benefits except for a few less characters, and even if you had several these, relative to the whole program, it wouldn't amount to much.
Its completely up to Stefan whether or not he implements this. Really though labels are global. Whenever I'm doing this there's only so many times you use GET1: or FLUSH1: or FLUSH2: before you start to get them mixed up. I did it at least 3 or 4 times while porting over my HANGMAN code to BASLOAD.
User avatar
ahenry3068
Posts: 1082
Joined: Tue Apr 04, 2023 9:57 pm

Re: BASLOAD

Post by ahenry3068 »

Found a minor bug. Its an edge case and it might be hard to address.

Lately I've been coding here in BASIC but also doing some support programs in QB64 or I might not have ever caused this.

QB64 is BASIC but it's more modern so you can Call a SUB just by putting it's name a line alone. No GOTO or GOSUB required.
When I did this in some BASLOAD code by accident. Left out the GOSUB just the GOSUB label alone. GOSUBS and GOTO's after the line were all off by 1 line number in the outputted code.

Like I said an Edge case. This was with the latest version ending in .6

3 Possible solutions.
1. If you find a label ALONE on a LINE. Insert a GOSUB.
2. If you find a label ALONE on a LINE with no code addressing it RAISE an Error and Stop (probably best to begin with)
3. If you find a lable ALONE on a LINE raise a warning. But in the code flush it out. Ignore it.

#1 Would have solved my problem, but then I might not have found my coding Error. I'm really in favor of 2 or 3. Unless you wanted to make #1 a Default and Documented behaviour.
Post Reply