Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 02:08 05 Feb 2023 Privacy Policy
Jump to

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 Kingdom
Posts: 2930
Posted: 12:15am 24 Jan 2023
Copy link to clipboard 
Print this post

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
CMM2 Welcome Tape, Creaky old text adventures
 
Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 2987
Posted: 12:21am 24 Jan 2023
Copy link to clipboard 
Print this post

It sounds sensible to me.
Geoff
Geoff Graham - http://geoffg.net
 
Mixtel90

Guru

Joined: 05/10/2019
Location: United Kingdom
Posts: 3327
Posted: 10:32am 24 Jan 2023
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 3034
Posted: 10:43am 24 Jan 2023
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 2930
Posted: 10:50am 24 Jan 2023
Copy link to clipboard 
Print this post

  JohnS said  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.


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
CMM2 Welcome Tape, Creaky old text adventures
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 6828
Posted: 10:54am 24 Jan 2023
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 3034
Posted: 11:00am 24 Jan 2023
Copy link to clipboard 
Print this post

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: Australia
Posts: 899
Posted: 11:22am 24 Jan 2023
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 2930
Posted: 11:32am 24 Jan 2023
Copy link to clipboard 
Print this post

  matherp said  4) It may break existing programs ( e.g. a, a$ issue)

Given it isn't an issue why change?


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.

  JohnS said  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.)


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
CMM2 Welcome Tape, Creaky old text adventures
 
robert.rozee
Guru

Joined: 31/12/2012
Location: New Zealand
Posts: 2042
Posted: 12:11pm 24 Jan 2023
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 2930
Posted: 12:18pm 24 Jan 2023
Copy link to clipboard 
Print this post

  robert.rozee said  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.


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.

  Quote  I also think the allowed length of names should be reduced down to (an enforced) 27 characters ...


WHAT? HOW? SORRY ;-)

Best wishes,

Tom
Edited 2023-01-24 22:46 by thwill
CMM2 Welcome Tape, Creaky old text adventures
 
robert.rozee
Guru

Joined: 31/12/2012
Location: New Zealand
Posts: 2042
Posted: 12:34pm 24 Jan 2023
Copy link to clipboard 
Print this post

  thwill said  
  Quote  I also think the allowed length of names should be reduced down to (an enforced) 27 characters ...


WHAT? HOW? SORRY ;-)
Best wishes,
Tom


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: Australia
Posts: 5119
Posted: 12:11am 25 Jan 2023
Copy link to clipboard 
Print this post

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
Senior Member

Joined: 13/02/2015
Location: United States
Posts: 283
Posted: 03:59am 25 Jan 2023
Copy link to clipboard 
Print this post

  JohnS said  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


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 States
Posts: 35
Posted: 06:14am 25 Jan 2023
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 6828
Posted: 07:53am 25 Jan 2023
Copy link to clipboard 
Print this post

  Quote  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.


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 Zealand
Posts: 2042
Posted: 10:17am 25 Jan 2023
Copy link to clipboard 
Print this post

  matherp said  
  Quote  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.


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.


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 Kingdom
Posts: 2930
Posted: 08:32pm 29 Jan 2023
Copy link to clipboard 
Print this post

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
CMM2 Welcome Tape, Creaky old text adventures
 
DaveJacko
Newbie

Joined: 25/07/2019
Location: United Kingdom
Posts: 30
Posted: 09:37pm 29 Jan 2023
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 3034
Posted: 10:12pm 29 Jan 2023
Copy link to clipboard 
Print this post

Easy fix: don't use goto :)

John
 
     Page 1 of 2    
Print this page
© JAQ Software 2023