BASIC function and procedure names

It appears that apart from the underscore (CHR$95), only CHR$64, the “at” sign or arobas, and CHR$96, the “`” mark resembling a closing single quote, can be used in the names of PROCs and FNs in addition to actual letters and numbers in BASIC.

I would like to use them to differentiate between PROCs which deal with strings and those for integer numbers.

If it were possible to use them, $ and % would be ideal, but as it is not, which of these two available characters would be most appropriate to designate use with strings and which with integers.

My uses are:

PROC_Debug`()

and

PROC_Debug@()

but which would be best/most-appropriate for each purpose? I don’t want to make an arbitrary choice without any advice!

My initial leaning would be ` for strings and @ for integers, but I think that is informed by the “quote” idea and the use of @ in number formatting.

Any opinions based on better logic?

You may need to be aware of this bug to do with using the @ sign in PROC/FN names.

This isn’t a show-stopper (you just have to be careful when selecting PROC/FN names) but it does smack of “accident waiting to happen”.

You may need to be aware of this bug to do with using the @ sign in PROC/FN names.

Thank you! Interesting. I did want to use both “just for the look”, being then of equal length. As @ comes before` in the ASCII character set, the problem shouldn’t arise, but I can see it could have if I used “debug” and “debug@”. But “debug`” and “debug@” should be (?) OK.

Thank you for that information!

I’m just devising some routines for monitoring and logging variables in my own programs under development, but want to get it “right” in case anyone else wants to use it later!

I’d be leaning towards DebugS, DebugI, DebugH, etc.
(String, Integer, Hex)

I don’t feel it’s particularly useful for future maintenance to assign meanings to seemingly arbitrary symbols.

I don’t feel it’s particularly useful for future maintenance to assign meanings to seemingly arbitrary symbols.

I increasingly think you are right. Why don’t I just use, say, _dbgSTR and _dbgINT, shortening the “debug” to keep the statements short as it’s convenient to keep them to a “tab” on the RHS of the edit page so that they can easily be identified when required.

I’ve been using 2 arguments,the first the variable being evaluated and the second a descriptor string such as the variable name followed by # to help identify a particular line or set of lines.

2 routines to make the references as easy to enter as I can.

These data are printed to the screen nicely formatted, and squirted to a file in case anything less-transient is needed.

I’m just devising some routines for monitoring and logging variables in my own programs under development

[blatant plug] Have you looked at my Reporter? That is exactly what it is designed to do, especially in BASIC programs. A simple *Report var1% var2$ var3 ... will display for each variable it’s name and value in a scrollable window, which can be saved to a file if required. The display can include memory, system variables, Traces, changes to variables, colours, and much much more. See website for details.

Sorry for the delay, I’ve been having connectivity issues.

Stuart suggested

You may need to be aware of this bug

There’s an old software engineering saying I was advised of in my youth:

Question: If you are peer reviewing 100 lines of code and there’s an off-by-one error in one line, how many lines are suspect?

Answer: Everything they’re ever bloody written.

This is an ever-bug that is easily fixed by updating your documentation (and compressors), as it’s a bit late to fix in BBC Basic. Naturally it’s been fixed in nemoBasic for a long time:

The cause is the disagreement between PROC/FN and variables as to whether @ is a valid symbol character. This is a problem because in the original code the same stub function is used to check character validity for both variables and PROC/FN when looking for DEF (and only when looking for DEF).

So despite claims to the contrary, @ is NOT a valid character in PROC/FN names in BBC Basic (though it is in nemoBasic). And it’s broken in RO BBC Basic because it was broken on the Beeb too.

Just checked some compressors set to rename PROC/FNs:

• Celerity – nemo
• StrongBS – Molsen Alshayef
• BasCrunch – Ragnar Hafstað
• BasCompress – Cy Booker

None introduced an @ in a PROC/FN name (not applicable to Celerity anyway).

However, when given a file containing such a construction (which may or may not work depending on ordering):

• Celerity – Perfectly defined all PROC/FNs without confusion, effectively repairing the file.
• StrongBS – Perfectly renamed all PROC/FNs to not use @ without getting confused, repairing the file.
• BasCrunch – Renamed all PROC/FNs but retained @ in the same place (without getting otherwise confused). The resulting file will run only if the original did.
• BasCompress – Failed with errors due to truncating the @ and therefore mistaking names.

I’ve always been of the opinion that StrongBS is the best Basic compressor (though you have to switch some settings off because they’re flawed). It produces the most compact code.

Celerity is an optimiser rather than a compressor and is generally used to post-process StrongBS output – it pre-creates Basic’s workspace with all PROC/FNs and variables already defined in an optimal order.

You forgot Crunchie.

I’ve always been of the opinion that StrongBS is the best Basic compressor

It appealed to me as well, particularly as it ran on RO5 which others did not. But it has some very serious flaws, and when I eventually managed to contact Mohsen he confirmed he no longer had the sources, so it was un-maintainable.

I switched my allegiance to Crunchie.

StrongBS

To be clear, I meant v2.10 not v3 which I found to be unusable.

In 2.1 I have the following switched off, presumably because I found them to be unreliable or plain broken:

Concatenate directives
Remove empty procedures
Concatenate IF...ENDIF
Remove brackets
Remove empty IF
Remove empty CASE
Remove empty WHEN
Remove empty OTHERWISE
Convert CASE to IF

Rick remarked

forgot

Can’t forget what one didn’t know, thank you! But I note that our lamented friend writes

Because a name must contain only identifier characters, Crunchie does not crunch routine names that contain the ‘@’ character.

So that answers that.

Incidentally, it failed totally on the first three line program I tried, so I won’t be using it for anything.

Incidentally, it failed totally

That’s an interesting fault. It’s probably a fairly simple fix, but…

How it went wrong (the credit being the second line) implied that it expected the first line to be in the form: REM >progname
If you insert this, it works as expected.

[later] Yup, looking at the source there’s special handling for the first line (in a function called FNfirst_line).

There probably ought to be a switch to turn that off, but…

[even later] The manual says: Note that CRUNCH does not crunch the first line, nor does Crunchie. This should start with REM> and be followed by the name of the file.

Does nemoBASIC’s CRUNCH treat the first line differently?

Rick regurgitated

CRUNCH does not crunch the first line

Rubbish.

It doesn’t if the first line is a REM> line.

Let me be clear.

BBC Basic absolutely does CRUNCH the first line. Always.

HOWEVER, a REM in the first line will be preserved. This is to ensure that error messages from LIBRARYs are helpful.

But statements that Basic “does not CRUNCH” the first line, or there being something special about “REM>” are false.

First line is CRUNCHed. If it is a REM it is not discarded regardless of b2 of the flags.

Unlike Knuth I have not only proven this to be true, I’ve actually tried it.

Does BASIC – with flags set leave the REMs behind when loading a file?

There’s two ways Basic decides to CRUNCH the program:

1. You told it to with CRUNCH flags

2. You loaded a program (or supplied it in memory) in the command line or loaded a file with LIBRARY… when BASIC$Crunch exists¹ (value unimportant) – and it uses flags = 15

If bit 2 of the flags is set, it will remove all REMs except one in the first line of the program.

All other CRUNCH changes affect all lines equally. In summary:

If bit 0: Remove spaces before statements
If bit 1: Remove space within statements
If bit 2 and not first line: Remove REM
If bit 3: Remove empty statements
If bit 4 (manual only): Remove blank lines

¹ Added in RO3

Okay, but good luck arguing the point with the author. ;)

I tried removing the call to first_line (and let the normal processing take over) but the cruncher hung up on your example. Clearly there’s something going on in there that can’t just be skipped over. Pfft.

Time to feed the furry and then consume a kg of lasagna while enjoying TBM…

I’m currently fretting about comments inside assembly.

Short version: REM normally extends to the end of the line… but not inside the assembler. This causes great difficulty because the tokeniser doesn’t know that, and fails to tokenise anything after a REM (obviously).

But stuff does get executed after a REM inside assembly. e.g.

Basic executes the orange underline correctly.
Basic tries to execute the red underline, but the PRINT hasn’t been tokenised, so it explodes.

I really want to make REM extend to the end of the line inside the assembler too. But that’s technically an incompatibility.

You’d expect a tokeniser to remove REMs, but even CRUNCH screws up the above program, removing EVERYTHING after the REMs, killing the program in the process.

I know this is off topic, but it reminds me of a problem a mate of mine had with some embedded C. His character generator statements were fine until one point, after which all characters were off by one. It turned out that he had ended every line with the character in a comment. It went wrong after the backslash, because that’s taken as a line continuation character – so the next character was not compiled.

So the line continuation took priority over the comment.

Parsing can be hard. In the REM case it’s different parts of the same system disagreeing about the parsing… which makes it somewhat harder for the user.

FWIW I’ve restored REM’s expected behaviour in nemoBasic.

Historical context: The original AB did not have any comments in assembly. But in Arthur 0.3 \ ; REM were added as synonyms, which directly disagrees with the tokeniser. So the bug was there from the start of Arthur.