08-15-2023, 10:07 PM
I don't know what you are doing to keep track of variables in micro(A). But it would have to be done in one of two ways.
An UDT which looks more or less like this:
This is just for starters and is only for example. "ident" is the name of the variable. "kind" must be called that way, not "type" since it's a reserved word in most modern BASIC's. This decides whether to use "var", "ptr" or "str" in micro(A). "isarray" then enables an external rule for a memory pool to attach to this element of this UDT. In other words, it could be zero for a regular variable in micro(A) and otherwise, the maximum number of elements in the array.
"scope" is the important one here. It could be set to zero so all variables are global. The way to set it, however could be a pain. Some manuals like that for Free Pascal talk about "reference levels" which causes discouragement. But if the author of the interpreter expects it to be useful enough to allow nested calling of functions, this problem has to be attacked.
This "scope" thing could help in checking to protect variables in another scope. The author of the interpreter could choose how to protect the global variables inside an user-written function. Could always do it, like in Python unless "global" keyword is offered. Now creating local variables should rely on scope. When the user-defined function exits, just search the variable table for candidates with the same scope and remove them. Please do not complicate the situation LOL by seeking to replicate "STATIC" technique in QuickBASIC/Qbasic/QB64. Must rely here on global variables that preserve value between function calls.
Otherwise the suggestion is one I made earlier. Reserve a limited number of variables. Like five per type. They will be used only as parameters for the user-written functions. This is similar to how Perl and Powershell handle things. The drawback is that it limits having one user-written function from calling another one. The author of the interpreter doesn't want to keep a large amount of memory for variables that cannot be used in the main program.
I was going to disturb bplus about this a few months ago. Keep 10 variables around to be used only for user-defined functions in "Oh" interpreter. Keep another 10 variables if you really want to be ambitious, and have one "Oh" interpreter instance call another instance. Which would bring about replicating COMMAND$. Those variables should not be used for any other purpose. They should be just volatile helpers like $1, $2, $3 etc. in "gawk" and Perl, like replaceable parameters in MS-DOS batch language.
An UDT which looks more or less like this:
Code: (Select All)
type vardecl
ident as string
kind as _byte
scope as _byte
isarray as _byte
end typeThis is just for starters and is only for example. "ident" is the name of the variable. "kind" must be called that way, not "type" since it's a reserved word in most modern BASIC's. This decides whether to use "var", "ptr" or "str" in micro(A). "isarray" then enables an external rule for a memory pool to attach to this element of this UDT. In other words, it could be zero for a regular variable in micro(A) and otherwise, the maximum number of elements in the array.
"scope" is the important one here. It could be set to zero so all variables are global. The way to set it, however could be a pain. Some manuals like that for Free Pascal talk about "reference levels" which causes discouragement. But if the author of the interpreter expects it to be useful enough to allow nested calling of functions, this problem has to be attacked.
This "scope" thing could help in checking to protect variables in another scope. The author of the interpreter could choose how to protect the global variables inside an user-written function. Could always do it, like in Python unless "global" keyword is offered. Now creating local variables should rely on scope. When the user-defined function exits, just search the variable table for candidates with the same scope and remove them. Please do not complicate the situation LOL by seeking to replicate "STATIC" technique in QuickBASIC/Qbasic/QB64. Must rely here on global variables that preserve value between function calls.
Otherwise the suggestion is one I made earlier. Reserve a limited number of variables. Like five per type. They will be used only as parameters for the user-written functions. This is similar to how Perl and Powershell handle things. The drawback is that it limits having one user-written function from calling another one. The author of the interpreter doesn't want to keep a large amount of memory for variables that cannot be used in the main program.
I was going to disturb bplus about this a few months ago. Keep 10 variables around to be used only for user-defined functions in "Oh" interpreter. Keep another 10 variables if you really want to be ambitious, and have one "Oh" interpreter instance call another instance. Which would bring about replicating COMMAND$. Those variables should not be used for any other purpose. They should be just volatile helpers like $1, $2, $3 etc. in "gawk" and Perl, like replaceable parameters in MS-DOS batch language.