(08-16-2023, 09:50 PM)grymmjack Wrote: 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...
- Native BOOL _TRUE and _FALSE (maybe using '$:BOOL to make it optional)
- Optional parameters for SUBs and FUNCTIONs
- EVAL("QB CODE")
- Returning arrays from SUBs and FUNCTIONs
- Arrays inside UDTs
- Arrays of UDTs inside UDTs
- Passing FUNCTIONs and SUBs into other FUNCTIONs and SUBs
- '$INCLUDE_ONCE:
- Native JSON ('$JSON)
- Native DICTIONARY ('$DICTIONARY)
- 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.