 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. |
Forum Index : Microcontroller and PC projects : MMB4L: should functions/subs be allowed same names as labels?
Page 1 of 2   |
|||||
| Author | Message | ||||
thwill Guru  Joined: 16/09/2019 Location: United KingdomPosts: 3840 |
Hi folks, Historically MMBasic allows you, within one program, to declare a label "foo" and also a SUB or FUNCTION foo(), it works fine and isn't ambiguous, at least not to the interpreter. I doubt anyone intentionally does this, and if I make it an error it will allow me to simplify MMB4L by handling "declaration" of all three types of "target" the same. Does anyone have any thoughts? Best wishes, Tom Edited 2023-01-24 10:16 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
It sounds sensible to me. Geoff Geoff Graham - http://geoffg.net |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5726 |
I can't see a problem with it as it is in theory. It may not be something that I'd normally do, but I can't see a reason why the same name couldn't be given to both as they are different things. However, as I said, it's not something I'd normally do because I don't think it's good programming practice. Because of this I'd be fine if it produced an error. After all, you get an error if you try to use the same variable name with different types. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3658 |
If reasonably possible, I'd prefer an error if a program does that as it's just going to make the program harder to understand/maintain. John |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3840 |
That's the point John, at the moment no version of MMBasic reports an error for this, it's valid AND it works. I'm considering making MMB4L different so it does report errors for clashes between fun/sub names and labels, and ALSO between variable names and labels. Reasoning: 1) I doubt anyone uses this existing "mis?feature" deliberately. 2) I think it will make MMBasic code easier to read and error reporting clearer if such duplication is prevented. 3) It will allow simplification/consolidation of MMB4L's fun/sub/label lookup code. Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8579 |
4) It may break existing programs ( e.g. a, a$ issue) Given it isn't an issue why change? |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3658 |
My last post was just about fun/sub cf label names. If people use variables (a, a$, etc) I suppose we have to allow it. (Such that the $ in a$ is in effect part of the name.) John |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 1781 |
PicoMite > clear :dim a,a$ Error : A Different type already declared > clear :dim a,a% Error : A Different type already declared > clear :dim a$,a% Error : A Different type already declared > |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3840 |
Firstly I'm not advocating this changes in other MMBasic implementations, that's not my business. The implementation of the Variable/Sub/Function (and I'm working on Label) lookup code in MMB4L has already been rewritten c.f. your implementations. I don't think there is any merit or advantage to be gained in disussing why ;-), but if you are curious look at funtbl and vartbl here: https://github.com/thwill1000/mmb4l/tree/thwill-alpha5/src/core The change I'm now considering would make for simpler code (= smaller code = easier to test = easier to maintain) at IMO insignificant reduction in functionality - actually enforcing the writing of cleaner MMBasic code. Who uses "a" as a label ... they need to learn otherwise ;-) And the $,%,! is definitely not part of the variable name ... though I wonder if it might have been earlier in MMBasic's lifecycle (likewise the opening bracket in an array variable name) which would account for the "issues" I identified in skipvar() ? Still considering my options, Tom Edited 2023-01-24 21:45 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2287 |
requiring unique names makes good sense - variables, labels, function and subroutines, etc are all OBJECTS, and so basic code becomes much cleaner and easier to follow if non-uniqueness is an error. the debate was had, i believe, when Geoff decided to require that strings, integers, and floats have unique names (ie, A$ and A% was not allowed at the same time), and everyone survived the changeover without any major loss of life. the idea of simplifying the core of MMbasic is also appealing. this may even free up a little flash memory on the MX170, which is a scarce resource - both the chip (atm) and the flash. and while writing - i also think the allowed length of names should be reduced down to (an enforced) 27 characters, excluding trailing "$", "%", "!", and "(". this allows for the likes of MyFunction$(/0 (where /0 is a trailing null character) along with a 2-character 'safety margin'. once perfected in MMB4L, there is then the potential to port the changes back to other versions of MMbasic. cheers, rob :-) |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3840 |
I'm not involving myself in that bun-fight, but note that Peter's ports and MMB4L all use hashed name lookup, trading use of additional memory for better performance. I don't personally see that getting ported back to the MX170, but I have been wrong before and no doubt will be again. WHAT? HOW? SORRY ;-) Best wishes, Tom Edited 2023-01-24 22:46 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2287 |
sorry: i was being lazy, and posting the comment here rather than in the other thread you started (https://www.thebackshed.com/forum/ViewTopic.php?FID=16&TID=15487) discussing name lengths. if the tokenizer enforced this rule then no checking at run-time would be needed - another simplification in the interpreter. cheers, rob :-) |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5903 |
Back in the early MMBasic days we had IF ... THEN GOTO linelabel where the GOTO was optional. IF ... THEN linelabel was OK. If that was still the case, there could easily be confusion when linelabel was also a SUB name. That particular case is no longer relevant because the GOTO is now compulsory but it does demonstrate the preference to keep names unique. Who knows what future code enhancement will fall over if names are not unique. While it is easy for rigorous checking when you have unlimited memory and system performance, expecting the same level on constrained systems is unfair. The fact that you can currently get away with conflicting names is not a reason to encourage it. It only makes maintaining old code more difficult. Jim VK7JH MMedit MMBasic Help |
||||
| toml_12953 Guru Joined: 13/02/2015 Location: United StatesPosts: 326 |
Since BASIC has allowed it since the beginning (May 1964) it really should be allowed in any language that calls itself BASIC. |
||||
| tgerbic Newbie  Joined: 25/07/2019 Location: United StatesPosts: 40 |
I would also vote to leave it alone. I would say that using good coding practices is a good idea and code should be usefully documented. If this is done it will help with maintainability. Most BASICs, for example, allow goto statements. You can choose to use none, a couple or hundreds. It is the programmers choice. If maintainability is important to the programmer, they will probably avoid any ambiguity in naming. Legacy code may already have reused naming and the code might be very solid and supportable. Making reuse trigger an error would force anyone using the code to have to do a rewrite and this might be difficult in a large or possibly not too well documented program. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8579 |
This is the point I was making about a vs a$ which was misunderstood. There is a large library of code for the original Maximite that has never been translated for more modern devices and versions of MMbasic precisely because of this. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2287 |
surely just about anyone can use search-and-replace in notepad or any other text editor?! cheers, rob :-) |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3840 |
Hi folks, Thanks for the input. I've decided to maintain compatibility and keep labels in their own "namespace" for the moment, though I have squashed a handful of inconsistencies with name/identifier lengths that I found on the journey. Just some final titivating left do, with a release by next weekend (hopefully). Best wishes, Tom Edited 2023-01-30 09:22 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| DaveJacko Regular Member  Joined: 25/07/2019 Location: United KingdomPosts: 52 |
Hi all, has anyone noticed that you can accidentally use duplicate line labels? no error thrown ( on recent pico(+flash drive), also old lcd bacpack) 'goto' will go to the first one, which you had forgotten existed. Eventually one throws the laptop out of the bedroom window. here: .... here: .... goto here regs, Dave |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3658 |
Easy fix: don't use goto :) John |
||||
| Page 1 of 2 |
|||||
 Print this page |
