![]() |
Forum Index : Microcontroller and PC projects : mmBASIC ENDIF
Author | Message | ||||
OA47 Guru ![]() Joined: 11/04/2012 Location: AustraliaPosts: 982 |
Could I get a concensus of opinion should END IF be two words or one ENDIF. We already have END SUB and END FUNCTION as two words and I have been trapped more times than I would like to admit to. If it is not a major issue could both variations be accepted? ![]() |
||||
Grogster![]() Admin Group ![]() Joined: 31/12/2012 Location: New ZealandPosts: 9492 |
My 2c only - ENDIF. The reason for my preference this way, is that all the other languages I have seen write it as one word like that. ...my 2c only... Smoke makes things work. When the smoke gets out, it stops! |
||||
BobD![]() Guru ![]() Joined: 07/12/2011 Location: AustraliaPosts: 935 |
You didn't ask about ELSEIF. I am happy with ELSEIF and ENDIF being one word. +1 to what Grogs said. |
||||
Gizmo![]() Admin Group ![]() Joined: 05/06/2004 Location: AustraliaPosts: 5111 |
I find I'm typing in END IF instead of ENDIF, because I spend a lot of time working with VB, ASP, etc, which use "END IF". So my vote is for END IF, but I'm not really bothered either way. I go out of my way to avoid the use of ELSEIF. I hate it with every ounce of my being. ELSEIF makes someone elses code near unreadable, especially if you converting from one language to another. That last ELSE at the end of a string of ELSEIF's does my head in ![]() Glenn The best time to plant a tree was twenty years ago, the second best time is right now. JAQ |
||||
OA47 Guru ![]() Joined: 11/04/2012 Location: AustraliaPosts: 982 |
You are on the money Glenn. It is my years of programming VB etc that has given me the bad habit of using END IF. I love working with the MMBasic so I hope I can adapt without loosing too much hair. GM ![]() |
||||
TassyJim![]() Guru ![]() Joined: 07/08/2011 Location: AustraliaPosts: 6220 |
I have got used to both. It's use is split equally amongst the languages I use. I have thought about putting a 'fix end if' into MMEdit but having MMBasic accept either would be good. SELECT CASE I would like. Jim VK7JH MMedit |
||||
MicroBlocks![]() Guru ![]() Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I like END IF because it is using the same structure as END SUB and END FUNCTION. Mixing styles gets you into trouble. Microblocks. Build with logic. |
||||
Geoffg![]() Guru ![]() Joined: 06/06/2011 Location: AustraliaPosts: 3270 |
Originally I was trying to emulate Microsoft BASIC but I suppose that MMBasic has evolved to be sufficiently different that it could support END IF also. I will look into it and implement it if it is reasonably possible. Geoff Geoff Graham - http://geoffg.net |
||||
OA47 Guru ![]() Joined: 11/04/2012 Location: AustraliaPosts: 982 |
Thanks again Geoff(hair saver)Graham GM |
||||
TassyJim![]() Guru ![]() Joined: 07/08/2011 Location: AustraliaPosts: 6220 |
And then I will have to change MMEdit..... (But not a serious issue for me) Jim VK7JH MMedit |
||||
halldave![]() Senior Member ![]() Joined: 04/05/2014 Location: AustraliaPosts: 121 |
Geoff Please, Please, even pretty please could you consider Select Case End Select exactly like vb syntax will make all the nested if then else endif slightly less complicated Select Case number Case 1 To 5 'Between 1 and 5, inclusive ' The following is the only Case clause that evaluates to True Case 6, 7, 8 'Between 6 and 8, inclusive Case 9 To 10 'Equal to 9 or 10" Case Else 'Not between 1 and 10, inclusive" End Select |
||||
Geoffg![]() Guru ![]() Joined: 06/06/2011 Location: AustraliaPosts: 3270 |
OK, I will add SELECT CASE to the list... but I cannot guarantee that it will be implemented as there are many factors to consider. I should explain that because of the way MMBasic works there is a limit to the number of functions and commands that can be supported. Each function/command is converted to a single byte token when a BASIC program is loaded, this is done for speed. At this time MMBasic can have a maximum of 127 commands and 127 functions (including special keywords and automatic variables). To change this limit would require a major rewrite of the interpreter and also cause an impact on memory efficiency and speed. Depending on the platform (Maximite, Micromite, etc) there are about 12 free slots available for commands and 15 for new functions. As a result I have been trying to limit the number of new commands/functions to features that are really important. It is also why I converted the I2C functions from about 8 commands to a single set of commands all starting with I2C (which counts as just one command) - that clawed back about 7 slots. This is a long winded way of explaining why I am careful about adding new commands/functions. Another factor is that any new commands/functions must be done right the first time because once a command/function is added to the language it is very hard to remove in the future as doing so will break some programs. But, I think that SELECT CASE is important enough to consider using up two of these slots. Geoff Geoff Graham - http://geoffg.net |
||||
G8JCF![]() Guru ![]() Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Thank you Geoff. My 2 pennyworth For consistency "End If" would be great, after all we already have "Exit For/Sub/Function", and "End Sub/Function" as has already been pointed out, so EndIf seems an anomaly IMHO. I absolutely have to agree with Gizmo that ELSEIF is an abomination ! Whoever thought that construct was a good idea should have had their head examined and pickled in a large glass jar ! I 200% agree with WW is the correct way forward for multi-If constructs and no fall-thru once a case condition has been met, else we will need an "Exit Select". Peter The only Konstant is Change |
||||
MicroBlocks![]() Guru ![]() Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Another keyword that is very useful is "CONTINUE". You use it especially in loops. The current use of the keyword is to resume execution after a CTRL+C. I guess an alternative keyword could be RESUME. :) I think it is not a problem to maintain backward compatibility to give another functionality to the CONTINUE keyword as it is only used at the prompt, never inside a program. Order keywords that will make life easier, more importantly it will shrink the size of the basic program and will be significanty faster, are: [code] TRIM v$ = TRIM(mystring$,removechars$[,LEFT|RIGHT]) JOIN r$ = JOIN(myArray$,separator$) SPLIT myArray = SPLIT(myString$, separators$, [Max [,RemoveWhiteSpace]]) REPLACE v$ = REPLACE(myString$, find$, replacement$) [/code] TRIM is used to strip characters from a string. [code] a$ = " This is a string..." print TRIM(a$," .") This is a string print TRIM(a$, " .", LEFT) This is a string... print TRIM(a$, " .", RIGHT) This is a string [/code] JOIN is great to concatenate values in an array to a string [code] DIM Arr(10) FOR i = 0 to 9: Arr(i) = i * 2: NEXT i print JOIN(Arr,",") 0,2,4,6,8,10,12,14,16,18 DIM Text$(2) Text$(0) = "Hello" Text$(1) = "World!" print JOIN(Text$, " ") Hello World! [/code] SPLIT is the opposite. [code] myArray = SPLIT("0,1,2,3,4,5,6,7,8,9", ",") print myArray(3) 3 myArray$ = SPLIT("This is a text.", " ") print myArray$(3) text. myArray$ = SPLIT("1234, ABC, DEF, GHI" , "," , 2 , true) print myArray$(0) 1234 print myArray$(1) ABC, DEF, GHI [/code] REPLACE [code] Text$ = "Hello World!" print REPLACE(Text$, "World", "Backshed members") Hello Backshed members! [/code] Microblocks. Build with logic. |
||||
shoebuckle Senior Member ![]() Joined: 21/01/2012 Location: AustraliaPosts: 189 |
I think there is a case for CASE but END IF, TRIM, JOIN, SPLIT and REPLACE leave me cold. TZ if you want to speed up the code, why not use the CRUNCH utility. Cheers, Hugh |
||||
MicroBlocks![]() Guru ![]() Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I use crunch. :) Those suggested keywords can be replaced with current basic code in the form of subroutines and functions. It is however slow, my guess maybe 10000 times slower then a native implementation, as it is using a lot of string manipulation. It takes a lot of memory and some things can not be done as a subroutine/function because you can not use an array as a parameter. If you work with devices that use strings as records (like a GPS), or if you want to do logging, parse keyboard input etc those keywords come in very handy. Microblocks. Build with logic. |
||||
Justplayin![]() Guru ![]() Joined: 31/01/2014 Location: United StatesPosts: 327 |
My two cents too.. I prefer End If, just because that's the way it is in Liberty BASIC which I use regularly. In QuickBASIC I used SELECT CASE a lot, for some reason I find LBs version always lacking and gave up trying to use it. For me, TRIM$ is a must. I use it all the time in LB to cleanup user input and other data. It was surprising to find it missing it MMBASIC. REPLACE$ sounds like a great idea too. --Curtis I am not a Mad Scientist... It makes me happy inventing new ways to take over the world!! |
||||
Gizmo![]() Admin Group ![]() Joined: 05/06/2004 Location: AustraliaPosts: 5111 |
I think Geoff's comment about the limited number of commands is important. While I would prefer END IF, I would not like to see it implemented if it means we could miss out on new commands in the future. I can live with the error message when I accidentally type in END IF instead of ENDIF. It's not hard to delete that space between END and IF, or use a find/replace to do the work for you. So my position is we shouldn't have two ( or more ) commands that do the same thing. As for the string commands, I use TRIM, SPLIT, JOIN and REPLACE every day, but these can be easily replaced with a function. Glenn The best time to plant a tree was twenty years ago, the second best time is right now. JAQ |
||||
![]() |
![]() |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |