BASLOAD breaks BASIC DEF statement

[jestin]

The BASIC DEF statement should allow a user to define functions that can be called later. It requires the symbol used for the function to begin with FN, such as DEF FND(N)=INT(RND(1)*N)+1.

When BASLOAD loads this program, it replaces the FN* name with a generated symbol, so that BASIC can no longer interpret it as a function:

This breaks the DEF statement such that it cannot be used with BASLOAD. If BASLOAD leaves any FN* symbols alone when translating, I believe it would fix this bug.

[jestin]

I found out that the parser works if you separate the FN from the function name. So while DEF FND(N)=INT(RND(1)*N)+1 does not work, DEF FN D(N)=INT(RND(1)*N)+1 does, provided you also call the function with the space: PRINT FN D(6).

I don't know if this workaround is enough to consider closing this bug.

[stefan-b-jakobsson]

DEF and FN are two BASIC commands. Requiring them to be separated from other code isn't really a workaround, even though the built-in interpreter accepts that you skip all spaces.

BASLOAD requires identifiers to be separated by a char that can't be part of an identifier. This is to make parsing source code with long symbol names user-friendly.

Not requiring spaces and long symbol names would be sort of possible, but a symbol could then not contain a BASIC command. I'm pretty sure users would be caught by this over and over, and that it would be a bad idea.

Some symbol name examples:

• PRINTME would always be interpreted as PRINT ME, that is printing the value of ME
• CLOSEFILE would be interpreted as CLOSE FILE, that is closing the file FILE
• ASTRONAUT would be interpreted as ASTR ON AUT, as ON is a command

[mooinglemur]

I think this issue probably stems from a misunderstanding of what is happening here. DEF and FN are two separate keywords in CBM basic. The FN is not part of the identifier but a keyword all on its own. The syntax is DEF FN <identifier>(<param>).... CBM basic does not require spaces in between keywords and variable names, nor even two consecutive keywords, but BASLOAD does, for reasons including the potential unintended consequences Stefan alluded to, of supporting long identifiers and if it were to support keywords not surrounded by spaces.

tl;dr, not a bug, IMO. The "workaround" is indeed the intended syntax.

[jestin]

That sounds correct. I learned this convention from the old manuals, which specify that FN is part of the function name, and not a keyword onto itself (meaning it can't be separated with a space):

Clearly, that's not really the case. I've learned these manuals often oversimplify some of their explanations, and I think this might be the case here. Probably best to close this bug, and update BASIC docs to make it clear that FN isn't part of the symbol.