What are good things now to add to QB64?

[mnrvovrfc]

As long as we're wishing...

@SMcNeill @a740g @offbyone I asked this in private already, but would like to share this here.

Are there plans to evolve the language further with things like...

1. Native BOOL  _TRUE and _FALSE (maybe using '$:BOOL to make it optional)
   
2. Optional parameters for SUBs and FUNCTIONs
   
3. EVAL("QB CODE")
   
4. Returning arrays from SUBs and FUNCTIONs
   
5. Arrays inside UDTs
   
6. Arrays of UDTs inside UDTs
   
7. Passing FUNCTIONs and SUBs into other FUNCTIONs and SUBs
   
8. '$INCLUDE_ONCE:
   
9. Native JSON ('$JSON)
   
10. Native DICTIONARY ('$DICTIONARY)
    
11. FUNCTIONs and SUBs inside other FUNCTIONs and SUBs
    

These things are so nice in other languages, I'm finding I'm really missing them.
The issue isn't that QB64PE isn't like every other language - it can be it's own thing, the issue is I'm building bad habits.

GOSUB and GOTO lol - Nothing wrong with them they work fine, but the reason I used those recently is because it's so cumbersome to pass variables around elegantly. The language isn't DRY (Don't Repeat Yourself) at all.

So instead of shimming everything into funcs and subs where i am now using gosub and goto, i just move on with life. 
Meanwhile my cognitive load is higher than it should be in QB64 vs. other languages.

Anyway

Just some thoughts

I've decided to start a new thread so the one by Terry isn't being derailed too much. Not a popularity contest for me LOL.

(1) will require "real" boolean variables and values like Lua and Pascal. In other words, cannot choose any non-zero value as true anymore. Few BASIC programmers would enjoy that, only those like me that had some exposure to languages having boolean types.

(2) This is a high request from me.

(3) Wasn't DSMan or someone else in QB64 team trying to come up with a QB64 interpreter? Because that's what it would involve. If it's only a parser for arithmetic and first-year sequential math stuff then Steve already did that.

(4) This is the same problem as doing it with UDT's -- often too large if it has to be copied. :/

(5) Static arrays inside UDT's is more like it. Otherwise use _MEM. Otherwise figure out how to do an "union" like in C.

(6) No comment.

(7) This could be confusing and difficult to debug; we would need an industrial-strength debugger like that of Purebasic. It's easy to get fancy with function pointers even with simple programs so that other constructs like SELECT CASE... END SELECT are neglected.

(8) Well you already proposed it grymmjack and I support you.

(9) I have to learn that stuff then.

(10) Associative arrays would be a big boost to this programming language despite the performance overhead and the bloat to executables.

(11) Nested subprograms could be a mixed bag like #7. Some people then are going to want function pointers that could point to "local" functions. I'd rather do without it.

How about "AS (type)" at the end of the parameter list, instead of sigil right after FUNCTION name? How about "RESULT =" on LHS instead of having to type in the long-ass FUNCTION name? This last point could over some people who write sloppy programs assigning the function result several times instead of cleanly doing it once, and relying far too much on EXIT FUNCTION.

Don't get me started about GOSUB and RETURN made worthless in Freebasic, for me that's one of the biggest scandals they've ever made. Sorry but in BASIC I want my RETURN back for GOSUB.

[grymmjack]

I've decided to start a new thread so the one by Terry isn't being derailed too much. Not a popularity contest for me LOL.

Awesome @mnrvovrfc! Thank you for doing this.

[grymmjack]

As long as we're wishing...

@SMcNeill  @a740g  @offbyone I asked this in private already, but would like to share this here.

Are there plans to evolve the language further with things like...

1. Native BOOL  _TRUE and _FALSE (maybe using '$:BOOL to make it optional)
   
2. Optional parameters for SUBs and FUNCTIONs
   
3. EVAL("QB CODE")
   
4. Returning arrays from SUBs and FUNCTIONs
   
5. Arrays inside UDTs
   
6. Arrays of UDTs inside UDTs
   
7. Passing FUNCTIONs and SUBs into other FUNCTIONs and SUBs
   
8. '$INCLUDE_ONCE:
   
9. Native JSON ('$JSON)
   
10. Native DICTIONARY ('$DICTIONARY)
    
11. FUNCTIONs and SUBs inside other FUNCTIONs and SUBs
    

These things are so nice in other languages, I'm finding I'm really missing them.
The issue isn't that QB64PE isn't like every other language - it can be it's own thing, the issue is I'm building bad habits.

GOSUB and GOTO lol - Nothing wrong with them they work fine, but the reason I used those recently is because it's so cumbersome to pass variables around elegantly. The language isn't DRY (Don't Repeat Yourself) at all.

So instead of shimming everything into funcs and subs where i am now using gosub and goto, i just move on with life. 
Meanwhile my cognitive load is higher than it should be in QB64 vs. other languages.

Anyway

Just some thoughts

(1) will require "real" boolean variables and values like Lua and Pascal. In other words, cannot choose any non-zero value as true anymore. Few BASIC programmers would enjoy that, only those like me that had some exposure to languages having boolean types.

(2) This is a high request from me.

(3) Wasn't DSMan or someone else in QB64 team trying to come up with a QB64 interpreter? Because that's what it would involve. If it's only a parser for arithmetic and first-year sequential math stuff then Steve already did that.

(4) This is the same problem as doing it with UDT's -- often too large if it has to be copied. :/

(5) Static arrays inside UDT's is more like it. Otherwise use _MEM. Otherwise figure out how to do an "union" like in C.

(6) No comment.

(7) This could be confusing and difficult to debug; we would need an industrial-strength debugger like that of Purebasic. It's easy to get fancy with function pointers even with simple programs so that other constructs like SELECT CASE... END SELECT are neglected.

(8) Well you already proposed it grymmjack and I support you.

(9) I have to learn that stuff then.

(10) Associative arrays would be a big boost to this programming language despite the performance overhead and the bloat to executables.

(11) Nested subprograms could be a mixed bag like #7. Some people then are going to want function pointers that could point to "local" functions. I'd rather do without it.

How about "AS (type)" at the end of the parameter list, instead of sigil right after FUNCTION name? How about "RESULT =" on LHS instead of having to type in the long-ass FUNCTION name? This last point could over some people who write sloppy programs assigning the function result several times instead of cleanly doing it once, and relying far too much on EXIT FUNCTION.

Don't get me started about GOSUB and RETURN made worthless in Freebasic, for me that's one of the biggest scandals they've ever made. Sorry but in BASIC I want my RETURN back for GOSUB.

Following your format for reply @mnrvovrfc:

(1) Yep, it wouldn't be required of course, but for those of us who wanted them they could be there.

(2) Are there any work-arounds for this? I don't think so?

(3) Yea, Fellipe Heitor made that. It's a great project! But yes I know what you mean. I wouldn't need EVAL once other stuff was added, that was just me hoping for a compromise.

(4) How do other langs allow it?

(5) Yes, it seems _MEM is useful in so many contexts. I need to buckle down and try to grok that. @TerryRitchie is going to make a tutorial I think! :excited: (@SMcNeill YT videos are good too but I didn't fully follow them mostly due to bad timing. I'll rewatch.)

(6) Hey, we're dreaming anyway right?

(7) Yes it can be but in lang like JS it's extremely powerful when you start to understand it. Closures and scope hoisting are amazing tools.

(8) This and TRUE/FALSE would be wonderful!

(9) JSON is fantastically useful. Think of it as a serialized structure that is self describing. Where XML is very verbose, JSON is simple but obvious. Check it out here: https://www.json.org/json-en.html

(10) YESSSS AGREED!!!

(11) No one would have to use it. Again just because it is there does not mean everyone needs to use it. But having it there would be really nice. Less important for sure and lower prioroity wish from me

Thanks again for making this a thread.

Yes AS (type) would be great. What does LHS mean?

[Dav]

Can I throw in a wish?   Allow resource/binary files to be included in compiled programs (images, sounds, etc).   RapidQ use to do that, was something like this

Code: (Select All)

$RESOURCE: 'back.jpg' AS BackImage1   'add image file as a resource, give it the name BackImage1

Then in code, we could use BackImage1 like a file:

Code: (Select All)

back& = _LOADIMAGE(BackImage1, 32)

- Dav

[bplus]

I have Eval code (and Steve does too, I think a more complete set of math functions, (they are easy to add into code)) and way more powerful FVal$ code if anyone wants a copy. I use FVal$ in my Interpreter "oh". I'd have to fix up the straight up Fval$ code version since the big incompatible Function name use change of v 2.0 Warning: it's not exactly Basic like but more like another program language whose name escapes this senior at the moment. But I can describe it's syntax:

Every Function is in the form of FunctionName[a1, a2, a3,...] all of them including add, subtract, divide, multiply
It's not a + b + c + d, it's add[a, b, c, d, ...] (some functions allow any number of arguments)
It's not a * x ^ 2 + b * x + c but add[mult[a,power[x,2],mult[b, x],c] Yikes! a Basic user would say.
But it's more powerful because you can do string functions and Booleans and probably do User Defined Functions with it as well though I haven't tested that. What a great idea!

[SpriggsySpriggs]

I really like Dav's suggestion of including resources. That would be absolutely excellent.