Re: [Ql-Users] sBASIC overloading...
On Thu, Jun 28, 2018 at 2:03 AM, Wolfgang Lenerz via Ql-Users < ql-users@lists.q-v-d.com> wrote: > Hi, > > I made a small Sbasic testcase (SMSQE, not QDOS). > > That seems a quite definitive test case. Asked and answered! Thank you. -- Dave Park d...@sinclairql.com ___ QL-Users Mailing List
Re: [Ql-Users] sBASIC overloading...
I think it depends on which types of variables you're coercing... In this case, because integers are stored as floats and are a wicked lie, ints and floats are already the same thing logically speaking. So the only invalid coercion is string to float where the string contents are of the wrong type. I wonder the history behind the shortcut? On Thu, Jun 28, 2018 at 1:01 AM, Wolfgang Lenerz via Ql-Users < ql-users@lists.q-v-d.com> wrote: > Hi, > > I can't help but wonder whether the time taken to parse all your > parameters to check whether they are the right type won't be longer than > having several procedures. > > Wolfgang > > > > > I'll make sure to respond right away in future, before I've fully > > understood the subtleties and implications of your replies. :D > > > > I was digesting the reply. I've been neck deep in developing a USB > keyboard > > solution for the QL - a project that has become a multi-headed beast that > > required getting into elements of the 8302/8049 relationship I just never > > knew I'd have to think about. Also neck deep in fence building after a > > neigborhood dog broke into the pen and killed many of my chickens. > > > > It does seem that coercion gives similar results - if everything is > passed > > as a string, it can be coerced however we'd like, as long as the data is > > checked for validity. > > > > It does seem the functionality of overloading can be implemented in > > roundabout yet still brief and readable ways. > > > > Thank you. > > > > > > > > On Tue, Jun 26, 2018 at 1:57 PM, Per Witte via Ql-Users < > > ql-users@lists.q-v-d.com> wrote: > > > >> So sorry for wasting my time trying to answer your question. It wont > happen > >> again. > >> > >> On 21 June 2018 at 16:38, Per Witte wrote: > >> > >>> 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 < > >> ql-users@lists.q-v-d.com > 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 > >> > > > > > > > ___ > QL-Users Mailing List > -- Dave Park d...@sinclairql.com ___ QL-Users Mailing List
Re: [Ql-Users] sBASIC overloading...
Hi, I made a small Sbasic testcase (SMSQE, not QDOS). I made a program with procedures all called "abcdefghijklmnopqrt"+ a 5 digit number at the end. The program starts at line 100, is increased by one and very 12th line a new 10 line procedure is created. The first statement therein is "return", so that I don't meausre the body of the procedure. The rest of the lines on the procdure are filled with "Print". (so 100 def proc abcdefghijklmnopqrt00100 101 return 102 print ... 110 print 111 end def 112 def proc abcdefghijklmnopqrt00112 etc, until just after line 3. The last procedure then is always 31000 def proc abcdefghijklmnopqrt31000 I then measured how long it takes to call the first procedure and the last procedure. Measured with the millisecond timer of SMSQmulator: calling the fist procedure 1 million times takes 5742 milliseconds calling the last procedure 1 million times takes 5768 milliseconds Wolfgang > > I can't help but wonder whether the time taken to parse all your > parameters to check whether they are the right type won't be longer than > having several procedures. > > Wolfgang > > > >> I'll make sure to respond right away in future, before I've fully >> understood the subtleties and implications of your replies. :D >> >> I was digesting the reply. I've been neck deep in developing a USB keyboard >> solution for the QL - a project that has become a multi-headed beast that >> required getting into elements of the 8302/8049 relationship I just never >> knew I'd have to think about. Also neck deep in fence building after a >> neigborhood dog broke into the pen and killed many of my chickens. >> >> It does seem that coercion gives similar results - if everything is passed >> as a string, it can be coerced however we'd like, as long as the data is >> checked for validity. >> >> It does seem the functionality of overloading can be implemented in >> roundabout yet still brief and readable ways. >> >> Thank you. >> >> >> >> On Tue, Jun 26, 2018 at 1:57 PM, Per Witte via Ql-Users < >> ql-users@lists.q-v-d.com> wrote: >> >>> So sorry for wasting my time trying to answer your question. It wont happen >>> again. >>> >>> On 21 June 2018 at 16:38, Per Witte wrote: >>> 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 < >>> ql-users@lists.q-v-d.com > 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 >>> >> >> >> > ___ > QL-Users Mailing List > > ___ QL-Users Mailing List
