Bug in BASIC?

I have a question about whether the following is a bug:

The procedure PROCdmy / PROCdmy2 is provided in an external library so the actual parameters used in the definition are not necessarily known to the user, these should be LOCAL to the procedure so it shouldn’t matter.

   10REM >Test
   20x=60
   30PRINT "x=";x;" (should be 60)"
   40PROCdmy(FNBB("B10"),y,0.6)
   50PRINT "x=";x;" (should be 55)"
   60PROCdmy2(FNBB("B10"),y,0.6)
   70PRINT "x=";x;" (should be 55)"
   80PRINT "FNBB(""B10"")=";FNBB("B10");" x=";x
   90END
  100:
  110DEFPROCdmy(x,y,r)
  120ENDPROC
  130:
  140DEFPROCdmy2(xx,y,r)
  150ENDPROC
  160:
  170DEFFNBB(x$)
  180x=0:y=0
  190CASE x$ OF
  200WHEN "B10":x=55:y=40
  210ENDCASE
  220=x
>RUN
x=60 (should be 60)
x=60 (should be 55)
x=55 (should be 55)
FNBB("B10")=55 x=55
>

I am using the function FNBB("B10") to generate values for x and y, then using those in the procedure call to an external library (which works) but after the library call x has the wrong value.

My understanding of BASIC V always was that every variable is global, unless explicitly stated in a procedure with the LOCAL statement.

FN/PROC parameters are also local so the x in PROCdmy(x,y,r) is given the value 55 and the value is restored when the procedure ends

Colin is correct – however the important thing to note is that the parameters are local for the duration of the FN/PROC body (as expected) and for the evaluation of the parameters before the body is executed (unexpected compared to most other programming languages). So because PROCdmy accepts an ‘x’ parameter, “PROCdmy(FNBB(...)...)” will cause the ‘x’ variable accessed by FNBB to be PROCdmy’s local version of x instead of the global version.

Yes and if it was considered ‘correct’ behaviour you’d expect

PRINT FNx(1, FNBB("B10"))

DEF FNx(x, y) = x

to return 55 and not 1

And the moral of today’s story:

Local names <> Global names

;-)

Just out of interest, I wonder what ABC makes of the above…

Local names <> Global names

In describing BBC BASIC I would rather say:

There is only one namespace for variables.

the parameters are local for the duration of the FN/PROC body (as expected) and for the evaluation of the parameters before the body is executed (unexpected compared to most other programming languages)

This comes about naturally from the above. When a FN/PROC is executed, the current value of a formal paramenter variable is pushed on the stack and the variable is initialised with a null value. Only then is the actual parameter evaluated and the formal parameter variable given its value. Hence that last stage of evaluation will find that if it uses a variable which is also a formal parameter, it will have either a null or unexpected value – see below.

Because formal parameters are actioned in turn, an earlier value might be used in a later evaluation, which is even more confusing. ;-)

It is nice to know that it is a feature, not a bug. I shall try to remember not to use a function as an input parameter to a procedure where the function alters a global variable which has the same name as the local parameter variable used in the procedure definition line, as the global variable may be corrupted.

This makes it important that when providing a library procedure or function, the acual parameter variable names used in the definition must be explicitly quoted.

This makes it important that when providing a library procedure or function, the acual parameter variable names used in the definition must be explicitly quoted.

I’d counter that this demonstrates one should never use function calls as parameters – it’s never completely safe and is a maintenance nightmare. Inherited localness in subordinate functions is tricky enough when done deliberately.

This is worrying. When validating input, I frequently use things like

A$=FNtrim(FNupcase(A$))
FNtrim strips leading and trailing spaces,
FNupcase converts all (English) characters to uppercase.
Both functions use local variables, often A$ and I%

If I read the above correctly, this might result in empty strings.

I believe that the only time you’ll run into problems is if you have a situation like the following:

Outer(Inner())

• Outer is a function/procedure which has an argument ‘Foo’ in its argument list
• Inner is a function which attempts to read/write a global variable also called ‘Foo’

If Inner is invoked anywhere within the evaluation of Outer’s arguments then you’ll encounter problems (e.g. Outer(Middle(Inner())) is dangerous, as is Outer(Middle()) if Middle calls Inner from its body)

I think this may also extend to if you directly reference a global (or any other variable from outside Outer’s scope) within the argument list, e.g.:

A$="A"
B$="B"
Outer(B$, A$)
...
DEF PROCOuter(A$, B$)

I think this will have the effect of calling Outer(“B”, “B”), because the read of A$ that occurs for determining the value of the second parameter will actually be reading the local value from Outer’s call frame.

Inner is a function which attempts to read/write a global variable

It’s worse than that Jeffrey. Here’s an example that goes wrong without explicit LOCAL and without global variables, in this case because of RETURN:

A$="KO"
B$=FNrev(A$):PROCshow(B$):PROCshow(A$) :REM Construction 1

PRINT"Compare and contrast"
A$="KO"
PROCshow(FNrev(A$)):PROCshow(A$)       :REM Construction 2
END

DEFFNrev(RETURN A$):A$=RIGHT$(A$)+LEFT$(A$):=A$
DEFPROCshow(A$):PRINTA$:ENDPROC

Unless you already knew that those two constructions would behave differently, not when challenged, but without even thinking about it, then you must concede that using function calls as parameters has arcane and complex consequences.

Outer(“B”, “B”)

No, it doesn’t work like that. Things get stacked then changed.

I say “explicit LOCAL” because DEFPROCa(b) is an implicit LOCALb.

Alan used the example

A$=FNtrim(FNupcase(A$))

and suggested

If I read the above correctly, this might result in empty strings.

I don’t see why ‘empty’ would be likely. ‘Wrong’ is entirely possible though, as is random memory access, crashing and things catching fire.

For example, your FNupcase might use a global to reference a character table or territory number. Let’s say that’s case%. If, at some point in the future, you change FNtrim and happen to add a case% parameter to it, then FNupcase stops working but only as a parameter.

The following is robust:

A$=fnupcase(A$):A$=FNtrim(A$)

It’s less than 10% slower, and 100% safer.

And if anyone thinks RETURN is an unusual construction, here’s a common usage case:

A$="This is an example"
REPEATPRINTFNword(A$):UNTILA$=""
END

DEFFNword(RETURN A$):LOCALZ%,B$
WHILEASCA$=32:A$=MID$(A$,2):ENDWHILE
Z%=INSTR(A$+" "," "):B$=LEFT$(A$,Z%-1):A$=MID$(A$,Z%+1)
=B$

…