Hacking in BASIC

It feels slightly me-too though, IYSWIM.

It is. I program for pleasure, mostly, and enjoy the challenge, rather like doing crosswords. ;-)

Does Basalt fix any of the many bugs?

It was never about fixing bugs, although it does implement safe CLOSE and TIME.

Here’s another for your collection:

DO [WHILE|UNTIL <cond>]
...
IF <cond> EXIT
...
LOOP [WHILE|UNTIL <cond>]

It’s a Basalt thing I suspect. It’ll be dimming in the stack or summat.

DEFFN_ERROR
 LOCAL k%:DIM k% LOCAL TRUE
 k%!-8=!_ERROR REM more magic 
=TRUE

What!?!

I am puzzled by the second LOCAL.

It’s a Basalt thing I suspect. It’ll be dimming in the stack or summat.

Oh no it’s not! It is standard BASIC, but only in the Castle derived versions – thanks Steve.

Here is a break down.

LOCAL k%:DIM k% LOCAL TRUE

This DIMs a local block on the stack of zero extent, because TRUE=-1.

The DIMmed variable k% is therefore a pointer into the stack.

The offset at k%!-8 is the return address for the function FN_ERROR and !_ERROR is magic for !&8684, the current error handler.

So at =TRUE the interpreter returns the value TRUE to the IF and therefore looks for the return address, which is now to the error handler. Hence the equivalence to ERROR on its own.

This has not been tested very hard, so no guarantees.

I think I’ll stick to using BASIC in straightforward rather than devious ways…E&OE…

I’ve been getting more enthusiastic about Steve’s TRY idea, but with BASIC syntax:

CASE ERROR OF
  REM This is the TRY block
  PROCall_kinds_of_errors_might_happen
WHENerrornumber
  REM deal with that error
OTHERWISE
  REM deal with all other errors,
  REM or if no OTHERWISE then throw the ERROR
ENDCASE

However, it requires WHEN, OTHERWISE and ENDCASE to behave as an implicit code block terminator for the TRY code, and that requires context. That means something on the stack.

And this means that plain old CASE/ENDCASE would no longer be able to stack anything, where currently it can:

DEFPROCweird_but_legal(global%)
CASEglobal%OF
WHENFALSE:LOCALa%,b%,c%
OTHERWISE:REM global vars will be used
ENDCASE
a%=b%+c%
ENDPROC

I can’t think of a way around this that doesn’t break for any embedded CASE within the TRY block.

Adding a stacked context where previously there wasn’t one changes behaviour. This is a shame, as I really can see the utility of this construction.

Steve. Steve. Steve…

Steve. I love the TRY construction. It’s fab. I want it.

Here’s my test program:

REM Test the two kinds of CASE/ENDCASE construction

IF0^0:PRINT"This doesn't look like nemoBasic"

PRINT"Normal CASE:"
FORZ%=1TO5:PRINT;Z%":";
 CASEZ%OF
  WHEN2:PRINT"Two"
  WHEN1,3,5:PRINT"Odd"
  OTHERWISE:PRINT"Four"
 ENDCASE
NEXT
PRINT

PRINT"Successful TRY:"
CASE ERROR OF
  PRINT"This is the TRY block"
  PRINT"No errors here"
OTHERWISE
  PRINT"Error ";ERR" happened"
ENDCASE
PRINT

ONERROR:ONERROROFF:PRINT"Error ";ERR" was not handled. Stopping.":END

PRINT"Errors in TRY"
FORZ%=1TO7:PRINT;Z%":";
 CASE ERROR OF
   REM This is the TRY block
   IFZ%=1:Z%=nosuchvar
   IFZ%=2:Z%=Z%/0
   IFZ%=3:Z%=(3
   IFZ%=4:Z%=FNnothere
   IFZ%=5:WHEN:REM Effective BREAK
   IFZ%=6:mistake
   IFZ%=7:"syntax"
   REM That was it, if we get to here, success!
 WHEN26:PRINT"No such var"
 WHEN18:PRINT"Div by 0"
 WHEN27:PRINT"Missing )"
 WHEN29:PRINT"No such FN"
 WHEN4:PRINT"Mistake"
 ENDCASE
 IFZ%=5:PRINT"OK!"
NEXT

Note that in a CASEERROROF the absence of an OTHERWISE means that unhandled errors are thrown to the previous error handler. However, if there is an OTHERWISE then it gets all non-specifically-handled errors. ERR=0 is special, as always.

(My earlier idea of OTHERWISE as a success clause was silly – that’s what the end of the TRY block is, after all)

I love the TRY construction. It’s fab. I want it.

My earlier idea of OTHERWISE as a success clause was silly

Welcome to the club. ;-)

Although it would be nice to have in BASIC itself it is not necessary, because you can construct it from a normal CASE as I showed earlier. If you allow a translation phase, for example Basalt or Crunchie, you can hide the awkwardness.

DO..LOOP might be a step too far, but here is another to put your mind to:

IF <cond1> THEN
...
ELSEIF <cond2> THEN
...
ELSEIF <cond3> THEN
...
ENDIF

Pretty easy to get the same effect with CASE TRUE OF, but I think this construction is more elegant in some circumstances.

Edited to include the missing THEN keywords.

While we’re fiddling around in BASIC, is there any way that an error handler can display the call stack that lead to the error? I frequently have to resort to putting a *reportstack just before places where errors might be expected.

is there any way that an error handler can display the call stack that lead to the error?

Sore point. BBC Basic’s error handling is dumb, and this is caused by a hang-over from the translation to ARM from 6502.

On the venerable Beeb, Basic’s memory usage was broadly the same – first Basic’s workspace, then the program, then the variables, then some free space, and then “the stack”. The “stack” being where Basic sticks temporary stuff, loop and flow control structures, LOCAL variables (in a manner of speaking) and so on. However, the 6502 stack was elsewhere. So Basic’s internal machine code routine calling didn’t effect “the stack”, only the CPU stack.

On ARM it was decided to mix the two stacks, so “the stack” contains both flow-control structures (which are well defined) and whatever some routine has decided to STMFD while it does stuff. This includes exposed interfaces like SWI and CALL… and in the case of CALL and USR, the machine code then uses the same stack too.

So when an error occurs, the state of “the stack” is indeterminate. There’s junk on it. There’s also valuable flow-control structures, the PROC call stack and so on, but there’s junk there too and it can easily look like legitimate structures.

When a ONERRORLOCAL occurs, Basic not only stores the address of the error handler, it also records the stack pointer at that moment. Then, when an error occurs, it simply resets the stack pointer to this known value.

This has horrific consequences which cause real problems. It is by far the worst design decision in BBC Basic. The most obvious is that all LOCAL variables since that ONERROR suddenly become GLOBAL. This is mind-bogglingly stupid and isn’t widely-enough understood. Say you have a Wimp program whose wimp block is called q% – a very common convention. You may be tempted to reuse code by writing a routine like this:

!q%=handle%:SYS"Wimp_GetWindowState",,q%
PROCdo_something_with_window(q%+4)
...
DEFPROCdo_something_with_window(q%)
blah blah blah
ENDPROC

I have seen distributed programs that do this kind of thing. If no error occurs then it works fine. But if the PROC (or anything it calls) raises an error, the global q% has now got 4 bigger, permanently.

LOCAL works by putting a copy of the variable’s value on the stack and then setting it to zero. At ENDPROC/= it retrieves the original value and restores it. But as I’ve described, if an error occurs the contents of the stack are discarded, and all LOCALs stay global. That includes parameters (which are implicitly LOCAL unless preceded by RETURN).

It did not have to be like this. Basic could use STMFD in such a way that it could step over the junk from its own internal calls, and hence unwind the stack back to the desired level, restoring LOCALs as it went. But that isn’t how the original BBC Basic worked with a 3KB my-first-program, so it isn’t how ARM Basic works with 1MB desktop applications.

TL;DR

The short version is: It could be arranged, but it would be a significant change in behaviour.

Ideally I’d want a way of signalling the required ONERROR behaviour. NEWERROR perhaps!

Steve said

Although it would be nice to have in BASIC itself it is not necessary, because you can construct it from a normal CASE as I showed earlier.

Not in standard Basic (without poking about in workspace) and of course you do not get the encapsulation that this affords… for example:

REPEAT:REM Oh this is going to be good
  CASE ERROR OF
    UNTIL FALSE
  WHEN43:REM Not in a REPEAT
    PRINT"Ha ha!"
  ENDCASE
UNTIL TRUE
PRINT"Phew!"

This is what I was talking about when I mentioned having to give CASE a stack presence – it changes how CASE/ENDCASE interacts with other loops.

In particular, in standard Basic this minimal program is legal:

REM Short boring program
ENDCASE
REM The end

Whereas in nemoBasic that produces an error (“OS missing from CASE statement” at the moment – more accurate wording will be required!). And conversely, whereas the single line program CASE 1 OF is illegal (“Missing ENDCASE”), CASE ERROR OF ends silently without error… because it wouldn’t start looking for ENDCASE until there’s an error, and if it reaches the end of the program there is no error.

Steve also suggested

ELSEIF

ELSIF perhaps. New keywords are easy, but getting existing editors to work with them is less so, which is why I stick to the existing keywords arranged in new ways never before attempted.

That’s not chutzpah, it’s a requirement. ELSEIF cannot work for the obvious reason that it’s already valid Basic with a different meaning. ELSETHENIF would work, but is getting very ugly. CASETRUE OF is only partly a solution (quite apart from the ugly tokenisation issue) – the main problem is the difference between CASE’s and IF’s concept of “truthy”.

I had already planned to use CASE OF for this scenario. i.e. the following cannot work with CASETRUE OF:

CASE OF
WHENflags%AND1:REM b0 set
WHENflags%AND2:REM b1 set
WHENflags%AND12:REM b2 and/or b3 set
ENDCASE

Naturally I’m also wanting to do

CASE X% OF
WHEN<0:PRINT"Negative"
WHEN0TO9:PRINT"One digit"
WHEN11TO99STEP2:PRINT"Two digits and odd"
WHENlist%():PRINT"One of these values"
ENDCASE

The CASE OF construction is rather good.

I’m trying to work out how that’s any different from exactly the behaviour you’d expect from that code…

rhetorical non-question…

Re Nemo on error handling:

The short version is: It could be arranged, but it would be a significant change in behaviour.
Ideally I’d want a way of signalling the required ONERROR behaviour. NEWERROR perhaps!

If I read your post correctly, making it possible for the stack to be unwound after an error would also require fixing a little known bug relating to LOCAL ERROR handling. This would seem to me to be a perfectly acceptable change.

This would seem to me to be a perfectly acceptable change

It’s a breaking change. Consider this which specifically uses the broken LOCAL to provide contextual information about the error:

context$=""
ONERRORPROCerror
...
DEFPROCerror:LOCALA$
A$=REPORT$:IFcontext$>"":A$+=" during "+context$
context$=""
PRINT"ERROR: "A$
ENDPROC
...
DEFPROCmay_go_wrong:LOCALcontext$
context$="may_go_wrong"
x=x/0
ENDPROC

“Fixing” the LOCAL issue would break that code. So it cannot be imposed by default, it would have to be explicitly requested. I’m leaning towards using NEWERROR to set an internal flag.

Clive asked, rhetorically

I’m trying to work out

The aim is to provide the multiclause IF/ELSIF/ELSIF/ELSE/ENDIF that many languages have. It can be approximated with CASE TRUE OF and for many “values” that would be identical. e.g.

CASE TRUE OF
WHEN K%>64 AND K%<91:PRINT"Uppercase"
WHEN K%>96 AND K%<123:PRINT"Lowercase"
ENDCASE

This works because each of the comparisons evaluates only to TRUE or FALSE. However, IF is not so picky, it is only interested in FALSE (do the ELSE) or anything else (do the THEN). So most things that work as an IF don’t work in a CASE TRUE OF, for example:

X%=5

IF X%AND1 PRINT"Odd number"

CASE TRUE OF
WHEN X%AND1 :PRINT"Odd number, hello? What?!"
ENDCASE

The IF works, the WHEN does not, because X%AND1 is 1 whereas TRUE is -1.

My CASEOF construction allows “truthy” comparisons like IF, so this does work:

X%=5

CASE OF
WHEN X%AND1 :PRINT"Odd!"
ENDCASE

This is therefore a direct replacement for IF/ELSIF/ELSIF/ELSE/ENDIF.

Ah, I see what you’re getting at. I’m not so familiar with other languages as I am with BBC BASIC, so I just know about anything other than 0 being sort of TRUE without even thinking about it.

And I’ve never used CASE TRUE OF – I’ve only ever used CASE variable OF…

Not in standard Basic (without poking about in workspace)

But poking around in workspace is fun, and effective. ;-)

CASE ERROR OF
 UNTIL FALSE

Why on earth would any one do that? It is of the class of abusing loops that exists without your CASE ERROR. Keep everything properly nested and the standard BASIC works.

Truthy is a JavaScript term, but is useful for describing the behaviour of Basic’s IF.

Why on earth would any one do that?

It’s merely an illustration of the tight encapsulation, much like calling a PROC. I was demonstrating that this implementation is not the same as your example. Also see the contrived example of contextually doing a LOCAL inside a CASE – no longer possible.

which is why I stick to the existing keywords arranged in new ways never before attempted.

I am with you there. Hence ERROR LOCAL ... ERROR RESTORE for my nested errors.

ELSEIF cannot work for the obvious reason that it’s already valid Basic with a different meaning.

Its actual meaning is just what is required. The example I posted is just a continuing series of nested multi-line IF. What is missing is the correct number of ENDIF. The logic is just what you would expect, unless I am mistaken. A translation phase can insert the missing ENDIF , but otherwise BASIC goes in search of them.

he main problem is the difference between CASE’s and IF’s concept of “truthy”.

Yes. That is why the ELSEIF construct is useful over the CASE TRUE OF as you say.

It’s merely an illustration of the tight encapsulation […] doing a LOCAL inside a CASE – no longer possible.

You present programmers with a problem. CASE a% OF is not ‘encapsulated’ and they are free to do things like LOCAL, but you would introduce the very similar looking CASE ERROR OF with very different rules.

I see your

CASE X% OF

and raise you:

CASE OF <value>[,type%]
WHEN <range>[,<range>]^
...
OTHERWISE
ENDCASE

<range> is either a single value or first TO last.

type% controls in/exclusive bounds for numeric and case and accents for strings.

While we’re thinking of adapting BASIC, think about Unicode. (Or would you rather not?) Once the number of bytes in a string is not equal to the number of characters, LEN, INSTR, LEFT$, MID$, RIGHT$, CHR$, ASC() all become ambiguous.