+- QB64 Phoenix Edition (https://staging.qb64phoenix.com)
+-- Forum: Chatting and Socializing (https://staging.qb64phoenix.com/forumdisplay.php?fid=11)
+--- Forum: General Discussion (https://staging.qb64phoenix.com/forumdisplay.php?fid=2)
+--- Thread: SELECT CASES ??? (/showthread.php?tid=978)
RE: SELECT CASES ??? - mnrvovrfc - 10-17-2022
(10-16-2022, 08:48 PM)SMcNeill Wrote: Yucky yuck yuck!One more vote for "yuck", it's too confusing. Some people complain about the syntax, let's not give them more reasons to.
Look close at your code samples. Count the conditions you check against for point (-1, -1)...
The first does 3 checks for y, 3 checks for x. The second does 9 checks for y, 9 checks for x.
6 conditional checks vs 18.. How much slower is the multiple select cases going to be??
Yucky yuck yuck!
:
Do you *really* want to add that type of overhead to your program?
There was a code example which enrolled "SELECT CASE... END SELECT" into three or four subprograms which were called in turns, by a big "SELECT CASE... END SELECT" in the main program. That is the highest level of achievement the majority of BASIC programmers would care about that construct.
Also... tuples... make me shiver. Please let's not make QB64PE's BASIC look more like Python.
(10-17-2022, 05:21 AM)SMcNeill Wrote: But, with that said, I'd encourage Pete -- or whomever wants to, including you -- to work up the changes yourself and push them into the repo. We always try and support new developers, and this really doesn't seem like it'd be overly complicated for someone to use as a break-in exercise to learning and interacting with the qb64pe.bas source.The problem is I would have to create an account with Github which is a big fat nope for me. Half the web browsers don't work with that stupid site. I only want to visit that place only to be able to download QB64PE or any other thing that interests me. Otherwise it's an impressive mess, got there much faster than Sourceforge which is sad. Another problem is that my coding skills in C/C++ aren't really up to the standards of "pushing them up into the repo". Not that I'm embarrassed about coding something, but I have never tried to do anything with C++ in decades, literally. Only in C with "stdio", "stdlib" and rather simple stuff like that.
Just because none of the current devs would be interested in spending their precious free time to add or make a suggested alteration, that doesn't mean you can't make it yourself. *That's* the beauty of open-source programming.
If my coding skills were quite good, however, I wouldn't have cared about this programming system. There is an open-source music program I would have liked to fix, because it no longer runs on Windows10, in one of my dreams...
RE: SELECT CASES ??? - mnrvovrfc - 10-17-2022
(10-17-2022, 02:46 AM)Spriggsy Wrote: You can declare a function and sub with the same nameI actually had to go and test it. This is going to produce a new dimension of confusion while lazy people are encouraged. It's a funky way to support subprogram overload, only one overload case allowed.
RE: SELECT CASES ??? - Pete - 10-17-2022
So I count 3 in the "cool" camp, and two in the "yucky" camp. I don't want to put any pressure on those who haven't responded yet, but ask yourself this... Would you rather be cool, or yucky?
Kidding aside, I'm not really advocating we do this in QB64. I was wondering if others, who program in other languages, have had this type of select case available. I mean it would be neat to have it in QB64, but it certainly is not a priority. After all, as we already have other existing conditional statements to accomplish the same thing, only to me, they are not as intuitive as using relationships; but, hey, what do I know about relationships? I've only been married to one woman... 45 years and counting. Not trying to inflate my ego... and NO Steve, I don't have to inflate my "wife" either!
Pete
RE: SELECT CASES ??? - RhoSigma - 10-17-2022
+1 for "yucky", can't even believe it's discussed to this extent with 20+ posts already.
RE: SELECT CASES ??? - Pete - 10-17-2022
It's a dead heat! Hey I discovered MySQL uses SELECT CASE WHEN THEN, that sounds like fun. SWITCH appears to be C#, C++, and JavaScript. I mean come on people, wouldn't creating SELECT CASES a monumental breakthrough in QB64 syntax, or would be more like a break in syntax? I suppose it depends on what camp you are in, the "cool" one or the "yucky" one.
Pete
RE: SELECT CASES ??? - DSMan195276 - 10-17-2022
(10-17-2022, 06:41 AM)Pete Wrote: I agree that a good compiler could optimize the IF/THEN statements, but I would get a bit concerned at what point relationship comparisons are allowed. Two elements, as my y and x example, are not too difficult but what if someone wanted u, v, x, y, z all in one CASE relationship? That gets to be a hell of a lot of nesting.
Well it depends, but really the compiler should be able to group the comparisons such that it only does them once and then uses the results to check the various combinations for each
CASE. Presumably a lot of the
CASEs will share the same individual comparisons, so the compiler would simply work out which comparisons are needed by which cases and then do them in the proper order.
RE: SELECT CASES ??? - Kernelpanic - 10-17-2022
It says "syntax error", so one should be able to fix it. To do this, however, one would first have to know what kind of error is actually meant in order to use the correct syntax. At the moment I don't think really that is a real bug, just a "know how".
But today I don't feel like it anymore, it was a strenuous day.
Syntax error . . . but what kind?
RE: SELECT CASES ??? - SMcNeill - 10-17-2022
(10-17-2022, 08:15 PM)Kernelpanic Wrote: It says "syntax error", so one should be able to fix it. To do this, however, one would first have to know what kind of error is actually meant in order to use the correct syntax. At the moment I don't think really that is a real bug, just a "know how".
But today I don't feel like it anymore, it was a strenuous day.
Syntax error . . . but what kind?
It's a misuse of FUNCTION. See the below:
Code: (Select All)
foo
Function foo
foo = 3
End FunctionNow, doesn't that produce the *exact* same error as you're seeing?
It sure is!!
WHY??
Because FUNCTIONS *have* to be returned to a variable or used in conjecture with a SUB style command such as PRINT.
x = foo would fix the problem completely.
Code: (Select All)
x = foo
Print x
Function foo
foo = 3
End FunctionPRINT foo would also fix the problem competely.
Code: (Select All)
Print foo
Function foo
foo = 3
End FunctionSUBs are called directly as they do something. FUNCTIONs return a value.
RE: SELECT CASES ??? - Pete - 10-17-2022
Oh for goodness sakes. If you are posting SELECT CASES is a syntax error, well, of course it is. It's made up. We are just kicking around an idea and to see if other languages have anything similar.
Sorry if you got sucked in to thinking this was some new keyword, and if I'm missing what you are posting about, my apologies in advance. I'm up to my ASCII in space aliens these days. Darn Halloween!
Pete
RE: SELECT CASES ??? - SMcNeill - 10-17-2022
(10-17-2022, 09:45 PM)Pete Wrote: Oh for goodness sakes. If you are posting SELECT CASES is a syntax error, well, of course it is. It's made up. We are just kicking around an idea and to see if other languages have anything similar.
Sorry if you got sucked in to thinking this was some new keyword, and if I'm missing what you are posting about, my apologies in advance. I'm up to my ASCII in space aliens these days. Darn Halloween!
Pete
You missed it. We've got 2 completely unrelated conversations going on in this one topic. https://staging.qb64phoenix.com/showthread.php?tid=978&pid=7984#pid7984