[dev build] Fixing an old bug regarding recursion in QB64 - Testers wanted!

[Ryster]

will recursion still work?

Code: QB64: [Select]

1. Print Factorial_Recursive&&(5)
2.  
3. Function Factorial_Recursive&& (n As Integer)
4.     If n = 0 Then Factorial_Recursive&& = 1: Exit Function
5.     Factorial_Recursive&& = n * Factorial_Recursive&&(n - 1)
6. End Function
7.  

Is that a question for me?
If so, it displays the result 120 after compilation

[bplus]

Hello
What's the problem?.
For me it displays as a result of compilation: 5 stars and 1

Here's a question for @Ryster: What version are you getting the correct answer of 5 stars and a 1?

My QB64 v1.5 does fail the test demo Fellippe offered.

[Petr]

It seems to work as it should. I also welcome this upgrade, but I am absolutely sure that it is only a matter of time before this thing catches up with me. It's great that it now works. My current programs all working as expected in this version.

[bplus]

I am leary of the change, but I am an old fogy and hate change that is not my idea anyway ;-))

It is so easy to fix a () less function with a dummy I don't see it worth the risk specially a revision # change to 2.

Fixed with dummy, like this

Code: QB64: [Select]

1. Dim Shared X
2. X = 5
3. Print F(0)
4.  
5. Function F (dummy)
6.     If X = 0 Then
7.         F = 1
8.     Else
9.         Print "*"
10.         X = X - 1
11.         F = F(dummy)
12.     End If
13. End Function
14.  
15.  
16.  

And this line makes way more sense to me.

Code: QB64: [Select]

1. F = F(dummy)
2.  

[Ryster]

https://www.dropbox.com/s/79v4le52cn44icc/Test_Qb64.jpg?dl=0

[bplus]

https://www.dropbox.com/s/79v4le52cn44icc/Test_Qb64.jpg?dl=0

Well that's older than 1.5 there's no revision number, is that QB45? ;-))

What's that icon in top left corner?

[RhoSigma]

I am leary of the change, but I am an old fogy and hate change that is not my idea anyway ;-))

It is so easy to fix a () less function with a dummy I don't see it worth the risk specially a revision # change to 2.

Fixed with dummy, like this

Code: QB64: [Select]

1. Dim Shared X
2. X = 5
3. Print F(0)
4.  
5. Function F (dummy)
6.     If X = 0 Then
7.         F = 1
8.     Else
9.         Print "*"
10.         X = X - 1
11.         F = F(dummy)
12.     End If
13. End Function
14.  

And this line makes way more sense to me.

Code: QB64: [Select]

1. F = F(dummy)
2.  

Very good point @bplus to take into consideration. Will probably waiting a couple more days before start refactoring my stuff, to see if @FellippeHeitor and the other responsible DEVs rethink the whole thing and come up with a solution, which makes less impact on existing code (maybe another Meta command to switch between the old/new behavior? - If it ever was worth to add a new meta, then for this one, it would avoid the whole effords mentioned by Steve).

[bplus]

Exactly due to being a breaking change, we’re internally coming to final terms on bringing the version bump to 2.0.

If you ask me, the outstanding revision of having built-in Debugging IS change enough for bumping version number to 2.0 ie after 2.0 you have built-in Debug; makes sense to me.

How much of a need is there for parameter-less functions?

I saw a little discussion on another forum about confusion between using () for functions and () for arrays, just imaging now a string function looking like a string variable F$ = string variable or function?

or using it in an
IF f$ = g$ Then...

[SMcNeill]

Very good point @bplus to take into consideration. Will probably waiting a couple more days before start refactoring my stuff, to see if @FellippeHeitor and the other responsible DEVs rethink the whole thing and come up with a solution, which makes less impact on existing code (maybe another Meta command to switch between the old/new behavior? - If it ever was worth to add a new meta, then for this one, it would avoid the whole effords mentioned by Steve).

A $NoRecursion meta command would be nice.  When stuff breaks, it’d be simple to point to it and tell folks, “Try this at the top of your code first.”  Recursion was always been just an issue with functions with zero parameters and worked with those that had them (or dummy params).  Back when I posted a fix for this three years ago, nobody wanted the functionality and I never added it into the repo.

https://www.qb64.org/forum/index.php?topic=704.msg6085#msg6085

We discussed it on Discord, tossed the idea around a bit, and then ultimately abandoned it — which is why I never tried to write code around the concept that it’d ever be changed. 

Boy, do I got a lot of rewriting to do now, just to keep all my libraries up to date once this goes live! 

[doppler]

bringing the version bump to 2.0.

All the resistance to going a full point but, I always knew the debugger stuff would warrant a full bump.  Now this just enforces the change.

Sometime near future, when QB64 gets to V4.5, we are going to skip that one right ?

[FellippeHeitor]

will recursion still work?

The fix is exactly to allow recursion all the way. QB64 had the bug described in my first post that wouldn't allow a function without parameters to be called recursively, and the new patch fixes that.

To be clear: QB64 didn't behave like QuickBASIC 4.5 did - any code that relied on this bug wouldn't have worked in QB4.5, due to that. We're catching up with a long-standing issue, one that will require some getting used to.

This is why we need as many of you to help us figure out if anything won't work as outlined in my first post in this thread, like Steve and Rho have been doing (thanks, you two!).

Hello
What's the problem?.
For me it displays as a result of compilation: 5 stars and 1

I have no idea what version of QB64 you're using. That interface sure looks outdated. The code I shared in the first post of this thread won't produce the proper results in v1.5. Please let us know more details.

It seems to work as it should. I also welcome this upgrade, but I am absolutely sure that it is only a matter of time before this thing catches up with me. It's great that it now works. My current programs all working as expected in this version.

That's great to hear, thanks Petr!

How much of a need is there for parameter-less functions?

It's not proper that we support recursion half-way - and the new patch will fix a long-standing issue. We've always aimed to get as close as possible to 100% compatibility with QB4.5 code, and this is a step forward.

As explained before, any existing code that treated the function name as a regular variable was relying on a buggy feature, and it'll take some getting used to the fixed (right) way.

Boy, do I got a lot of rewriting to do now, just to keep all my libraries up to date once this goes live! 

We will have a good chunk of code-reviewing to do all over the place, as you pointed out. We have the Samples gallery and also the wiki - which btw contains an example in the very page for Function that relies on the buggy implementation we're now fixing.

Very good point @bplus to take into consideration. Will probably waiting a couple more days before start refactoring my stuff, to see if @FellippeHeitor and the other responsible DEVs rethink the whole thing and come up with a solution, which makes less impact on existing code (maybe another Meta command to switch between the old/new behavior? - If it ever was worth to add a new meta, then for this one, it would avoid the whole effords mentioned by Steve).

The decision to make this a a new major version release (v2.0) stems from all that's outlined at https://semver.org/ <-- recommended reading.

The tl;dr version is: we're making a fix that can break existing functionality - that grants the version bump while clearly stating "you folks may need some extra work, here's how it works now".

And we're glad it will from 2.0 onwards work as it should always have.

@All: testing continues, I thank you all for joining the ride and please let me know if all works as outlined in the first post in this thread.

[FellippeHeitor]

All the resistance to going a full point but, I always knew the debugger stuff would warrant a full bump.  Now this just enforces the change.

Sometime near future, when QB64 gets to V4.5, we are going to skip that one right ?

That's definitely something to consider 🤣

[FellippeHeitor]

Back when I posted a fix for this three years ago, nobody wanted the functionality and I never added it into the repo.

https://www.qb64.org/forum/index.php?topic=704.msg6085#msg6085

That wouldn't have fixed it entirely, but it's been hanging there for three years, with your question on that thread echoing in my head:

It's kinda a hack, but it works -- unless somebody has a more elegant solution?

I'm glad you're on board.

[Ryster]

I actually tested with an older 32-bit version. After all, there were no test restrictions :). It is currently still the best last 32-bit version to be released so far. The next newer 32-bit versions couldn't handle my code. I am currently using the 64-bit version because none of the newer 32-bit versions, as well as the older one in question, can compile due to the size of the code. For those interested -> in the upper left corner of the window is the coat of arms of my country :).
Applies to: QB64x32 v 0.82

[jack]

@FellippeHeitor
I agree with the changes you did to QB64, I think that the compiler is treating recursive functions properly now and gives meaningful error messages if you attemp to use the function name as a variable :)