Understanding scope of variables

[georgeo]

Hi everyone,

In ZXBASIC, is this a valid program?

Code:

function myFunction( name$ as string ) as uinteger
    dim length, n as ubyte
    dim total as uinteger = 0

    length = len(name$)

    if length=0 then
    return total
    end if

    for n = 0 to length-1
    total = total + code(name$(n))
    next n
   
    return total
end function

REM Main program
dim n as ubyte
dim ans as uinteger

n = 14
ans = myFunction("Hello")

print "Answer = " + str$(ans)
print "n = " + str$(n)

stop

I have a variable labelled 'n' in both the top-level program and a function. I believe, in the function, 'n' is a different, locally defined variable, which is deleted when the function ends.

Would the same work, if I replaced the function with a subroutine (accepting I couldn't return an answer in the same way)?

I ask as I am seeing unexpected behaviour in my program (not the one above, a much longer program) and one possibility is that I'm using the same variable names for different entities in both the top-level program and subroutines.

Thanks in advance for any help

[georgeo]

Actually, my question is more related to subroutines than functions. So, is the following code valid:

Code:

sub myFunction( byref total as uinteger, name$ as string )
    dim length, n as ubyte

    length = len(name$)

    if length=0 then
    return
    end if

    for n = 0 to length-1
    total = total + code(name$(n))
    next n
   
    return
end sub

REM Main program
dim n as ubyte
dim total as uinteger

n = 14
myFunction(total, "Hello")

print "Answer = " + str$(total)
print "n = " + str$(n)

stop

---with variables labelled 'n' in both the main program and the subroutine.

Thanks again

[RandomiserUsr]

I believe scope in ZX BASIC is global and even if you include other .BAS files you have created, it seems that they all get collated then compiled as one.
Not sure if this answers your question ?

[boriel]

I believe scope in ZX BASIC is global and even if you include other .BAS files you have created, it seems that they all get collated then compiled as one.
Not sure if this answers your question ?

Yes, #include just puts the BASIC code at the place where the #include was placed.
Another feature for libraries is still in progress.

[boriel]

Actually, my question is more related to subroutines than functions. So, is the following code valid:

Code:

sub myFunction( byref total as uinteger, name$ as string )
    dim length, n as ubyte

    length = len(name$)

    if length=0 then
    return
    end if

    for n = 0 to length-1
    total = total + code(name$(n))
    next n
   
    return
end sub

REM Main program
dim n as ubyte
dim total as uinteger

n = 14
myFunction(total, "Hello")

print "Answer = " + str$(total)
print "n = " + str$(n)

stop

---with variables labelled 'n' in both the main program and the subroutine.

Thanks again

Both SUB and FUNCTIONS are the same (with the small difference that FUNCTIONS are expected to return a value).
When you DIM a variable within a function or sub, it's a *local* variable, and will be used only in that scope and destroyed upon exiting that scope. If there's another variable with the same name in an outer scope (i.e. the global one) this variable is "shadowed" by the LOCAL one and not accessible. So your program is OK (and use a Function, it's also OK.

If you don't use DIM within a FUNCTION / SUB, the global variable will be used *if already declared*. If it's not declared, an implicit local variable is then created (which again is destroyed upon exiting). If you don't want this to happen, compile with --explicit, which will require every variable to be declared with DIM before use.

This is very counterintuitive:

Code:

SUB test1()
    n = n + 1   ' Declares a local variable n, there's no previous n declared
    PRINT n
END SUB

DIM n as UByte = 3

SUB test2()
    n =  n  + 1   ' Uses n from the global scope because there's one already declard
    PRINT n
END SUB

SUB test3()
    DIM n = 5
    n =  n  + 1   ' Uses n from the local scope because it's declared
    PRINT n
END SUB

test1
test2
test3

So to avoid test1() to implicitly declare a local var, compile with --explicit

[georgeo]

Hi Boriel,

Thanks. That example makes things very clear. I think, in practice, using --explicit is a good idea to avoid most unexpected consequences. It is still important to watch out for previously defined values being picked up by subroutines, as in test2(). I guess putting function and subroutine definitions before the main program avoids that risk.

Sadly, I'm seeing an issue using --explicit with the print42 library, as I'll explain in a new thread.

Thanks again,