I am not sure why BASIC needs to have unassigned variables. What is
the benefit of asking the user to assign each variable rather than
setting by default all variables to NULL. There is the CLEAR and
CLEARCOMMON commands that set all variables to zero not NULL which is
a problem when you deal with strings instead of numbers. The space for
variables is anyhow allocated and a value of NULL would make the
variable work as a number as well as a string. Maybe someone knows the
reasons for this BASIC choice.

Lucian

"x" wrote
Well, if you prefer your variables to default to empty strings I guess you
could just start using shell variables...

at TCL if you do
set foo=tom dick harry
then later in a basic program do
crt 'shell variable foo was ':@foo ;execute 'unset foo' capturing bucket
crt 'shell variable bar is ':@bar
where either you had never done any set bar=stuff
or had most recently done unset bar
then your basic program will happily assume bar exists but has
empty string as the contents.

Oh, and in D3 assigned(@bar) is invalid syntax, yet
assigned(bar) presumes your interest was in a regular variable

I like to use them to pass temporary debugging info down / up a string of
subroutine calls; much tidier than adding an additional subroutine arg
or a new entry in COMMON or arranging a temporary disk file / item...

On Nov 11, 10:03*pm, "Frank Winans" <fwin... (AT) sbcglobal (DOT) net> wrote:

Good trick. I usually open a work file much like the automatically
supplied work file in early versions of Microdata. I stuff debug
clues into the workfile as I go. Then if something goes wrong the
work file often has helpful information - even if something goes wrong
years later. A little caution is needed with some flavors but it's
not rocket science. Better (maybe just newer) flavors have an option
in the debugger to print the stack and that is very helpful.

On 2010-11-11 21:22:09 -0500, x <lucian_pata (AT) yahoo (DOT) com> said:

I believe that it prevents subtle errors, such as typos in variable
names. Automatically setting every new variable to NULL would mask
such errors, leading to more difficult debugging.

--
Kevin Powick

On Nov 12, 7:39*am, Kevin Powick <nos... (AT) spamless (DOT) com> wrote:
Kevin beat me to it.
Once you've had to work on nine thousand line programs, trust me, you
will love the idea that it tells you when you have a variable typo.

Will

"wjhonson" <wjhonson (AT) aol (DOT) com> wrote

What he said, and what he said, too.

While we're on the subject...
Don't rely on the compiler to catch unassigned variables!
Just because you've seen the compiler point it out:

Warning: Variable 'X' never assigned a value

Doesn't mean that it will catch something at compile time
that doesn't happen until run time.

Here's a program that compiles cleanly, yet fails when run:

CRT X
X = "YO!"

--
frosty
results from uniData 7.2; YMMV

On 2010-11-12 13:04:06 -0500, "frosty" <frostyj (AT) bogus (DOT) invalid> said:

I've come to appreciate that some mv compilers produce a waring message
similar to:

"Warning: The value assigned to X is never used."

--
Kevin Powick

Catching typos in variable names would be one benefit.
You may have order of assignment error as in Frosty's example, true,
another benefit.
On the other hand BASIC allows you to reuse variables any way you like
without complaint such as open a file and then assign the file
variable to something and further more changing the variable type, see
crazy code below.
OPEN 'BP' TO FILE ELSE STOP
FOR FILE = 1 TO 5000
FILE = FILE:'0'
NEXT FILE
CRT FILE
I mean there is a gate with a big lock called unassigned variable but
there is no fence around the gate.
Should the compiler restrict variable usage ? Once you have a file
handle "A" you should not use the name "A" for anything else. Once you
have used "B" as a number you should not be able to build "B" as a
string.
What do you think ?
Lucian

On 2010-11-12 13:33:47 -0500, x <lucian_pata (AT) yahoo (DOT) com> said:

No.

Such a restriction essentially creates a strongly typed language. If
you did this, you would then need to introduce a host of new functions
to cast variables from one type to the other.

A = 22
CRT 'The temperature is ':IntToStr(A):' degrees.'

--
Kevin Powick

No, I was thinking along these lines.
Either:
1) making BASIC even more lax by ignoring the unassigned variable
altogether because of its limited benefits
2) making BASIC more precise (not restrictive) by generating error
messages when you have something like:
A = 22 <--- numeric assignment
A = A:"0" <--- string assignment
Instead you would have to write:
A = "22" <--- string assignment
A = A:"0"
Once you assign A as a string you cannot do arithmetic on it. If by
mistake you put letter "O" instead of digit zero "0" and try to do
arithmetic operations with A your program will halt with an error that
otherwise will be caught at compile time.
Lucian