Adding more Logical Operators

[DSMan195276]

> My impression was the appraoch to QB64 has been to keep the new parts to a minimum, to accommdate newer features of PCs since the old days.

Considering the current feature set of QB64 the cat might be out of the bag on that one Though that might not be completely fair.

I haven't really thought about adding new operators, but I can say that it would be a lot messier than adding new functions (as was done for

_SHR

, I guess). I think there's also an important distinction to be made because some things like

_SHR

can be implemented as regular functions, but things like

AndAlso

cannot be implemented as a regular function, so an operator is just about necessary for them (or it would be something that looks like a function, but doesn't actually work like one).

> I would say that if we are going to add stuff to the language, keep it to important changes, like

Personally (and this is me just making this up) I think it would be good to have a clearer distinction between "core" features that are part of the language, and add-on type things that are basically just special libraries. Things like arrays in UDTs would definitely be a "core" feature (and one I would like to see ), things like GUI support in the language would be better served more as a separate thing you can pull-in (even if it had special language support to make it nicer to use). Maintaining stability for something like a full GUI library is a whole different can of worms, and could reasonably get replaced by something better in the future even if we keep the old one supported.

[madscijr]

> I would say that if we are going to add stuff to the language, keep it to important changes, like

Personally (and this is me just making this up) I think it would be good to have a clearer distinction between "core" features that are part of the language, and add-on type things that are basically just special libraries. Things like arrays in UDTs would definitely be a "core" feature (and one I would like to see ), things like GUI support in the language would be better served more as a separate thing you can pull-in (even if it had special language support to make it nicer to use). Maintaining stability for something like a full GUI library is a whole different can of worms, and could reasonably get replaced by something better in the future even if we keep the old one supported.

All that makes sense and I pretty much agree. 
What is AndAlso supposed to do anyway, that can't be done with normal if then else elseif ? 
Is it something like "finally" in a try catch block? 
(I never saw the point in "finally" as well.)

But speaking of try/catch and if we're talking making improvements, how about adding improved error handling? As is, QB64's ON ERROR GOTO is awfully limited - you can't even GOTO a line inside a function, it has to be a label defined somewhere in the main code. What we need is ON ERROR RESUME NEXT that works like it does in VBA, or a simple TRY/CATCH. I've been living without it for the 2+ years since I've dove into QB64, but improving the scope of error handling would be a nice upgrade!

[DSMan195276]

> What is AndAlso supposed to do anyway, that can't be done with normal if then else elseif ?

It's a short-circuiting operator, so it's the same as a regular

AND

but the argument on the left is evaluated first, and if the result is false then the right side is never evaluated at all. It can have some benefits because the left side might be checking that the right side can be evaluated at all (without producing an error). I'm not sure I'd say it's really necessary, but either way the short circuiting nature of it means it can't be implemented as a regular function, as all function arguments are evaluated before calling the function.

> Is it something like "finally" in a try catch block?

Well we're kinda mixing a lot of different things here try-catch-finally involve exceptions, which end up jumping over whole blocks of code. Personally I don't really like exceptions, but it is what it is. 'finally' blocks can be useful for ensuring that resources get cleaned up even when an exception is thrown. Say you need to close a file with

CLOSE

, but an exception is thrown while you have the file open, so your

CLOSE

gets skipped. If you put it in a

finally

block it's guaranteed to run even if an exception gets thrown at some point. Of course there are better patterns than this, but it is an option.

> But speaking of try/catch and if we're talking making improvements, how about adding improved error handling? As is, QB64's ON ERROR GOTO is awfully limited - you can't even GOTO a line inside a function, it has to be a label defined somewhere in the main code. What we need is ON ERROR RESUME NEXT that works like it does in VBA, or a simple TRY/CATCH. I've been living without it for the 2+ years since I've dove into QB64, but improving the scope of error handling would be a nice upgrade!

I've been thinking about this a bit as well, but I don't have anything concrete. I agree the current situation stinks, I think in general it would be nice if we had something like

ON ERROR RESUME NEXT

and then could just check if

ERR <> 0

to determine if an error occurred on the last statement. Still not amazing, but much more flexible and probably wouldn't require huge changes to the language to support it.

That said I haven't really fleshed anything out yet (and it's not really on my todo list, it's just an annoyance whenever I program in QB64 ), perhaps it would be better to revamp the whole thing entirely. Also, there's also the messy detail that the error handling we have is not really consistent, new functions like

_LOADIMAGE()

do indicate if the file can't be opened without an ON ERROR happening. And then there's that sticky "backwards compatibility" issue ;D ...

[madscijr]

> What is AndAlso supposed to do anyway, that can't be done with normal if then else elseif ?

It's a short-circuiting operator, so it's the same as a regular

AND

but the argument on the left is evaluated first, and if the result is false then the right side is never evaluated at all. It can have some benefits because the left side might be checking that the right side can be evaluated at all (without producing an error). I'm not sure I'd say it's really necessary, but either way the short circuiting nature of it means it can't be implemented as a regular function, as all function arguments are evaluated before calling the function.

> Is it something like "finally" in a try catch block?

Well we're kinda mixing a lot of different things here try-catch-finally involve exceptions, which end up jumping over whole blocks of code. Personally I don't really like exceptions, but it is what it is. 'finally' blocks can be useful for ensuring that resources get cleaned up even when an exception is thrown. Say you need to close a file with

CLOSE

, but an exception is thrown while you have the file open, so your

CLOSE

gets skipped. If you put it in a

finally

block it's guaranteed to run even if an exception gets thrown at some point. Of course there are better patterns than this, but it is an option.

> But speaking of try/catch and if we're talking making improvements, how about adding improved error handling? As is, QB64's ON ERROR GOTO is awfully limited - you can't even GOTO a line inside a function, it has to be a label defined somewhere in the main code. What we need is ON ERROR RESUME NEXT that works like it does in VBA, or a simple TRY/CATCH. I've been living without it for the 2+ years since I've dove into QB64, but improving the scope of error handling would be a nice upgrade!

I've been thinking about this a bit as well, but I don't have anything concrete. I agree the current situation stinks, I think in general it would be nice if we had something like

ON ERROR RESUME NEXT

and then could just check if

ERR <> 0

to determine if an error occurred on the last statement. Still not amazing, but much more flexible and probably wouldn't require huge changes to the language to support it.

That said I haven't really fleshed anything out yet (and it's not really on my todo list, it's just an annoyance whenever I program in QB64 ), perhaps it would be better to revamp the whole thing entirely. Also, there's also the messy detail that the error handling we have is not really consistent, new functions like

_LOADIMAGE()

do indicate if the file can't be opened without an ON ERROR happening. And then there's that sticky "backwards compatibility" issue ;D ...

I thought of one other feature that would be very useful for QB64, which I think someone was maybe going to work on before all this RCCola and forking business, which is a built-in native cURL or wget utility or set of commands. If you're collecting requests or suggestions, please throw that in :-)

[DSMan195276]

> I thought of one other feature that would be very useful for QB64, which I think someone was maybe going to work on before all this RCCola and forking business, which is a built-in native cURL or wget utility or set of commands. If you're collecting requests or suggestions, please throw that in :-)

I don't know if this is what you were thinking about, but I'm actually already working on that exact thing:

https://github.com/QB64-Phoenix-Edition/.../issues/46

I've made fairly good progress, right now the goal is to just get a basic 'unstable' API implemented to try it out and also replace the shelling to

curl

that QB64 does to download the Wiki pages.

If you have any other ideas I would definitely recommend making GitHub issues for them, that's the best way for them to not get lost

[madscijr]

> I thought of one other feature that would be very useful for QB64, which I think someone was maybe going to work on before all this RCCola and forking business, which is a built-in native cURL or wget utility or set of commands. If you're collecting requests or suggestions, please throw that in :-)

I don't know if this is what you were thinking about, but I'm actually already working on that exact thing:

https://github.com/QB64-Phoenix-Edition/.../issues/46

I've made fairly good progress, right now the goal is to just get a basic 'unstable' API implemented to try it out and also replace the shelling to

curl

that QB64 does to download the Wiki pages.

If you have any other ideas I would definitely recommend making GitHub issues for them, that's the best way for them to not get lost

Yes, that is exactly it, that will be great! 
GitHub issues eh? 
People are going to say I've been living under a rock, but I haven't messed with github much beyond "download ZIP", lol. 
But I see the "new issue" button, so I will definitely keep that in mind, thanks!

I hear you on the priorities though, definitely get it stable, don't mind my ramblings. There will be time for that.