Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
basic reserved words shouldn't be permitted as variables, but it isn't consistent (see Pi above).
Edited by CaptainBoing 2017-06-17
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290
Posted: 03:14am 16 Jun 2017
Copy link to clipboard
Print this post
the problem is that mmbasic interpreter has to fit in a limited amount of flash - 190k or thereaboust on the MX170 - and so error checking is not 100% perfect.
what you are seeing is asc followed by a space being interpreted as a variable name rather than a function name. because print allows terms to be seperated by whitespace, you then see the value of the variable called asc (zero) followed by the contents of the string "," (a single comma).
upon a little thought, would it be more efficient if the "(" were inclided in the token tables for functions? ie, the table would contain "asc(" instead of just "asc". this would be one for geoff. and should function names ever be interpreted as variable names?
cheers, rob :-) Edited by robert.rozee 2017-06-17
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985
Posted: 03:18am 16 Jun 2017
Copy link to clipboard
Print this post
that is what I deduced too but white space should always be ignored (except labels and possibly a couple of other instances
I have never encountered this and it strikes me as a bad idea - hence "reserved words"Edited by CaptainBoing 2017-06-17
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8592
Posted: 03:39am 16 Jun 2017
Copy link to clipboard
Print this post
It is which is precisely why "asc (" is not the same as "asc("
{ "Asc(", T_FUN | T_INT, 0, fun_asc },
Functions without parameters are a special case e.g. PI
{ "Pi", T_FNA | T_NBR, 0, fun_pi },
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209
Posted: 06:32am 16 Jun 2017
Copy link to clipboard
Print this post
Why not just ignore all whitespace. That is how it is done with most programming languages. If that means the PRINT command has to be changed then i would say that would be good as using a whitespace as a delimiter is very unconventional and can lead to mistakes that are hard to find. It would also help with the problem that keywords are being interpreted as variables. Microblocks. Build with logic.
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985
Posted: 06:42am 16 Jun 2017
Copy link to clipboard
Print this post
guess how I came across it
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290
Posted: 12:18pm 16 Jun 2017
Copy link to clipboard
Print this post
i recently struck the same problem with a function i had that was called colour$(), recently dragged up from some old code. it took a bit of head-scratching to figure out what was going on!
changing the delimiters for commands would a very big paradigm shift, though not unheard of - consider the differences between python versions 2 and 3. an advantage is that the editor could 'eat' all whitespace within lines when saving and reformat the code upon loading (whitespace at the start of a line and before a comment being the exceptions). functions and subroutines could also be collapsed into a single entity (as in C).
how would folks feel if the print statement required brackets around the parameter list and all parameters seperated by either commas or semicolons? there would be many other changes elsewhere, but the ones to print would be by far the most obvious. it would definitely be something justifying a major version number change, as big for the language as the move from the MX150 to MX170 platform.
geoff: how do you feel about the idea of this being discussed? it would be a departure from microsoft basic compatibility, but may simplify some parts of the interpreter. i would suggest (if it happens) that the first step should be going through and reworking the syntax before starting any modifications to the interpreter's C code, an exercise that could be conducted on the forums.
all just my opinion, nothing else!
cheers, rob :-)
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985
Posted: 12:26pm 16 Jun 2017
Copy link to clipboard
Print this post
yes I understand what you mean.
I think, for me at least, it just means I have to be more attentive to how I write stuff just as in strictly typed languages (your example of python is a case in point).
If you know the trap is there it can be avoided. I never forget that MMBasic is free (well, without charge - it is not "free") and dealing with any little wrinkle could
a. require the resources of a full time dev team b. exclude it from the smaller devices
I'll work around it and not lose any sleep.
GoodToGo! Senior Member Joined: 23/04/2017 Location: AustraliaPosts: 188
Posted: 03:49pm 16 Jun 2017
Copy link to clipboard
Print this post
You would think so, but then human factors comes in to play. I spent an eternity trying to work out why a GUI LED would change colour but not turn 'on' in a control/monitoring program I am working on.
Eventually turns out I had "CTRLVAL (Page1LED(Channel)) = 1" instead of "CTRLVAL(Page1LED(Channel)) = 1"
Stupid thing is the same thing burnt me when I started playing with uMites.... I must be a goldfish. Once around the bowl and it's all new again.
Cheers GTG!
...... Don't worry mate, it'll be GoodToGo!
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209
Posted: 06:57pm 16 Jun 2017
Copy link to clipboard
Print this post
A PRINT statement could also be used as: [code] PRINT "Hello ";Name$;"." [/code] Just replace the space with a semicolon. If this is done then whitespace can be skipped as i think PRINT is the only command that does something special with a space. Microblocks. Build with logic.
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290
Posted: 11:18pm 16 Jun 2017
Copy link to clipboard
Print this post
the behaviour of print allowing whitespace to seperate terms is certainly something i'd not noticed before i started using micromite basic. have just done a quick check with an old version of cbmbasic (statically recompiled for win32) and it interprets PRINT A B as a command to print the single variable AB.
would modifying the syntax of PRINT to disallow using whitespace as a seperator be sufficient to have the editor 'eat' all whitespace outside of quotes without too much disruption?
Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
Print this post
