deh?! You mean something like window$? That's the LAST thing I would want in a MSX. I think the current BASIC is sufficient, if we talk about commands and functions.
I agree!
On the other hand, I'd like it to be more consistent. For example LOCATE X,Y,C and PRESET (X,Y). Note the parentheses. That way it'll be MUCH easier to use.
I don't really know if this is a question of consitence. One could see it like this. You also can consider
LOCATE as a function. Than with parentheses. Or as a command, then without them.
And a nicer assignment/equation sign. So use '=' for assignments and '==' for equations, just like in C or something similar.
Then, it wouldn't be BASIC anymore! What isn't nice on '=' for equations? Thats the normal mathematical usage, very intuitional in BASIC, Pascal etc. If there's an problem at all, -- I don't think there is one -- then it's the '=' for assignements! The pascalien ':=' is much better. But even BASIC has a better solution, consider ''LET A = 3''. Thats original BASIC! The form ''A = 3'' is just an abbreviation.
PRESET doesn't return a value, so it's not a function but a subroutine. Thus, parentheses shouldn't be necessary when calling PRESET.
What if you call a function, but you don't need the return-value. Should you call it with or without parenthesis? Should it actually be allowed to discard the return-value?
In my experience, using parentheses for functions and subroutines would make it a whole lot easier to program (at least in VB, curse the COM interaction!
)
I'd also like to see a windowing system (I didn't add it to AdvancedBasic for nothing
). Would make it a lot easier to make editors with a GUI. Of course, you don't HAVE to use it...
Feature I'd like to see:
- Text-windowing
- Proper functions/procedures
- WHILE/DO, DO/UNTIL
- COPY using (X,Y,W,H) instead of (X1,Y1)-(X2,Y2). How often have I written code like
COPY(X,Y)-(X+W-1,Y+H-1) knowing that the interpreter would have to calculate the
W and H again from those expressions... Wasted CPU cycles!
- Oh, COPY in text mode! 
10 SCREEN 0
20 WINDOW(10,10,70,20)
30 MYPROC("Hallo World!")
40 END
50 DEFPROC MYPROC(P$)
60 WHILE HELL <> FROZEN DO
70 PRINT P$;" "; ' This of course only fills the window defined in line 20
80 ENDWHILE
90 ENDPROC
[edit]And long variable names, of course[/edit]
You mean like this:
? ;)
classes!
Class Window
Private
Field A
Field B#
Field C%
Field D$
Function MyFunction(Look!, Rare!, Neverbeenused$, W00000T#)
End Function
End Private
Public
Field F!
Function MyFunction2$(ForSale#, Amount_of_Boblets)
End Function
Function MyFunction3#(Ebay_comission, Tax)
End Function
End Public
Constructor(x,y,z=1)
End Constructor
Destructor
End Destructor
End Class
M33P=ApplyClass(Window)
M33P.MyFunction3(1,2)
M33p.Destructor()
End
This can't be too hard to read for even the biggest C++ n00b. Perhaps it's slightly more typework, but it's -imho- way more clear and less cryptic. Without some sort of class-mechanism I don't see big/advanced apps to be made. Even if it's just for the datahiding and reusability.
PRESET doesn't return a value, so it's not a function but a subroutine. Thus, parentheses shouldn't be necessary when calling PRESET.
Your're right, Arjan, PRESET doesn't return a value, so it's not a function. Clearly, its a subroutine in the most common sense. More precicely, its a procedure. (I only very seldomly used this statement!)
What if you call a function, but you don't need the return-value. Should you call it with or without parenthesis? Should it actually be allowed to discard the return-value?
In this case, if you're programming in Pascal, you would use a procedure. If there're no arguments to pass to the subroutine -- regardless if it's a procedure or a function -- you need not specifiy a parameter list, thus no parentheses. You can, e.g. consider 'pi' as a function without parameters returning 3.1415. You also can consider it as a name for a numerical constant.
In my experience, using parentheses for functions and subroutines would make it a whole lot easier to program (at least in VB, curse the COM interaction!
)
In MSX-BASIC, LOCATE is considered a command, I guess. Thats why there aren't any parentheses. This command is implemented by a subroutine. Compare it with the PRINT statement. The difference may be only according to syntax.
I'd also like to see a windowing system (I didn't add it to AdvancedBasic for nothing
). Would make it a lot easier to make editors with a GUI. Of course, you don't HAVE to use it...
It would be possible to improve MSX-BASIC in many ways, but would it be the 'classical feeling'?
For me, BASIC is a language well suited for small and medium sized programs (concerning to MSX),
so you need not doing much improvements. For applications beyond this, it's better to use Pascal!
Long variable names would be good, also labels and WHILE and UNTIL-loops. But wouldn't it violate the classic -- nostalgic? -- feeling? I think, there's no need to improve MSX-BASIC that way. It then stops to be BASIC! The only thing to be improved would be to add some nice debugging features, e.g. to list the variables with or without displaying its
current value:
LIST a-c, LIST a-, LIST x*, LIST a%, LIST a$,x$, LIST a-c,X$,d#-f#, also with LLIST respectively.
Thus, LIST a-z would list all variables, so you easily could find out which variable is not yet used.
Or TRON with specifying variable names, so that you'll get the values of this variables if they're encountered.
Any addition to MSX Basic would corrupt the backwards compatablity and will destroy the "nostalgic" MSX Basic, no matter what the addition is. So I think it's a bit weird to say debug options are good and while loops are bad...
Any addition to MSX Basic would corrupt the backwards compatablity and will destroy the "nostalgic" MSX Basic, no matter what the addition is. So I think it's a bit weird to say debug options are good and while loops are bad...
I didn't say that loops are bad. Backwards compatibility is only affected if an already existing feature of MSX-BASIC would be redefined in a possible MSX3-BASIC. Otherwise the added MSX2 screen modes would cause MSX2 not to be compatible with MSX1. I also didn't say that MSX-BASIC is ''nostalgic'' but that some additions to MSX-BASIC maybe could destroy a ''nostalgic'' feeling while working with it.
I stick to my previous points: NO object orientation in our BASIC 
Furthermore: more clarity to the dangling 'else'-clause of the if-then(-else)? statement, while is not necessary, as we have IF and GOTO 
Tanni: the 'LIST a-c' things aren't feasible in BASIC, because all variable names, types and values are determined at run-time. A workaround for this is declaring them using DEF INT/SNG/DBL/STR, but I don't think this is what we want. I still think MSX-BASIC is quite cool, but sucks syntactically (MSX-BASIC 5.0 anyone? ;-))))))
