MS Basic String handling like in Basic Xl/XE would be nice along with advanced string functions like LEFT$(), MID$(), and RIGHT$(). Equally valuable would be an actual string concatenation operator like STR1$ = STR1$ + STR2$, or a function like STR1$ = CONCAT$(STR1$, STR2$).
Apart from its slowness, the greatest weakness of Atari Basic was string handling.
I plan to add string handling functions, but possibly only to he floating-point version to keep the small size of the integer-only IDE. I really want to keep the base implementation under 8kB, and currently I have only 219 bytes left
But, I don't like the "RIGHT$", "MID$" and "LEFT$" function names, I think that the syntax is confusing for assignments and too long, like ' MID$(A$,3,2)="TEST" '.
One possibility is using a square-bracket syntax, like: ' A$[3,5] = "TEST" : ? A$ ', I think that would be more natural, but incompatible with other basics.
At the time, I didn't like the fact that Atari Basic lacked strings handling.
Many type-in listings for other machines didn't work.
A compatibility with popular C64 Basic strings handling would be nice.
One question, does C64 basic allows assigning to MID$, as ' MID$(A$,2)="hello" ' ?
Yes, the Atari can do some clever tricks with strings, but sometimes you just want to carve up text with the least finagling, and Atari string handling is all about the finagling. In a Microsoft style Basic (nearly every other Basic in existence), you can have arrays of strings containing mixed data with delimiters and use string functions like instr$(), left$(), and mid$(), etc$(), to pull apart the string and extract data. It's the closest you can get to having structs without adding structs to Basic.
Philsan has an excellent point also, Portability of code between Basics is a desireable feature as I learned when a gentleman asked me to help him port a horse handicapping program from Microsoft Basic to the Atari. It was an exercise in frustration with Atari string handling and lack of string arrays, which the program used heavily. I thought it would be an easy port because there were no graphics, but I finally had to admit that it would take far longer than I had time for, and may not have fit in free memory in its final form. It might have been cheaper to simply sell a copy of MS-Basic with every copy of his program.
Ideally, you'd want a basic with the best of both worlds. I don't really know what PUR-80 ten liners are, but guessing from the title I would surmise it is packing as much functionality into ten lines of "pure" Atari Basic as possible. What does that have to do with the features of a Basic that seeks to expand upon what Atari Basic can do in terms of features and execution speed?
dmsc, while I'm wishing, how about a "PrintUsing()" feature for doing formatted printing? You don't have to get into regular expressions (I hate those anyway).
Also, what is the deal with procedure arguments? Are they not supported or it is try it at your own risk?
About "print using", this is not easy to implement, as FastBasic uses the math-pack FASC function to convert floating point to decimal, so it has no control over the format returned. A simpler function to implement is TAB(), as ' PRINT "Hello"; TAB(20); "World" ', that would allow to print lists more easily.
And about procedure parameters, those are not supported (yet?), the parser is not powerful enough at this time to address parameters without storing the values in variables, so for example one possible implementation would change:
PROC test, x, y
POS. x, y
Into the equivalent:
PROC test, x, y : test_y = y : test_x = x
POS. test_x, test_y
The idea is that each parameter should define a "local" variable that is filled at procedure start. But, now we have another problem: the parser should ensure that the procedure is called with the correct number of arguments, or the execution would fail. So, you must define the procedure before calling it. All in all, not that simple for this "small" basic.
You can do all of this in Atari Basic as well. Personally I prefer Atari Basic's double-subscript syntax to slice strings over separate functions such as left$(), mid$(), etc. To me it is cleaner.
Ye, I tend to agree, this is why I proposed the square brackets syntax instead.
Thanks for all the suggestions!