TheBackShed.com

Forum Index : Microcontroller and PC projects : Geoff - possible changes to MMBasic?

Author

Message

Paul_L
Guru

Joined: 03/03/2016
Location: United States
Posts: 769

Posted: 03:40am 18 Jul 2018

Copy link to clipboard

Print this post

Hi Geoff,

I hate to annoy you but I've got two suggestions for modifications to the MMBasic syntax definition.

I'm attempting to write a calibration data file from arrays, containing hundreds of values, using loop constructs with formatting to make it easily editable by hand, and then read the calibration data back into the arrays using loop constructs. I hit a snag.

This code:

OPTION BASE 1
DIM T%(10)=(1,2,3,4,5,6,7,8,9,10
Open "test1.dat" For output As #1
For i%=1 To 10
Print #1, Str$(T%(i%)); '<<<<<<<<<<<< writes "1,2,3,4,5,6,7,8,9,10" to file
If i%<10 Then Print #1,",";
Next i%
Close #1

produces this file:

1,2,3,4,5,6,7,8,9,10

and this code reads the file:

OPTION BASE 1
DIM T%(10)=(1,2,3,4,5,6,7,8,9,10
Open "test1.dat" For input As #1
input #1, T%(1),T%(2),T%(3),T%(4),T%(5),T%(6),T%(7),T%(8),T%(9),T%(10)
Close #1

but this code fails:

OPTION BASE 1
DIM T%(10)
Open "test1.dat" For input As #1
For i%=1 To 10
Input #1, T%(i%)
Next i%
Close #1

After the first iteration of the loop with i%=1 the INPUT command begins looking for the next line. My thought was that if a comma was added to the end of the input command line like this,

INPUT #1, T%(i%),

then the input command could keep the pointer into the data file at the comma in the data line and read the next value on that line instead of moving it to the next line. The addition of the comma after the last variable in the INPUT line might confuse an older interpreter.

The required code might look like this:

OPTION BASE 1
DIM T%(10)=(1,2,3,4,5,6,7,8,9,10
Open "test1.dat" For input As #1
For i%=1 To 9
Input #1, T%(i%),
Next i%
Input #1, T%(10)
Close #1

Robert Rozee sort of agreed with my thinking:

robert.rozee said the use of INPUT #n,V1,V2,...,Vn, (with a trailing comma) seems logical, as it would match the way the PRINT statement works. this could be a worthwhile addition geoff may like to think about adding to the language.

In the absence of the ability to make the INPUT command pause the data pointer in a line by the addition of a comma following the last inline variable I am instead writing each variable to its own line followed by human readable identification using this sort of code:

for j%=1 to SY
for i%=1 to SX
line%=line%+1
Print #1, Str$(n,w%)+", S%("+Str$(j%)+","+Str$(i%)+")"+", "+Str$(line%,3)
next i%
next j%

which enables manual editing of the data file, and then reading it in a loop with this sort of code:

for j%=1 to SY
for i%=1 to SX
Input #1, S%(j%,i%)
next i%
next j%

This seems to work, but I'm not sure why.

When INPUT is expecting a numeric value it seems that it extracts the value of the string it has read and then ignores the rest of the line after the first non-numeric character.

Would you please clarify the operation of the INPUT command when it expects a numeric value. I believe that it reads the data line until it finds a non-numeric character then it quits that input line. Exactly what characters are guaranteed to cause it to quit reading the current line, for example, would a "|" or "," or ">" after the numeric value always work?

These are a few lines from the 173 line calibration data file which I am using currently. The references to the array names and element numbers make it possible to edit the values manually. Will the commas after the numeric values definitely terminate the reading of each line by the INPUT command?

35, S%(1,1)
120, S%(1,2)
35, S%(1,3)
125, S%(1,4)
5, S%(1,5)
35, S%(2,1)
120, S%(2,2)
35, S%(2,3)

The second change might be simpler. A block remark construct would be extremely useful. Something like:

'{
this is a remark
}'

This would, of course, definitely confuse older interpreters.

Anyway, thanks for looking at this.

Paul in NY

Azure

Guru

Joined: 09/11/2017
Location: Australia
Posts: 446

Posted: 03:56am 18 Jul 2018

Copy link to clipboard

Print this post

It probably does not change things but for completeness and correctness your DIM statements are missing closing braces for the initial data.

TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 6283

Posted: 03:57am 18 Jul 2018

Copy link to clipboard

Print this post

To be sure that you are able to read your calibration file, I would read the description in as a string.
It can get overwritten each time so a simple string variable is all that's needed.

Quote FOR j%=1 TO SY
FOR i%=1 TO SX
INPUT #1, S%(j%,i%), junk$
NEXT i%
NEXT j%

Jim

VK7JH
MMedit

isochronic
Guru

Joined: 21/01/2012
Location: Australia
Posts: 689

Posted: 09:12am 18 Jul 2018

Copy link to clipboard

Print this post

(just a suggestion) Input/edit/save the data as a excel csv file instead of text. Inevitably a ?.txt (ed- or .dat) text file is opened with Notepad which has bad habits.
Edited by chronic 2018-07-19

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3292

Posted: 11:00am 19 Jul 2018

Copy link to clipboard

Print this post

I will have a look at it but I don't think that it would simple to implement.

The reason is that INPUT was one of the first BASIC commands defined by Kemeny and Kurtz 54 years ago. This was before strings and its great feature was that it allowed multiple numbers to be inputted (separated by commas) from the console. Note that it was line orientated, you had to enter a whole line before it was split into each number.

Since then we have had strings, CSV, file I/O, etc but INPUT has not changed much.

I will add your idea to my ToDo list but I suspect that tracking the trailing comma and remembering to then read the next line will get complex both in the syntax and implementation, especially with input from the console. And even then it will not address the other issues of CSV formatted data (like quoted CR/LF).

Whenever I read CSV files I use INPUT$() and handle the details with a bit of BASIC code (not hard to do).

Geoff

Geoff Graham - http://geoffg.net

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3292

Posted: 11:13am 19 Jul 2018

Copy link to clipboard

Print this post

Sorry, I forgot to answer this:

Paul_L said Would you please clarify the operation of the INPUT command when it expects a numeric value. I believe that it reads the data line until it finds a non-numeric character then it quits that input line. Exactly what characters are guaranteed to cause it to quit reading the current line, for example, would a "|" or "," or ">" after the numeric value always work?

The way that INPUT works is:
1 - Read a whole line.
2 - Split it into elements based on non quoted commas.
3 - If the element is quoted remove the quotes.
4 - If a numeric value is required the element is converted character by character stopping at the first non numeric character.
5 - String values are used "as is".

GeoffEdited by Geoffg 2018-07-20

Geoff Graham - http://geoffg.net

Paul_L
Guru

Joined: 03/03/2016
Location: United States
Posts: 769

Posted: 10:38pm 19 Jul 2018

Copy link to clipboard

Print this post

Hi Geoff,

Ah ... yes ... Dartmouth in 1964. Kemeny and Kurtz got a National Science Foundation grant to by a GE-225 computer and develop a time sharing system running BASIC some five years after I finished my implementation of far jump resolution in the Cornell 1401 assembler. I got to meet Kemeny and try out the original program at Dartmouth in 1965. I was amazed that it actually worked with very little latency. Kemeny wound up as the President of Dartmouth. I told you that I am older than dirt.

Thanks for looking at my suggestions. I really don't think implementing the final comma in the INPUT command is worth it. Since [INPUT X(n)%,] will read an entire line then split it on commas it will probably wind up with a variable length array of strings which it then tries to convert to a variable length array of numerics. It would then take the value of the first element of the numeric array and assign it to the nth position in X%(). Then the INPUT command would release its variables and return. The next time [INPUT X(n)%,] was called it would not have the filled numeric array available since it was released. Preserving the array would be too much trouble.

You didn't answer my last question directly. Will a comma in a data string (line) definitely cause INPUT to stop parsing the string and jump to the next string (line) when INPUT is looking for a numeric variable?

dim A%(99)
for i=1 to 99
INPUT A%(i)
next

The data file.

1, some junk text
2, more junk text
....
99, even more junk text

The alternate solution would be for me to develop a simple parsing algorithm to parse a data line with elements separated by commas and terminated with a "'" followed by junk text. Maybe that would be my best idea. There are numerous examples of this approach in MMBasic, including one written by you.

What about my second brilliant idea ... the block comment. Do you see any way to implement this?

Paul in NY

Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 5091

Posted: 07:09am 20 Jul 2018

Copy link to clipboard

Print this post

Hi Paul_L,

The block comment is definitely something that is valuable.
If the '{ and }' are the best basic translations of the /* */ in C is to be decided.

Please realize that the block comment also has impact on but RUN mode and EDIT mode in the Maximite and Micromite, but also in MMEdit.

MMedit already has a function to comment out blocks. The hard way. Adding a single quote before every line in the selected block. Maybe you should use MMedit...?

Regards,

Volhout Edited by Volhout 2018-07-21

PicomiteVGA PETSCII ROBOTS

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3292

Posted: 08:38am 23 Jul 2018

Copy link to clipboard

Print this post

Paul_L said You didn't answer my last question directly. Will a comma in a data string (line) definitely cause INPUT to stop parsing the string and jump to the next string (line) when INPUT is looking for a numeric variable?

When looking for a numeric value a comma will cause MMBasic to stop converting numeric chars and then go on to the next value. This is the way all BASICs work and is well known - so I am thinking that you are asking a different question (but I don't know what).

Just to be clear:

With this as the input:
123,456,78 CR/LF

and then running this command:
INPUT a, b, c, d

You will get:
a = 123
b = 456
c = 78
d = 0

All this kind of stuff can be easily discovered by by simply firing up MMBasic and experimenting.

Geoff

Geoff Graham - http://geoffg.net

Paul_L
Guru

Joined: 03/03/2016
Location: United States
Posts: 769

Posted: 10:22am 23 Jul 2018

Copy link to clipboard

Print this post

Thanks Geoff. Just looking for confirmation. I have used too many different languages in the last sixty years! The current inheritance differences between BASIC, FORTRAN, xBASE, FoxPro, Clipper, and LUA are nettlesome.

Paul in NYEdited by Paul_L 2018-07-24

Paul_L
Guru

Joined: 03/03/2016
Location: United States
Posts: 769

Posted: 10:31pm 26 Jul 2018

Copy link to clipboard

Print this post

Geoffg said I will have a look at it but I don't think that it would simple to implement.

.....

Whenever I read CSV files I use INPUT$() and handle the details with a bit of BASIC code (not hard to do).

You're right of course, and that's just what I did. It wasn't too complicated and I have a really readable data file now.

Paul in NY

rave
Newbie

Joined: 24/02/2018
Location: United States
Posts: 28

Posted: 05:51pm 30 Jul 2018

Copy link to clipboard

Print this post

Paul_L said Thanks Geoff. Just looking for confirmation. I have used too many different languages in the last sixty years! The current inheritance differences between BASIC, FORTRAN, xBASE, FoxPro, Clipper, and LUA are nettlesome.

Nettlesome

that's a word I haven't heard in a long time! Now I'm tempted to use this word in my undergraduate programming languages class to bemuse the students some more

More recently, PL designs emphasize POLS (principle of least surprise). Expecting INPUT with a trailing comma to read up to the next item fits that principle neatly. (No pressure, Geoff!)

- Rob

Paul_L
Guru

Joined: 03/03/2016
Location: United States
Posts: 769

Posted: 06:30am 31 Jul 2018

Copy link to clipboard

Print this post

Hi Rob,

Good grief Charlie Brown ... you're actually going to extract lexicographic advice from the random ramblings of a Polack from Brooklyn in an effort to bemuse unsuspecting undergraduates! That might provoke a student uprising!

Bemuse ... that's a word I haven't heard in a long time!

Thanks for examining my extension to the INPUT command Rob. POLS is a laudable idea which should be forefront in one's imagination when designing a programming language and while INPUT with an appended trailing comma seems to support POLS expecting it to retain a pointer position in a data stream must presuppose knowledge of the position of the INPUT command in a succession of programming statements which describe a loop.

In other words, in these statements

for i=1 to 99
INPUT #1, varname(i),
next

the interpreter would have to become an optimizing compiler to see the entire loop structure in order to decide to release the position of the pointer into the data stream only after the {for...next} loop finishes. An optimizing MMBasic compiler would be a nice thing, but I'd sooner run the existing interpreter for many uses. It reminds me of the relative differences of CLIPPER and dBaseIII+.

I think this might be a misuse of Geoff's time ... I think he might just be better advised to go for a walkabout instead.

Paul in NY

Print this page

To reply to this topic, you need to log in.