SELECT CASES ???
#21
(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.  Wink
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...
Reply
#22
(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.
Reply
#23
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? Big Grin

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
Reply
#24
+1 for "yucky", can't even believe it's discussed to this extent with 20+ posts already.
Reply
#25
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 Big Grin
Reply
#26
(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.
Reply
#27
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?  Angry
Reply
#28
(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?  Angry

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.
Reply
#29
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
Reply
#30
(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
Reply




Users browsing this thread: 1 Guest(s)