Declaring Variables

bbc micro/electron/atom/risc os coding queries and routines
Post Reply
User avatar
BeebMaster
Posts: 3621
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

Declaring Variables

Post by BeebMaster » Mon Jul 20, 2020 12:38 pm

As a result of an error in an ONERROR construction (which skipped a line which declares a variable, but doesn't skip the next line which manipulates the variable), I discovered that it isn't necessary to declare variables in advance in BBC BASIC in order to refer to them.

I'm sure this must be known about already, but I've never noticed it before.
capture35.png
Manipulating an undeclared variable assigns a value of zero for a numeric variable, or empty string for a string variable, without giving an error. Could be a slight space and speed saving method if you can guarantee that the first mention of a said variable has a null value.
Image

julie_m
Posts: 232
Joined: Wed Jul 24, 2019 9:53 pm
Location: Derby, UK
Contact:

Re: Declaring Variables

Post by julie_m » Mon Jul 20, 2020 2:59 pm

It's a side-effect of BBC BASIC's priorities.

The British dialects of BASIC protest if you try to read the value of a variable before it has been assigned. (Microsoft BASIC just silently creates such a variable, with a value of 0 or an empty string; sending many a hapless programmer on a wild goose chase when a variable fails to update.)

What happens with a reassignment statement such as X=X+1 is, the interpreter sees X= and immediately decides to prepare a space to store the variable X in. And once that is done, there is now an entry for X in the variables table. So when it tries to evaluate the right-hand side of the equals sign and sees X+1, there now is such a variable as X!

I've done some experimenting with random junk in memory, and it seems always to initialise these variables to 0 or "" every time.

User avatar
jgharston
Posts: 4118
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Declaring Variables

Post by jgharston » Mon Jul 20, 2020 3:50 pm

It doesn't seem to initialise variables to a null value, it's *specified* to initialise variables to a null value.

It can be very useful for things like cleanup code where you don't know if something might exist or not, or initialisation where you want to be able to call the initialiser multiple times, see:
http://beebwiki.mdfs.net/Forcing_a_variable_to_exist

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.32
(C) Copyright J.G.Harston 1989,2005-2020
>_

julie_m
Posts: 232
Joined: Wed Jul 24, 2019 9:53 pm
Location: Derby, UK
Contact:

Re: Declaring Variables

Post by julie_m » Mon Jul 20, 2020 6:31 pm

Well, my excuse is, I have never implemented a version of BBC BASIC from scratch! Nor have I paid much mind to the internals; but I would fully expect at least a Model B not necessarily to zero out the variable it was creating, but just to use whatever garbage might already be sitting in that bit of memory on the premise that it's expecting to initialise it with a concrete value.

Coeus
Posts: 1814
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: Declaring Variables

Post by Coeus » Mon Jul 20, 2020 6:50 pm

julie_m wrote:
Mon Jul 20, 2020 2:59 pm
What happens with a reassignment statement such as X=X+1 is, the interpreter sees X= and immediately decides to prepare a space to store the variable X in...
I wonder if that is deliberate choice or just a quirk of implementation. In one sense the more obvious approach would be to call the expression evaulator first which would leave a result in either of the integer, FP or string work areas and then process the assignment but whichever way it means storing an address temporarily - either the address of the start of the variable name in the program line or the address of the variable to be assigned.

As far as program semantics go, this approach allows the programmer to write less code while still avoiding the situation where one mis-spells a variable name so that a value is assigned to one variable and then the value read from one with a similar but not identical name.

julie_m
Posts: 232
Joined: Wed Jul 24, 2019 9:53 pm
Location: Derby, UK
Contact:

Re: Declaring Variables

Post by julie_m » Mon Jul 20, 2020 9:51 pm

Coeus wrote:
Mon Jul 20, 2020 6:50 pm
I wonder if that is deliberate choice or just a quirk of implementation. In one sense the more obvious approach would be to call the expression evaulator first which would leave a result in either of the integer, FP or string work areas and then process the assignment but whichever way it means storing an address temporarily - either the address of the start of the variable name in the program line or the address of the variable to be assigned.
If I was implementing a BASIC interpreter and trying to squeeze every bit of use out of memory, I probably would have done it Sophie's way, I've already searched the variable table, as soon as I saw the assignment, and know I'm creating a brand new variable (if I had been asking a variable what it was holding, I would have errored out with 26 No such variable; but in this case I'm telling). So I've reserved some space from the heap, adjusted my pointers accordingly; and I wind up with the address of my brand new variable, as the place to store something. Now is the first time I look to the right of the = sign and begin evaluating the expression. If that happens to include the new variable I have already made a space for in the variable table, the search will just succeed and return whatever the new variable had been initialised with (and if I were expecting to write a new value into it anyway, I might not even have bothered zeroing it out, if it was only going to be overwritten with a new value straight away).

Interestingly the Spectrum does it the opposite way round; assigning a variable to itself gives error 2 Variable not found. The Spectrum maintains its variables even across alterations to the program unless you deliberately use CLEAR. (Unlike the ZX81, though, variables don't get SAVEd with a program.) Every time a new variable is created, or a string length changes, the whole variable table has to be moved around. And it evaluates its expressions before it is fully sure what to do with the result. I think there is a stack-based virtual machine underneath it all, which would explain why it processed the right hand side of a LET statement before the left; the variable assignment itself must be a stack operation. The pre-entry syntax check will mean it already knows everything is clean.

But, you have to pick an order; either you decide where you're going to stick the result and then you stick it there, or you decide what you're going to do with the result of the next calculation before you calculate it. The behaviour on assigning a brand new variable to itself will depend on your choice.

Post Reply

Return to “programming”