Re: [Ql-Users] sBASIC overloading...
Im not familiar with C++ overloading, but S*BASIC allows some "parametric polymorphism", viz: dim x%(2): for i% = 0 to 2: x%(i%) = 9 - i% Test 'abc', 2.99, x% : def proc Test(a, b%, c) print a\ b% \ c, \ enddef Test : Result: abc 2.99 9 8 7 The SBASIC compiler performs a number of additional passes to SuperBASIC's parser, to end up with a much purer "executable". The compiled program is not machine code, of course, it consists of fixed length tokens that still need to be "interpreted". But all useless baggage has been eliminated from the program flow, expressions teased into simple RPN steps, and locations resolved to absolute addresses. So no, the size of the program or distance to procedures does not effect the speed of execution. On 20 June 2018 at 22:35, Dave Park via Ql-Users wrote: > Hi all, > > How hard would it be to extend sBASIC functions to support C++ style > overloading? > > Separately, does the sBASIC in SMSQ or Minerva still scan for > procedures/functions from the beginning of the program, so earlier FN/PROCs > have a speed advantage over later ones like in JM/JS? > > > -- > Dave Park > d...@sinclairql.com > ___ > QL-Users Mailing List > > ___ QL-Users Mailing List
Re: [Ql-Users] sBASIC overloading...
On 21 June 2018 at 15:21, Dave Park via Ql-Users wrote: > > SuperBASIC is quite unique in that it stores the *difference* in length > of > > a line compared to the previous line, along with its line number. This > way, > > because the current line length is also stored in a system variable, it > can > > search for lines in both backward and forward direction. So a proc/fn > call > > will be faster when the definition is closer to the calling line. This is > > also mentioned in the Minerva documentation. > > Hmmm. Are they stored in a known order, eg: alphabetical or order of > creation/declaration > They are stored in order of line number (it's Basic, after all...). > > You cannot define a proc/fn multiple times but you can check the type and > > usage of a parameter using the PARTYP, PARUSE, PARNAM$ and PARSTR$ > > functions in TK2 and act accordingly. An example of this is in my 'ls' > > procedure which uses an extra parameter as a flag for recursive directory > > searches. When this parameter is empty it only lists the current > directory. > > I suppose it does reduce these stresses that while sBASIC has "strict" > typing of variables, it allows easy transfer between variable types. It > also has the concepts of undefined variables and defined but unset > variables. > It's not as strict as it seems. What's also unique in S*BASIC is 'coercion'. You want to assign a numeric value to a string variable and S*BASIC will happily do this, by converting the number to a string (in other BASICs you would have to use STR$). And the other way round assign a string value to a numeric variable (provided the string contains a valid number). The type of a parameter in a procedure or function is determined when the function is *called*, not when it's defined. In a machinecode function you can find out what type a parameter is and choose to evaluate it as a number, string or name (in a BASIC function you can use the four TK2 functions mentioned above though you're probably a bit more restricted by parameter types). Also, variables are never undefined (they're defined as soon as you enter their name in a program line) but they can be unset... > Quite amazing for a language that fit in a very small part of 48K. And all written in 68K assembler in a few weeks time... Jan. -- *Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net ___ QL-Users Mailing List
Re: [Ql-Users] sBASIC overloading...
On Thu, Jun 21, 2018 at 3:13 AM, Jan Bredenbeek via Ql-Users < ql-users@lists.q-v-d.com> wrote: > SuperBASIC is quite unique in that it stores the *difference* in length of > a line compared to the previous line, along with its line number. This way, > because the current line length is also stored in a system variable, it can > search for lines in both backward and forward direction. So a proc/fn call > will be faster when the definition is closer to the calling line. This is > also mentioned in the Minerva documentation. Hmmm. Are they stored in a known order, eg: alphabetical or order of creation/declaration > You cannot define a proc/fn multiple times but you can check the type and > usage of a parameter using the PARTYP, PARUSE, PARNAM$ and PARSTR$ > functions in TK2 and act accordingly. An example of this is in my 'ls' > procedure which uses an extra parameter as a flag for recursive directory > searches. When this parameter is empty it only lists the current directory. I suppose it does reduce these stresses that while sBASIC has "strict" typing of variables, it allows easy transfer between variable types. It also has the concepts of undefined variables and defined but unset variables. Quite amazing for a language that fit in a very small part of 48K. -- Dave Park d...@sinclairql.com ___ QL-Users Mailing List
Re: [Ql-Users] sBASIC overloading...
On 21 June 2018 at 00:43, Dave Park via Ql-Users wrote: > My reason for asking was, I was wondering if an analysis of how frequently > functions were called, and from where, could affect how quickly they would > be stepped to. I have seen this behavior in SuperBASIC on JM/JS and > achieved often useful gains in improvements by placing the most frequently > called functions at the beginning or the program. > SuperBASIC is quite unique in that it stores the *difference* in length of a line compared to the previous line, along with its line number. This way, because the current line length is also stored in a system variable, it can search for lines in both backward and forward direction. So a proc/fn call will be faster when the definition is closer to the calling line. This is also mentioned in the Minerva documentation. > I was wondering if this was still true with the BASIC on SMSQ/Minerva. > AFAIK, Minerva is not very different in the way data structures are stored compared to Sinclair ROMs, but SMSQ is. > That let to the overloading question, which would allow the collapsing of > many functions into a single function using polymorphism. > You cannot define a proc/fn multiple times but you can check the type and usage of a parameter using the PARTYP, PARUSE, PARNAM$ and PARSTR$ functions in TK2 and act accordingly. An example of this is in my 'ls' procedure which uses an extra parameter as a flag for recursive directory searches. When this parameter is empty it only lists the current directory. Jan. -- *Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net ___ QL-Users Mailing List
