Re: [Ql-Users] SMSQ/E and unset variables
On 24 April 2017 at 18:27, Dilwyn Joneswrote: > When SBASIC was first mooted, I remember that there was at the time > discussion that other BASICs gave variables default zero value rather than > stopping with an error - "why couldn't the QL do this?" > > Don't know if that influenced Tony Tebby to make SBASIC variables behave > in this way or not, or was that just coincidence? > I've been struggling with this issue too when adapting the Spectrum's BASIC for BASICODE, which was largely based on M$ BASIC. This allowed default values for variables, which broke computers like the Spectrum and BBC. The official BASICODE spec required proper initialisation of variables but this was a common mistake among programmers that went undetected many times because of poor testing before airing (obviously they used a C64 as testing machine ;)). Since my adapted BASIC was expected to be used mainly to run existing programs I decided to allow defaults (and leave out syntax checks at entry too). So, default variable values might probably be a good thing to run BASIC programs converted from other platforms, but a bad thing when developing your own. -- *Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E and unset variables
Hi all, Thanks for your comments. I will look into both XREF and QREF which I have on my system. My latest thoughts are that perhaps we can combine the best of both worlds. We can continue to have default values of zero in the case of locals, while at the same time give an error if no value is available. Any global variables used will need to be initialised. Locals do get initialised and so are seen as bona fide variables. Looking at the SB name table, this is easy to see, even using SBASIC. Using Turbo toolkit, a "type" function can be defined as ... DEFine FuNction type(var) LOCal var$(127) var$ = PARNAM$(1) RETurn BASIC_B%(BASIC_L(24)+BASIC_INDEX%(var$)*8) END DEFine type This function returns 2 if var has a value, else zero. By giving an error, this will trap both spelling mistakes and also variables accessed out of scope. Michael Bulford ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E and unset variables
Yes, everyone should read "A Brief History". But exactly this case was not bespoken ;-). Ralf Am 24.04.2017 um 18:27 schrieb Dilwyn Jones: When QDOS evaluates an expression and encounters a variable with no value assigned, it STOPs with “error in expression” and reports the line number. The programmer may well have made some spelling mistake, and can immediately make a correction. QDOS is doing exactly what the programmer wants. Can SMSQ/E be upgraded to follow suit? Currently, in the above-mentioned case, SMSQ/E will use a zero value and will carry on blindly with no error reported. The assumption is made that any new variable will have a default value of zero. This behaviour does not take account of the fact that people are human and will sometimes make spelling mistakes. The unintentional mistake gets buried and lost in the middle of the code. I can spend a great deal of time and effort composing a program; I can type it all in, and can even double check it, but I can still overlook things. After writing a program in SMSQ/E, I can never be certain that it is free of typos. There is this constant anxiety in the mind. Programming can be difficult, even without the additional workload required of having to track down possible spelling mistakes, when there might be none at all - one can never tell. QDOS is much friendlier in this respect. This is why I would like for SMSQ/E to be upgraded to act like QDOS. If this would entail a slight loss of efficiency, then that would be acceptable. For me, the most important aspect of programming is to be able to write code that is going to work as intended. If SMSQ/E could be upgraded, then this would mean that all new variables would need to be initialised with values before they are used. This would apply to both global and local variables in procedure/functions. However, this is a recognised good practice in any case. It is good practice because these initialisations are being documented. We have to remember that others will want to look at and understand the code we write. SMSQ/E would be enforcing this desirable state of affairs, as QDOS does. Michael Bulford When SBASIC was first mooted, I remember that there was at the time discussion that other BASICs gave variables default zero value rather than stopping with an error - "why couldn't the QL do this?" Don't know if that influenced Tony Tebby to make SBASIC variables behave in this way or not, or was that just coincidence? Dilwyn ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E and unset variables
I agree. Its annoying. In the mean time you could try DP's XREF utility. It lists all variables alphabetically together with the line number on which it is defined and on which it is used. This quickly reveals spelling mistakes and provides other useful debugging information. Works a doddle on SMSQ/E too. Per On 24/04/2017 12:46, Michael Bulford wrote: Hi all, When QDOS evaluates an expression and encounters a variable with no value assigned, it STOPs with “error in expression” and reports the line number. The programmer may well have made some spelling mistake, and can immediately make a correction. QDOS is doing exactly what the programmer wants. Can SMSQ/E be upgraded to follow suit? Currently, in the above-mentioned case, SMSQ/E will use a zero value and will carry on blindly with no error reported. The assumption is made that any new variable will have a default value of zero. This behaviour does not take account of the fact that people are human and will sometimes make spelling mistakes. The unintentional mistake gets buried and lost in the middle of the code. I can spend a great deal of time and effort composing a program; I can type it all in, and can even double check it, but I can still overlook things. After writing a program in SMSQ/E, I can never be certain that it is free of typos. There is this constant anxiety in the mind. Programming can be difficult, even without the additional workload required of having to track down possible spelling mistakes, when there might be none at all - one can never tell. QDOS is much friendlier in this respect. This is why I would like for SMSQ/E to be upgraded to act like QDOS. If this would entail a slight loss of efficiency, then that would be acceptable. For me, the most important aspect of programming is to be able to write code that is going to work as intended. If SMSQ/E could be upgraded, then this would mean that all new variables would need to be initialised with values before they are used. This would apply to both global and local variables in procedure/functions. However, this is a recognised good practice in any case. It is good practice because these initialisations are being documented. We have to remember that others will want to look at and understand the code we write. SMSQ/E would be enforcing this desirable state of affairs, as QDOS does. Michael Bulford ___ QL-Users Mailing List ___ QL-Users Mailing List
[Ql-Users] SMSQ/E and unset variables
Hi all, When QDOS evaluates an expression and encounters a variable with no value assigned, it STOPs with “error in expression” and reports the line number. The programmer may well have made some spelling mistake, and can immediately make a correction. QDOS is doing exactly what the programmer wants. Can SMSQ/E be upgraded to follow suit? Currently, in the above-mentioned case, SMSQ/E will use a zero value and will carry on blindly with no error reported. The assumption is made that any new variable will have a default value of zero. This behaviour does not take account of the fact that people are human and will sometimes make spelling mistakes. The unintentional mistake gets buried and lost in the middle of the code. I can spend a great deal of time and effort composing a program; I can type it all in, and can even double check it, but I can still overlook things. After writing a program in SMSQ/E, I can never be certain that it is free of typos. There is this constant anxiety in the mind. Programming can be difficult, even without the additional workload required of having to track down possible spelling mistakes, when there might be none at all - one can never tell. QDOS is much friendlier in this respect. This is why I would like for SMSQ/E to be upgraded to act like QDOS. If this would entail a slight loss of efficiency, then that would be acceptable. For me, the most important aspect of programming is to be able to write code that is going to work as intended. If SMSQ/E could be upgraded, then this would mean that all new variables would need to be initialised with values before they are used. This would apply to both global and local variables in procedure/functions. However, this is a recognised good practice in any case. It is good practice because these initialisations are being documented. We have to remember that others will want to look at and understand the code we write. SMSQ/E would be enforcing this desirable state of affairs, as QDOS does. Michael Bulford ___ QL-Users Mailing List