Might be a bad idea. Clear all variables?

[sarossell]

I'm guessing I'm suffering from bad habits from the 80s, but I miss having a command to clear all variables.

Sinclair BASIC had a command; "CLEAR" that simply cleared all string and numeric variables to nil. I don't recall if it affected arrays.

Luckily, my other old bad habit of prepending all variables with "v." may allow me to create a function that finds all variables in the source code and then clears them. We'll see.

Hey, I literally went from Dartmouth BASIC IV on a teletype to Timex/Sinclair 2068 BASIC to Liberty BASIC with no formal training. I'm amazed I can achieve anything sometimes.

Any thoughts?

:@)

Update:

I've really stepped into an unexpected quandary here. I've managed to get the code to find all unique variables and arrays, but I can't for the life of me figure out how to clear them. I've tried eval$, replstr$, remstr$, and even byref. I also considered having the code write a separate program and try to include or merge the code into the existing in real time.

Now this isn't me complaining. I'm just trying to see the world of BASIC as LB has it laid out. I was surprised to find that LB doesn't have a Clear command to clear variables or an Include command to merge code. I'm curious why these have not been a topic of discussion before.

At the very least, I can run the code to generate a list that I can then manually add to the original program to make sure I don't miss any variables. But this is not quite what I was shooting for.

:@)

[honkytonk]

No need to put: "V" in front of the variables
Look at this:

[clear] 'New "button or menu or other.
var1 = 0: var2 = 0: var3 = 0: a$ = "": b$ = ""; c$ = "" '... ect ...
wait

On the Sinclair it was a "Clear" button.
I can make you a Sinclair keyboard simulator, you just have to do the rest.

[sarossell]

Not exactly what I was hoping for.

[mknarr]

I'm just curious. Can you give an example of why it's necessary to clear all variables. I have a commercial program of over 17000 lines and over a 1000 arrays and string and numeric variables. Yes some are cleared at times and others are used between sections of code not just for x=y to z. You may have a very good reason for clearing all variables at one time but in my case I would have to dig through the program to find out which one could be cleared and which ones would cause a disaster if cleared.

[honkytonk]

Jan 17, 2020 11:03:29 GMT -5 mknarr said:

I'm just curious. Can you give an example of why it's necessary to clear all variables. I have a commercial program of over 17000 lines and over a 1000 arrays and string and numeric variables. Yes some are cleared at times and others are used between sections of code not just for x=y to z. You may have a very good reason for clearing all variables at one time but in my case I would have to dig through the program to find out which one could be cleared and which ones would cause a disaster if cleared.

It's just nostalgia for the logic of the Sinclair keyboard.
Who wouldn't have it

[sarossell]

mknarr:

Certainly a valid question. My programming experience has been limited to Dartmouth BASIC IV from 1963, Sinclair BASIC from 1983 and Liberty BASIC from 1992. With the exception of Liberty BASIC, over time, I've picked up a lot of bad programming habits. But even more damning, I'm a bit OCD...Okay, a lot OCD. So, between HAVING a Clear command in Sinclair BASIC and WANTING a clean slate between file access routines in the same program, I like the idea of being able to start with fresh variables each time I load a new file to work on with a program. I've been bitten in the backside more than once by a variable that had old data while processing a new file.

:@)

[honkytonk]

Jan 17, 2020 11:50:08 GMT -5 sarossell said:

mknarr :

Certainly a valid question. My programming experience has been limited to Dartmouth BASIC IV from 1963, Sinclair BASIC from 1983 and Liberty BASIC from 1992. With the exception of Liberty BASIC, over time, I've picked up a lot of bad programming habits. But even more damning, I'm a bit OCD...Okay, a lot OCD. So, between HAVING a Clear command in Sinclair BASIC and WANTING a clean slate between file access routines in the same program, I like the idea of being able to start with fresh variables each time I load a new file to work on with a program. I've been bitten in the backside more than once by a variable that had old data while processing a new file.

Just initialize the variables before or after loading or in the right other place.

[sarossell]

My current project has 38 variables and five arrays. Yes, I could manually clear every single one. Just seems silly to assuage my OCD with so much effort when nearly forty years ago, all I had to do was type "10 CLEAR". Besides, I clearly indicated that I was approaching this issue from an academic stance in the interest of learning why LB doesn't include such a command. I've mentioned that I have picked up some bad programming habits in the past. Learning a lesson about why this command is not available may help to correcting some of those habits. I spent a couple of years attempting to learn object-oriented programming only to realize (and have confirmed) that OOP is just the newest (relatively) fad in programming and not the end-all-be-all some of the younger programmers have been conditioned to think it is. It has it's place. So, full circle, some ideas have their place. Ergo; CLEAR.

:@)

[Chris Iverson]

I had a suspicion that the main use of the CLEAR command was to free up RAM used by the program, and that it basically winds up clearing all variables as part of that.

Looking up references to Sinclair BASIC leads me to believe that my guess is correct, or at least in the ballpark; the CLEAR command clears out all RAM used by all programs, resetting variables, the GOSUB stack, the screen, the screen position, and (optionally) moves RAMTOP to the specified value, to preserve more memory when performing a NEW.

I see two reasons for the existence of this command, neither of which truly apply to LB.

The first is memory pressure; if you're running out of space for data, CLEAR can help clear up space you might otherwise be unable to.

The second is more a side-effect of the fact that all BASIC commands in a Sinclair BASIC system, like a ZX Spectrum, were also essentially system commands that you could run as you choose. If you're not currently running a program, and want to clear out any space that's not being used, you can manually run CLEAR yourself. I suspect this is how it most often got used; the fact that it's available to executing programs is a side-effect of how all commands were designed.

I did find a note in a ZX Spectrum manual that issuing a RUN command would also run an implied CLEAR statement, which makes sense. Starting a new program means the old program's data has to be purged to make room for the new executing program.


None of this really applies to LB; while LB has a memory limit, it's one that you're unlikely to hit just doing basic variable programming. You pretty much have to read in a LOT of data, create GIGANTIC arrays, or draw a LOT of graphics(without erasing) to come close.

The second part, clearing out system RAM when a program is done executing, or to free up RAM for other things, isn't something that a user-mode program in ANY modern OS has to concern themselves with. RAM is managed by the OS, and the handling of it is made opaque to every running program due to things such as segmentation, paging, and virtual memory. The reason commands like PEEK and POKE don't exist is because they literally can't in a modern system; there is so much going on when it comes to memory mapping in a modern system that you wouldn't be able to get useful results with those commands, anyway, unless you had a kernel-level view of and access to the system.



If you want some way to be able to return execution to the beginning of your program without flat-out restarting it, the best thing to do would be to initialize variables to empty before using them(or make sure their first use is assignment, and not reading), and then jump to the initialization block if you want to restart. That way, any values they currently have are overwritten before being used, anyway.

In fact, the only variables you'd have to initialize are those that you read before you assign them. If the first thing you do with a variable in a program is assign a value to it, then you don't need to worry about clearing it, or initializing it. Whatever garbage value it has will be overwritten by your program before affecting anything, anyway.

[Carl Gundel]

Jan 17, 2020 12:07:05 GMT -5 sarossell said:

My current project has 38 variables and five arrays. Yes, I could manually clear every single one. Just seems silly to assuage my OCD with so much effort when nearly forty years ago, all I had to do was type "10 CLEAR". Besides, I clearly indicated that I was approaching this issue from an academic stance in the interest of learning why LB doesn't include such a command. I've mentioned that I have picked up some bad programming habits in the past. Learning a lesson about why this command is not available may help to correcting some of those habits. I spent a couple of years attempting to learn object-oriented programming only to realize (and have confirmed) that OOP is just the newest (relatively) fad in programming and not the end-all-be-all some of the younger programmers have been conditioned to think it is. It has it's place. So, full circle, some ideas have their place. Ergo; CLEAR.

Well, as the language implementor I can say that in my youth I was not taught the usefulness of CLEAR.  The other languages I've used over the years don't include an equivalent as far as I know.

Since then I've never really found a use for it.

I'm not sure anyone else has petitioned to have it added.

I hope this at least satisfies your curiosity. 

The purpose is to essentially reset the program so you can in effect start from the beginning?

-Carl

[sarossell]

Thanks for chiming in guys! I really appreciate your input.

@chris Iverson: Your comment about an initialization block for variables sounds about right in this context. It's a bit like having to declare all variable types in other languages (which is one reason why I like LB, since it doesn't require that).

@carl Gundel: I'm sure your design choices for LB are routed in logic well outside of my wheelhouse. I'm just learning as I go, and found myself wondering why the pink Lego (Clear) was missing. In answer to your question, yes, the idea is essentially to reset the program variable state without having to restart the program. As a technical writer on some high-profile military and government projects, I observed on more than one occasion the requirement for the programmers to do exactly that - and they hated it. I just assumed my old pink Lego; the CLEAR command was a given. I was wrong! Now I'm just tyring to learn why.

On a related subject, may I venture to ask why the Include command is also not implemented? Again, I must stress, I'm not criticizing in the least. Just trying to learn how to do things correctly.

:@)

[alincon]

This code may not be exactly what you need, but I use it with windows that have a lot of textboxes.

First make a string variable with the unique parts of all the text box names:

   tntFields$ = "Ssn 9 Phon 10 Zip5 5 Zip4 4 Brm 1 Size 2 Incm 5 SDate 6 EDate 6 IDate 6 RDate 6"
   tntFields$ = tntFields$ + " TRnt 5 ARnt 5 1Rnt 5 Tot 5 Lld 25 Nam 25 Adr 40 Cty 20 Sta 2 Cvn 8 Pjt 10"


I put the numeric fields first so that I can do this:

for dx = 1 to 30 step 2
   v$ = "#tw.tb" + word$(tntFields$,dx)
   Stylebits #v$, _ES_NUMBER, 0, 0, 0
next
   
'sets character limits for each field
   for n = 1 to 44 step 2  
       v$ = "#tw.tb" + word$(tntFields$, n)
       call tbLimit hwnd(#v$), val(word$(tntFields$, n+1))
   next


Then I can check for blank fields:

for tf = 1 to 15  'check fields for blanks using handle variables
       v$ = "#tw.tb" + word$(tntFields$,tf)
       #v$, "!contents? tf$"
       if tf$ = ""  then print error message        
   next


And here's the clear variable code:

  for tf = 1 to 15  'blank fields.  
       v$ = "#tw.tb" + word$("Nam Ssn Lld Adr Cty Sta Zip5 Zip4 Phon Incm Eth Brm Cvn Pjt Size",tf)
       #v$, ""
   next


and the sub with the dll to limit text

sub tbLimit htext,hlmt

   calldll #user32, "SendMessageA",htext as word,_EM_LIMITTEXT as word, _

       hlmt as word, 0 as long, r as long

   end sub



[Rod]

Include, Clear hmmm... we are nineteen years in to this modern BASIC and not one person has asked for Clear, a few have asked for Include. But we have shouted them down. When you pop out of a Sub it’s all cleared. When we copy in a Sub it’s included. Old processors had needs, less so now.

The need for clear was memory, no restrictions now and in any event garbage collection recovers it all automatically. Subs help the process by releasing all the local variables automatically. The need for include was memory too, because the IDEs could not cope with large programs. So they needed paged in and out of memory. I think it was ram verses disc, the program had to be contained within ram. These restrictions are long gone.

You could not not in your lifetime write a program big enough to choke current IDEs.

still you made us think.

[sarossell]

Rod :

Interesting thought...If I enclosed the entire app in one subroutine, then simply running the subroutine again would clear all the variables, Yes? Hmmm....

Update: Whoo Hoo! And that's me learning stuff! Who says you can't teach an old dog new tricks? That works a treat! Thanks everybody!

[sarossell]

alincon:

Very clever indeed. I do like that Word$ command. Any idea of a quick way to count the number of words in a string other than the obvious loop and incremented counter? I don't think there's a command for that.

source$ = idecode$()
for n = 1 to time$("ms")
 w$ = word$(source$,n)
 if w$ = "" then exit for
next
print n;" words total."