Posts: 1,510
Threads: 53
Joined: Jul 2022
Reputation:
47
10-17-2022, 07:40 AM
(This post was last modified: 10-17-2022, 07:53 AM by mnrvovrfc.
Edit Reason: TL;DR as usual
)
(10-16-2022, 08:48 PM)SMcNeill Wrote: Yucky yuck yuck!
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? One more vote for "yuck", it's too confusing. Some people complain about the syntax, let's not give them more reasons to.
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.
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. 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.
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...
Posts: 1,510
Threads: 53
Joined: Jul 2022
Reputation:
47
(10-17-2022, 02:46 AM)Spriggsy Wrote: You can declare a function and sub with the same name I 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.
Posts: 1,616
Threads: 157
Joined: Apr 2022
Reputation:
77
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
Posts: 241
Threads: 10
Joined: Apr 2022
Reputation:
30
+1 for "yucky", can't even believe it's discussed to this extent with 20+ posts already.
Posts: 1,616
Threads: 157
Joined: Apr 2022
Reputation:
77
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
Posts: 217
Threads: 12
Joined: Apr 2022
Reputation:
31
(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 CASE s 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.
Posts: 714
Threads: 36
Joined: May 2022
Reputation:
13
10-17-2022, 08:15 PM
(This post was last modified: 10-17-2022, 08:16 PM by Kernelpanic.)
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?
Posts: 1,507
Threads: 160
Joined: Apr 2022
Reputation:
116
(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 Function
Now, 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 Function
PRINT foo would also fix the problem competely.
Code: (Select All) Print foo
Function foo
foo = 3
End Function
SUBs are called directly as they do something. FUNCTIONs return a value.
Posts: 1,616
Threads: 157
Joined: Apr 2022
Reputation:
77
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
Posts: 1,507
Threads: 160
Joined: Apr 2022
Reputation:
116
(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/showthre...84#pid7984
|