Meta Commands

[mnrvovrfc]

The rule #6 got my attention first in the "FILELIST$()" example in the QB64 Wiki. Somewhere the literature bragged along the lines of "open at any time, from any screen and when finished, it restored the previous screen". Usually this is expected from professional paid programmers.

I'm not keen about type suffixes except dollar-sign but it could help to tell what is the variable type straight away. However there is no such benefit for UDT's especially "AS _MEM". Therefore those will have to be surrounded by comments wherever possible.

One other thing, that would surely peak off a lot of people. If the program is to be shared, and it has a lot of comments not in English then... maybe it's better not to share it unless the author is willing to change the language. I can read comments well in Spanish, could follow along most of the time in Italian or Portuguese, less often in French, but it starts breaking down for German, Dutch, Greek, Slavic languages, Turkic languages, Asian languages etc. Oh well but most Chinese, Indonesian, Japanese, Korean etc. know to write stuff in English that is to be shared which demonstrates their education.

I was ordered in another forum to "learn Russian" LOL. I wish I could, it's the language that interests me the most this year.

Oh another thing, the names of the variables don't have to be changed to English, just the comments! Please don't hurt me...

It should only be for a program with a lot of lines of code. It varies from person to person what a "large" program is and what is to be called a "project".

[TerryRitchie]

For Library writers, I'd suggest always dimming both upper and lower bounds.

DIM a(0 to 100)

or, if you like OPTION BASE 1:

DIM a(1 to 100)

You never know what someone will have in their program where they include your library file, so it's best to be as self-contained as possible.  In both cases above, it doesn't matter what the option base is, as you've explicitly defined what the upper and lower limits of your arrays are going to be. 

Ah, so expected behavior. Explicitly setting the boundaries over rides OPTION BASE. Good to know.

[mnrvovrfc]

v1.5 had a "fix" to recursive functions in it, that changed how they worked for people -- and that STILL gets folks posting about it on a regular basis asking about, "Why my shit no work no more?"  That's with just a change to ONE single keyword...   

I'm sorry for asking if it's in the changelogs somewhere, but I cannot find it. So I'm asking here, what happened with this "fix"?

I went to the Wayback Machine to "dot-rip" to look at the changelog for v1.5 but didn't proceed further because my Internet connection could get very slow and, even if it's at top speed using anything from "archive-dot-org" is a drag.

[SMcNeill]

The whole changelog entry was just:

Fixes issue with recursive functions without parameters.

Not much to tell you there, about how it broke folks code. 

Prior to 1.5 (or 2.0, as the "fix" was listed as a 2.0 achievement), people would write a lot of code such as:

Code: (Select All)

FUNCTION foo
IF junk < 10 THEN foo = foo OR 1
IF junk >9 AND foo < 100 then foo = foo OR 2
IF junk > 99 and foo < 1000 THEN foo = foo OR 4

After the fix, all this old code was broken and no longer worked.  QB64 had always previously considered a variable inside a function to be the name of the function, and an assignment value.   After the fix, only the name on the left side of the equal sign was a name -- the name on the right side of the equal sign was now a recursive call back to the same function.

Lots of old code broke -- after all, people had only had 15 years or so to adapt to coding with the concept that "inside a function, the name references the function itself.  If one wants a recursive call, then one should pass a parameter for use with recursion."

For example -- an old recursive call to a function would look like:

Code: (Select All)

FUNCTION foo (dummy)

    IF junk < 10 THEN foo = foo(0) OR 1
    IF junk >9 AND foo < 100 then foo = foo(dummy) OR 2
    IF junk > 99 and foo < 1000 THEN foo = foo(whatever) OR 4

(Not that the example above makes any sense as a recursive function.  It's just there to show the functionality where adding a parameter to the function name turned it into a recursive call, rather than a name, inside the function.)

And you'll still find examples in the wiki, or on the forums, or in old libraries and github repositories that haven't been updated to change to the new "fixed" format of:

Code: (Select All)

FUNCTION foo
    IF junk < 10 THEN tempfoo = tempfoo OR 1
    IF junk >9 AND foo < 100 then tempfoo = tempfoo OR 2
    IF junk > 99 and foo < 1000 THEN tempfoo = tempfoo OR 4
    foo = tempfoo

END FUNCTION

[mnrvovrfc]

Prior to 1.5 (or 2.0, as the "fix" was listed as a 2.0 achievement), people would write a lot of code such as:

Code: (Select All)

FUNCTION foo
IF junk < 10 THEN foo = foo OR 1
IF junk >9 AND foo < 100 then foo = foo OR 2
IF junk > 99 and foo < 1000 THEN foo = foo OR 4

After the fix, all this old code was broken and no longer worked.  QB64 had always previously considered a variable inside a function to be the name of the function, and an assignment value.   After the fix, only the name on the left side of the equal sign was a name -- the name on the right side of the equal sign was now a recursive call back to the same function.

Lots of old code broke -- after all, people had only had 15 years or so to adapt to coding with the concept that "inside a function, the name references the function itself.  If one wants a recursive call, then one should pass a parameter for use with recursion."

If such a function existed it was horrendous. Because "foo" is being compared above twice and each time it calls the function. I would have never done that and have rarely needed recursion in any programming language. That's why I suck at LISP and descendant...

Something like this must have driven M$ to change Visual Basic so we lost there (and in Freebasic) the ability to use "GOSUB" and "RETURN", also to make it look even more like C/C++. Otherwise the fix would have been to always require parenthesis right after a function call, even an empty parameter list, except the function's name on LHS of assignment only to set the return value for that function.

The latest code example in your post might have been instead:

Code: (Select All)

FUNCTION foo
    IF junk < 10 THEN tempfoo = foo: tempfoo = tempfoo OR 1
    IF junk >9 AND foo < 100 then tempfoo = foo: tempfoo = tempfoo OR 2
    IF junk > 99 and foo < 1000 THEN tempfoo = foo: tempfoo = tempfoo OR 4
    foo = tempfoo
END FUNCTION

But the flaw remains of calling function "foo" once or twice for the sake of making a comparison, and a better chance without short-circuit evaluation. It's just better to give "foo" a parameter to control this better.

[SMcNeill]

A few foos too many in my examples...   LOL!  Once they start, and copy-paste hits, they never stop!

FUNCTION foo
IF junk < 10 THEN foo = foo OR 1
IF junk >9 AND foo < 100 then foo = foo OR 2
IF junk > 99 and foo < 1000 THEN foo = foo OR 4


Those two foos in red should've been junk instead, and junk, of course, would probably be best as SHARED junk, so you at least have a value with it to work with...  

What can I say?  It's after-midnight coding at its most honest! 

The point of the way old code worked, "foo = foo OR 1"  <-- here this was both references to the variable named foo, which held our return value.  After the fix, the one on the left was the variable; the one on the right became a recursive function call.

And that ended up breaking a lot of old code.  (Now folks will argue that it was "BADLY WRITTEN CODE", but that's debatable.  If it worked as the programmer intended, because that was an allowable syntax to the language, then how could it be badly written?  Only code that doesn't work, or that works but gives the wrong results, can be called badly written.)  Be what it may, it *used* to work, but after the "fix" to recursion, it didn't anymore.  

And we still have folks pop up on the forums or in the discord asking why their old stuff no longer works on newer versions of QB64 because of it.  But, at this point, what can one say except, "It is what it is."