Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: freetrav on August 24, 2018, 03:44:01 pm

Title: Suggested Feature: Variable Parameter Procs/Funcs
Post by: freetrav on August 24, 2018, 03:44:01 pm
I recognize that QB64's primary goal is QBASIC/QuickBASIC compatibility, with MS BASIC PDS compatibility just behind that. Nevertheless, there is a feature I recall from a different BASIC, pre-QB, that I would like to see:

I'm not sure of the "formal" name for this capability, but it effectively allowed you to write your own functions and procedures that could take different parameters, and process them based on the number, position, type, etc., of the parameters passed to the function/procedure. A modern language in which this is implemented is PowerShell, with its notion of "ParameterSets". There's a barebones intro to the concept in PowerShell written by (retired) Scripting Guy Ed Wilson. (https://blogs.technet.microsoft.com/heyscriptingguy/2011/06/30/use-parameter-sets-to-simplify-powershell-commands/)

(The BASIC was Summit Software Technology's BetterBASIC, which looked like - had it been invented today - a hybrid between GW and Q, with some additional features borrowed from other languages. BetterBASIC implemented this particular feature somewhat awkwardly at the code level; you had to write the procedure as PROCNAME.A, PROCNAME.B, etc., for each possible allowable set of parameters - but when you called them, it was always called PROCNAME followed by the parameters. It did, however, allow you to extend builtins using the same method; if you wanted to handle PRINT specially for a user-defined structured type, you would write the procedure PRINT.A that took your user-defined type as a parameter and processed it. I'd prefer something closer to the PowerShell model, but I'm not hard-core about it; any reasonable way to get the effect will be satisfactory.)
Title: Re: Suggested Feature: Variable Parameter Procs/Funcs
Post by: STxAxTIC on August 24, 2018, 03:51:24 pm
Hello,

This sounds like a request for OOP in a different guise. Good question really... Maybe some kind of library could be made to absract-up the way one can send parameters to functions, but I dont see this being a native QB64 feature around any corner ahead.
Title: Re: Suggested Feature: Variable Parameter Procs/Funcs
Post by: SMcNeill on August 24, 2018, 03:58:48 pm
Quote from: STxAxTIC on August 24, 2018, 03:51:24 pm
Hello,

This sounds like a request for OOP in a different guise. Good question really... Maybe some kind of library could be made to absract-up the way one can send parameters to functions, but I dont see this being a native QB64 feature around any corner ahead.
o

Or a request for Overloading Functions/Subs:

SUB Sort (Array() AS INTEGER)
SUB Sort (Array() AS SINGLE)
SUB Sort (Array() AS STRING)

3 SUBS, all with the same name, and you'd just call them with:

Sort Myarray()

If the array is an integer, it'd go to the first routine.  Single arrays would go to the second, and strings would go to the third...
Title: Re: Suggested Feature: Variable Parameter Procs/Funcs
Post by: FellippeHeitor on August 24, 2018, 04:12:52 pm
Both ideas are very tempting indeed. Overloading functions and SUBs would allow for ommitable parameters and scenarios like Steve just outlined, and that would be great.

The other way around, appending a sub/function name to a variable does indeed look like object oriented programming. I admit it's my dream to have something like

TYPE myCoolType
    a AS INTEGER
    b AS INTEGER

    FUNCTION sum()
        sum = this.a + this.b
    END FUNCTION
END TYPE

...and then we could DIM myCoolVariable AS myCoolType and do things like:

myCoolVariable.a = 10
myCoolVariable.b = 5
PRINT myCoolVariable.sum

But even as I explain it to you guys, having used this. in my explanation shows me that what I wanted was OOP. More specifically JavaScript.

It'd be cool, but looks like a long way from what QB64 really is, as stated in the first post of this thread.
Title: Re: Suggested Feature: Variable Parameter Procs/Funcs
Post by: freetrav on August 27, 2018, 07:56:55 am
OK, What I was thinking of was definitely "Function/Procedure Overloading", rather than "Object-Oriented Programming", but now that the latter has been mentioned, and both briefly discussed, I could see that being useful as well - in fact, if I'm not up to the 'm' in 'alzheimer', C++ and its descendants support both in an integrated manner (that is, you can have overloaded functions that are members/constructors for user-defined types/structs).

Following on to OOP, it would be reasonable to request operator overloading as well (that is, be able to define what "a + b" means, for a and be being user-defined types) - but this is QB/QB64, not "VB++#Script".

Given that PRINT is already overloaded, inherently, I don't consider Procedure/Function overloading in QB64 to be completely breaking of its QB-ness, any more than some of the other extensions do.
Title: Re: Suggested Feature: Variable Parameter Procs/Funcs
Post by: Cobalt on August 27, 2018, 11:01:40 am
I thought that whole idea was thoroughly trounced over at .NET a year or two ago, though I can't remember the exact reason for it. I do seem to remember it was discussed. Darn it where is that backup copy of .NET forum its definitely needed.
Title: Re: Suggested Feature: Variable Parameter Procs/Funcs
Post by: bplus on August 28, 2018, 09:25:05 am
Here is my fake overloading proof of concept, using spaces to delimit "parameters"  instead of commas which might be more natural looking. As you can plainly see, any amount of "parameters" variables and their values can be added, evalOverload needs only, eval>(numeric expression to evaluate), listed anywhere in string.
Code: QB64: [Select]
  1. _TITLE "Overload test eval"
  2. 'testing with QB64 X 64 version 1.2 20180228/86  from git b301f92
  3.  
  4. 'Overload test eval.bas B+ 2018-08-25 started
  5. ' modify Split for special case of spaces to be used as delimiter for overloaded p$ = parameter string
  6.  
  7. ' note: for ease of coding ~ is used for subtraction sign and normal - is reserved to indicate a negative number.
  8.  
  9.  
  10. CONST WW = 800
  11. CONST WH = 600
  12. SCREEN _NEWIMAGE(WW, WH, 32)
  13. _SCREENMOVE (1280 - WW) / 2 + 30, (760 - WH) / 2
  15.  
  16. test$(1) = "seven=7 eval>seven*10~7" ' < this is 7*10-7
  17. test$(2) = "A=2 b=3 C=5 x=10 eval>a*X^2+B*x+c"
  18. test$(3) = "eval>able*x^2+baker*x+charlie able=2 baker=2.99 charlie=5 x=10 eval>able*x^2+baker*x+charlie"
  19. FOR i = 1 TO 3
  20.     PRINT "For: "; test$(i);
  21.     evalOverload test$(i)
  22.     PRINT ", evalOverload returned: "; test$(i)
  23.     PRINT
  25.  
  26. SUB evalOverload (p AS STRING)
  27.     ' p$ comes in as parameters list, goes out as like a function's return value (but in string form of course).
  28.     ' so save p$ before calling and using here if need it again!
  29.  
  30.     DIM pList$(0)
  31.     DIM test AS INTEGER, L AS LONG, R AS LONG, found AS _BYTE, hit AS _BYTE
  32.     p = UCASE$(p)
  33.     Split p, " ", pList$()
  34.     FOR i = 0 TO UBOUND(pList$) 'find eval
  35.         IF INSTR(pList$(i), "EVAL>") THEN
  36.             this$ = rightOf$(pList$(i), "EVAL>"): found = 1: EXIT FOR
  37.         END IF
  38.     NEXT
  39.     IF found = 0 OR this$ = "" THEN PRINT "Did not find eval or what to eval.": p = "": EXIT SUB
  40.     b$ = ""
  41.     FOR i = 1 TO LEN(this$) 'do substitutions
  42.         wd$ = ""
  43.         hit = 0
  44.         WHILE INSTR("ABCDEFGHIJKLMNOPQRSTUVWXYZ", MID$(this$, i, 1)) AND i <= LEN(this$)
  45.             hit = 1
  46.             wd$ = wd$ + MID$(this$, i, 1)
  47.             i = i + 1
  48.         WEND
  49.         IF hit THEN i = i - 1
  50.         IF wd$ <> "" THEN
  51.             found2 = 0
  52.             FOR j = 0 TO UBOUND(Plist$) 'find eval
  53.                 IF leftOf$(pList$(j), "=") = wd$ THEN
  54.                     b$ = b$ + rightOf$(pList$(j), "="): found2 = 1: EXIT FOR
  55.                 END IF
  56.             NEXT
  57.             IF found2 = 0 THEN
  58.                 PRINT "Did not find word, "; wd$; ", in paramters list.": p = "": EXIT SUB
  59.             END IF
  60.         ELSE
  61.             b$ = b$ + MID$(this$, i, 1)
  62.         END IF
  63.     NEXT
  64.  
  65.     FOR j = 1 TO 6
  66.         op$ = MID$("%^/*~+", j, 1) 'notice the starnge sign for minus, to distinguish a neg number from subtraction op
  67.         WHILE INSTR(b$, op$)
  68.             place = INSTR(b$, op$)
  69.             L = place - 1: R = place + 1: lb$ = "": rb$ = ""
  70.             WHILE INSTR("1234567890-.", MID$(b$, L, 1)) AND L >= 1
  71.                 lb$ = MID$(b$, L, 1) + lb$
  72.                 L = L - 1
  73.             WEND
  74.             R = place + 1
  75.             WHILE INSTR("1234567890-.", MID$(b$, R, 1)) AND R <= LEN(b$)
  76.                 rb$ = rb$ + MID$(b$, R, 1)
  77.                 R = R + 1
  78.             WEND
  79.             vl = VAL(lb$): vr = VAL(rb$)
  80.             head$ = MID$(b$, 1, L): tail$ = MID$(b$, R)
  81.             SELECT CASE op$
  82.                 CASE "%": M$ = LTRIM$(STR$(VAL(lb$) MOD VAL(rb$)))
  83.                 CASE "^": M$ = LTRIM$(STR$(VAL(lb$) ^ VAL(rb$)))
  84.                 CASE "/": M$ = LTRIM$(STR$(VAL(lb$) / VAL(rb$)))
  85.                 CASE "*": M$ = LTRIM$(STR$(VAL(lb$) * VAL(rb$)))
  86.                 CASE "~": M$ = LTRIM$(STR$(VAL(lb$) - VAL(rb$)))
  87.                 CASE "+": M$ = LTRIM$(STR$(VAL(lb$) + VAL(rb$)))
  88.             END SELECT
  89.             b$ = head$ + M$ + tail$
  90.         WEND 'while op instr
  91.     NEXT
  92.     'return p  string as result
  93.     p = b$
  95.  
  96. FUNCTION leftOf$ (source$, of$)
  97.     posOf = INSTR(source$, of$)
  98.     IF posOf > 0 THEN leftOf$ = MID$(source$, 1, posOf - 1)
  100.  
  101. FUNCTION rightOf$ (source$, of$)
  102.     posOf = INSTR(source$, of$)
  103.     IF posOf > 0 THEN rightOf$ = MID$(source$, posOf + LEN(of$))
  105.  
  106. 'notes: REDIM the array(0) to be loaded before calling Split '<<<<<<<<<<<<<<<<<<<<<<< IMPORTANT!!!!
  107. SUB Split (mystr AS STRING, delim AS STRING, arr() AS STRING)
  108.     ' bplus modifications of Galleon fix of Bulrush Split reply #13
  109.     ' http://www.[abandoned, outdated and now likely malicious qb64 dot net website - don’t go there]/forum/index.php?topic=1612.0
  110.     ' this sub further developed and tested here: \test\Strings\Split test.bas
  111.     DIM copy AS STRING, p AS LONG, curpos AS LONG, arrpos AS LONG, lc AS LONG, dpos AS LONG
  112.     copy = mystr 'make copy since we are messing with mystr
  113.     'special case if delim is space, probably want to remove all excess space
  114.     IF delim = " " THEN
  115.         copy = RTRIM$(LTRIM$(copy))
  116.         p = INSTR(copy, "  ")
  117.         WHILE p > 0
  118.             copy = MID$(copy, 1, p - 1) + MID$(copy, p + 1)
  119.             p = INSTR(copy, "  ")
  120.         WEND
  121.     END IF
  122.     curpos = 1
  123.     arrpos = 0
  124.     lc = LEN(copy)
  125.     dpos = INSTR(curpos, copy, delim)
  126.     DO UNTIL dpos = 0
  127.         arr(arrpos) = MID$(copy, curpos, dpos - curpos)
  128.         arrpos = arrpos + 1
  129.         REDIM _PRESERVE arr(arrpos + 1) AS STRING
  130.         curpos = dpos + LEN(delim)
  131.         dpos = INSTR(curpos, copy, delim)
  132.     LOOP
  133.     arr(arrpos) = MID$(copy, curpos)
  134.     REDIM _PRESERVE arr(arrpos) AS STRING
  136.  
Yes! there is really only one string parameter, thank you.
Title: Re: Suggested Feature: Variable Parameter Procs/Funcs
Post by: bplus on August 28, 2018, 11:50:35 pm
Dang! I just noticed this:
Quote
test$(3) = "eval>able*x^2+baker*x+charlie able=2 baker=2.99 charlie=5 x=10 eval>able*x^2+baker*x+charlie"
eval>... was in the line twice! I forgot to cut the last one out. It still worked correctly.
Title: Re: Suggested Feature: Variable Parameter Procs/Funcs
Post by: STxAxTIC on August 29, 2018, 09:44:33 am
Heya blplus (and anyone else still following),

I have a moral(?) obligation to continue where bplus left off and show where this idea *could* go if you drive it hard for a few, oh, thousand hours. The "idea" of course is that everything is a string, and you represent all of your data as a string (not necessarily storing it that way of course.) If you stay true to the idea, you will wind up with something undoubtedly too slow to operate in the main loop of your gaming engine unless the string parsing is nerfed down a bit. However it will be infinitely portable. Make it right, and it's the last time you need to make it (across several platforms too if you put on a real straight jacket).

All that said, I present to some of you, and remind the rest of you, with one possible epitome of bplus's example, the Sxript project. This qb64 snippet reproduces bplus's example:

Code: QB64: [Select]
  1. REM $Include: 'sxmath.bi'
  2. REM $Include: 'sxript.bi'
  3.  
  4. eval "let(seven,7)", 0
  5. eval "[seven]*10-7", 1
  6.  
  7. eval "<let(A,2),let(b,3),let(C,5),let(X,10)>", 0
  8. eval "[A]*[X]^2 + [b]*[X]+[C]", 1
  9.  
  10. eval "map(<able,baker,charlie,X>,let,<2,2.99,5,10>)", 0
  11. eval "[able]*[X]^2+[baker]*[X]+[charlie]", 1
  12.  
  14.  
  15. SUB eval (a AS STRING, b AS INTEGER)
  16.     DIM c AS STRING
  17.     c = SxriptEval$(a)
  18.     IF b = 1 THEN PRINT c
  20.  
  21. REM $Include: 'sxript.bm'
  22. REM $Include: 'sxmath.bm'

However, since it's a pain in the ass to download the include files, make sure you have them in the right place, so on and so forth, I recommend the (identical) JavaScript implementation if you want to play with the code above. Basically hit this link:

http://www.barnesreport.net/sxript/docs/console/console.html (http://www.barnesreport.net/sxript/docs/console/console.html)

...and paste this code into the big box on the left:

Code: QB64: [Select]
  1. let(seven,7)                                  :
  2. print_[seven]*10-7                            ,\n:
  3.  
  4. let(A,2):let(b,3):let(C,5):let(X,10)          :
  5. print_[A]*[X]^2 + [b]*[X]+[C]                 ,\n:
  6.  
  7. map(<able,baker,charlie,X>,let,<2,2.99,5,10>) :
  8. print_[able]*[X]^2+[baker]*[X]+[charlie]      ,\n:

Within the Sxript ecosystem, so to speak, you have the full range of functional programming features - i.e. you can do everything without naming a single variable or function if you really insist. Or, it has the usual imperative stuff like line labels and goto's, etc. As is, this creature lends itself naturally to faking OOP capabilities much as JavaScript does. Curious people can keep me on the hook for questions, or have a glance at http://www.barnesreport.net/sxript/index.html (http://www.barnesreport.net/sxript/index.html) for a bit more.
Title: Re: Suggested Feature: Variable Parameter Procs/Funcs
Post by: bplus on September 05, 2018, 08:06:17 am
On another forum challenged to do a sin table without variables but apparently library files are OK so then INCLUDE files must be OK too, so here is my reply:
Code: QB64: [Select]
  1. _TITLE "test range.bi and bm"
  2. '$include: 'range.bi'
  3.  
  4. PRINT Range("1 to 100 step 1 do sin")
  5. PRINT "End of sin(1 to 100 stepping by 1) table."
  6.  
  7. PRINT: PRINT "Sin at 90 degree intervals:"
  8. PRINT Range("0 to 6.2832 step 1.5708 do sin")
  9.  
  10. PRINT: PRINT "Squares of numbers from 3.5 to 5.5 stepping by .5"
  11. PRINT Range("5.5 to 3.5 step .5 do square")
  12.  
  13. '$include: 'range.bm'
  14.  
  15.  
 [ This attachment cannot be displayed inline in 'Print Page' view ]  

Anyone want to see Range code? ;)
Title: Re: Suggested Feature: Variable Parameter Procs/Funcs
Post by: SMcNeill on September 05, 2018, 08:11:11 am
Quote from: bplus on September 05, 2018, 08:06:17 am
On another forum challenged to do a sin table without variables but apparently library files are OK so then INCLUDE files must be OK too, so here is my reply:

Wouldn't the easiest way just be to put the values into DATA statements, creating an actual table?  LOL
Title: Re: Suggested Feature: Variable Parameter Procs/Funcs
Post by: STxAxTIC on September 05, 2018, 07:50:56 pm
Hmm...

Need some clarity - is the original text of the challenge around? Unless you use a gimmick, you're probably using variables somewhere - even if you wanna chicken and egg the problem like Steve (sarcastically of course) suggested.
Title: Re: Suggested Feature: Variable Parameter Procs/Funcs
Post by: bplus on September 05, 2018, 08:16:00 pm
Tomaaz
Quote
The whole challenge is completely pointless. What about something like this:

Write a program that writes on the screen values of sinus for numbers form 1 to 100 without using any variable name.

Perl
Code: [Select]

print for (map {sin() (1..100)})


How many other languages can do it?

You can bet your sweet bippy variables are involved somewhere but I guess the trick is to not let them show.

Some languages shown had it built-in, others achieved the results with library extensions.
Title: Re: Suggested Feature: Variable Parameter Procs/Funcs
Post by: STxAxTIC on September 05, 2018, 08:56:05 pm
Aha, yeah this (in the language mentioned above):

Code: QB64: [Select]
  1. include(`../test/vector.txt'):
  2.  
  3. print_apply(sin,fill(1,100,100))
Text Only | Text with Attachments