BASIC INPUT: a strange "feature"?

[Ruud]

Pre-info: I'm busy writing my own BASIC that should be able to boot from floppy on a 8088 machine. It is written from scratch in assembly. The idea is that the code should be Commodore compatible so it be able to run PRG files copied from Commodores.

Not having used INPUT for a very long time, I was playing with it on my C64. The used program was simple:

1 input a,b
2 print a,b

Not knowing any more how you could enter multiple inputs, I started with ‘1 2’. To be sure to read it well, a space between the 1 and the 2.
First surprise: it asked for another input and the second and biggest surprise: the output was ’12 3’. RTFM I found out that I had to use commas as separators instead of spaces. After some time I tried as input ‘1 2 3 4 , 5 6 7 8’ and the result was ‘1234 5678’. To make sure that it were numbers I saw I added 'a+b' at the end of line 2 and I got 6912.

So it seems BASIC simply skips the spaces when reading numerical input. IMHO it shouldn’t do that. But it does. Am I missing something or did I run in a feature?

 

[krebizfan]

I tested it in IBM PC BASIC and got the same behavior. Note that inserting letters in the middle of a number like "76 h6" will result in an error so checking a few other possible entry methods would be prudent. Odd that none of the standards specifically mention implicit conversions like that but leading and trailing spaces are required to be removed and I guess it was just easier to remove a space in the middle of a number than to keep track that a space happened followed by more numbers.

 

[Timo W.]

May I ask why you even want to ask for two numbers at the same time instead of doing:

input a
input b

?

If a program would ask me to input two numbers, I would never think about separating them with a space.

 

[Ruud]

May I ask why you even want to ask for two numbers at the same time instead of doing....

Quite simple: Commodore BASIC supports it and if I want to be able to load Commodore PRG files (= BASIC), then I must support it as well.

 

[Chuck(G)]

I think that the answer is pretty simple--of course, leading spaces are ignored as are trailing spaces. So why not simply ignore all spaces? Saves code. Comma is the official delimiter in the ANSI BASIC definition as far as I can determine.

 

[krebizfan]

Multiple variables on a single INPUT statement were part of the BASIC standard. The standard and what MS aimed for allowed the separation of input with commas but if spaces were included next to the comma, those would be ignored. "123,456" and "123 , 456" are treated the same.

Note that some level of conversion will be necessary unless using the simplest of Commodore BASIC programs. All the PEEKs and POKEs will have to be replaced with something else; nothing on an 8088 will be at the same address. Clearing the screen is another adjustment; Chr$(147) would produce "ô" instead if using the standard IBM fonts. The code needed to handle the specifics of the Commodore 64 architecture will be complex.

 

[whartung]

Yea, it's just comma separated values. Even for strings they were comma separated. Want more? Use LINE INPUT and parse it.

 

[krebizfan]

LINE INPUT (or in other BASICs INPUT$) are not part of Commodore BASIC.

 

[Ruud]

Note that some level of conversion will be necessary unless using the simplest of Commodore BASIC programs. All the PEEKs and POKEs will have to be replaced with something else....

I only want my BASIC files to be binary compatible with the Commodore ones. So a Commodore PRG will list in my BASIC as it was written by it. Running it is a complete different matter: I had no intention at all to emulate what the Commodore program would do but...

Clearing the screen is another adjustment;

That made me think. AFAIK standard BASIC doesn't have such a command. Commodore does it by using a CHR$ code. And it uses more CHR$ codes for other features. It won't hurt to have a look at these codes and see if I will use them as well. Thank you for pointing me to them!

 

[rlauzon]

Didn't someone do this already? https://github.com/mist64/cbmbasic

 

[Ruud]

IMHO: no. The main difference: my CBM-BASIC is written in ML and will run on a 8088. This CBMBASIC has been generated by a tool that converted the original C64 ROMs into C. Download it and have a look at the biggest file: it is all gibberish. And I don't think it will run on a 8088.

 

[tradde]

IMHO: no. The main difference: my CBM-BASIC is written in ML and will run on a 8088. This CBMBASIC has been generated by a tool that converted the original C64 ROMs into C. Download it and have a look at the biggest file: it is all gibberish. And I don't think it will run on a 8088.

Wow, I had not looked at it closely enough. It might work, but you can tell it was generated.

 

[CP/M User]

Just a thought, but on my system (Amstrad CPC), "INPUT a" by default accepts numbers, commas are accpeted with "INPUT a,b" with a & b also numbers. Though if Strings are going to be processed, Locomotive BASIC (on Amstrad CPC) has LINE INPUT, though String Types are also accepted with "INPUT a$,b$". I'm a bit surprised "INPUT a" with Numbers along with Spaces is accepted, Locomotive BASIC has a built in safeguard in the event the INPUTs don't match the Type defined, a "?Redo from start" error is issued.

 

[Chuck(G)]

See ANSI X3.113-1987, Section 10.2. Input-reply is specified as one or more items separated by commas. No mention is made of white space, but the example at the top of page 112 shows leading and trailing spaces for numeric quantities.

 

[krebizfan]

White space is mentioned on page 115

If an input datum is an unquoted-string, leading and trailing spaces are ignored

Spaces in the middle of numeric input data should cause an error but the very simple parser doesn't bother with that case.

 

[Chuck(G)]

Guess what? Microsoft/GWBASIC doesn't care about embedded blanks in numeric quantities either.

Ok
10 x = 3. 1 4 1 5 9
20 print x
run
3.14159
Ok

The standard is silent on the subject of embedded spaces in numeric quantities. Recall that FORTRAN doesn't care about embedded spaces either. (at least FORTRAN before F90).

 

[krebizfan]

QuickBASIC does not accept

x = 3. 1 4

gives an "Expected: End-of-Statement" Error

However, INPUT with 3 . 1 4 will be stored as 3.14

I hadn't noticed these wrinkles back when I was using BASIC heavily. I could have simplified so many data validation routines.