Re: [Ql-Users] SMSQ/E and unset variables

2017-04-24 Thread Jan Bredenbeek
On 24 April 2017 at 18:27, Dilwyn Jones 
wrote:


> 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

2017-04-24 Thread Michael Bulford
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

2017-04-24 Thread Ralf Reköndt
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

2017-04-24 Thread pjwitte
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

2017-04-24 Thread Michael Bulford
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