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 <pjwi...@online.no> 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
