Page 1 of 1

BASIC Implicit Explicit and Value Typing

Posted: Mon Jan 07, 2013 5:00 am
by IMP-16
You don't specifically mention in the programming manual that variable typing is entirely implicit or self typing, should you?

Multipass interpreters have the ability to implement explicit typing giving the programmer an extra level of coding protection. Why didn't you implement explicit typing?

In the programming manual it says typing is either integer, floating or string. You don't tell the user just how many bits make up an integer but you do say a floating point number is 64 bits long. Integers can be used as shift registers so its important to know how many bits are involved. Is this an omission?

When Microsoft shipped MBASIC back in the late 70's memory was at a costly premium and everything was implicitly declared on the fly. They allowed numeric values to be forcefully typed by appending special characters to the variable to improve memory usage. Sometimes for clarity its easier to declare variables in octal, binary or hexadecimal rather than base 10 numbers. Do you feel you should implement this.

Re: BASIC Implicit Explicit and Value Typing

Posted: Tue Jan 08, 2013 7:05 pm
by admin
Except for dimensioned arrays (DIM) all variables are integer/floats except for names that end in $ which are strings.

Integers are 32 bit in size but auto-convert to floats if they overflow, underflow or are assigned a floating point variable. You may safely think of all numeric variables as floating point variables except when they are used as loop counters in the FOR loop. Loop counters are preserved as integers whenever possible. Floating point variables are 64-bit in size.

A variable may be forced to be a floating point value by assigning it a number with a decimal or an exponent. An integer can always be obtained by the function INT(a) where a is a variable which may be integer or floating point.

Variable are automatically created if they are on the left hand side of an assignment (and the name doesn't conflict with a keyword) but generate an error when they first appear on the right hand side of an assignment.

Constants that start with 0b is interpreted as (32-bit) binary numbers.
Constants that start with 0x is interpreted as (32-bit) hexadecimal number.
Control-BASIC has no concept of octal numbers.

There is a section in the language Reference titled Arithmetic which covers the declaration and initialization of variables.

A major reason why people use interpreters and BASIC in particular is that it does not require explicit declaration of variables, typing and memory management. A great deal of time and effort went into the expression parser and evaluator to ensure that it does the expected operation and does it correctly without burdening the user with knowing the details of numeric representation. Having a single type of numeric variable was a conscious design decision to shield users from overflow and underflow in byte operations, figuring out what happens when you assign a sixteen bit variable to a byte sized variable etc. I agonized over he expression evaluator for months so that integers stay integers as far as possible but gracefully become floating point values before precision is lost. Also, every function that expects an integer value will convert a float to an integer before evaluating the function. Ultimately I viewed explicit typing as a burden without (significant) benefit on a 32-bit processor and decided in favor of ease-of-use.

Another design decision was the removal of the DATA keyword. The exact same functionality can be achieved with an initialized array with the benefit of an error message when you read past the end of the array. The only thing that DATA achieves is the automatic management of an index into the array that stores the values without the ability to manage the index and the side 'benefit' that it wraps around when you read past the end of the data. This is not a benefit, it is an accident waiting to happen.

Hope this clarifies some of the design decisions.
Daniel