(free42) PGM Copy/Paste and @

[Werner]

Free42 seems to recognize @ as a comment character - just like the DM42 encoder/decoder page does.
However, it does not work after a number that can be mistaken for a line number, eg:

Code:

>LBL "RL"
 1
 RTN

pastes just fine, but

Code:

>LBL "RL"
 1 @
 RTN

doesn't - it omits the line with '1'. As a workaround for now I insert a decimal point, then it works.

Moreover, paste does not handle tabs before the comment char - I don't consider that a bug, just a nuisance, as tabs allow to line up the comment chars easily in a listing.

Cheers, Werner

[Thomas Okken]

(03-20-2018 10:03 AM)Werner Wrote:  Free42 seems to recognize @ as a comment character - just like the DM42 encoder/decoder page does.
However, it does not work after a number that can be mistaken for a line number

Actually, it doesn't recognize any comment characters. Once it has parsed a complete command, it simply ignores whatever follows on the current line.

There are two cases where it's a bit more complicated: strings and numbers. Strings (including commands with string arguments) are tricky because double quote characters aren't escaped, so you can't just stop parsing when you see a second double quote character; you have to keep going until the end of the line, or until you reach the maximum string length, until you can be sure where the string ends.

Numbers are complicated because a number can be a line number, or it can be a number without a line number. The logic that chooses between these two cases could probably use some improvement. The way it works now, "1 @" is considered a numbered line with an unrecognized command, so it is skipped. It's not easy to see how this *should* work... one possibility that has crossed my mind is to require uniformity in line numbering, i.e. either all lines should have line numbers, or none of them. That still leaves an ambiguity if a program *starts* with an ambiguous line, but it would fix the ambiguities in most cases.

[Werner]

Thanks for the explanation.
The difference between line numbers and numbers is, for me, easy: line numbers start in the first position, numbers don't. So

Code:

10 10 10

would then be the 10th line with the number 10 in it, with 10 as comment ;-)

and

Code:

 10

is simply 10 without a line number.

Now, about TABs:
Sometimes they are accepted, sometimes they're not. eg.

X=0?[TAB]comment

is NOT accepted, but

>LBL "WERNER"[TAB]comment

is. Strange - as in both cases the command is fully defined.

Cheers, Werner

[Thomas Okken]

I've come across listings where there is white space before line numbers, so I wrote the parser to be tolerant of that.

Regarding tabs, that sounds like the code that looks for the end of a command should be more lenient. Right now it accepts spaces and line breaks, but apparently not tabs. Also note that commands with string arguments are handled differently -- see my previous post -- so it's plausible that tab treatment is inconsistent across the different code paths.

N.B. Keep the suggestions coming in this thread. I'm on vacation right now so no code changes will happen right away, but when I do revisit the program parser, I'll check this thread for problems and suggestions.

[Werner]

Well, since you ask ;-)

'x' (lowercase x) as multiplication character is not recognized, and I think it used to be.
I have to provide '*' or '×' (look closely - this is the real 42S character - but that is not readily available on my keyboard). Okay.
But then why does it not recognize 'RCL* ST Z' ? There, the only option is the real 42S character.
I prefer having lowercase x's, but I can live with '*' if they would be accepted everywhere.

Just found out this one:

RCL/ ST Z is not recognized, but
STO/ ST Z is

Hm apparently it's the RCL's that are the problem here as STO* is accepted.

Cheers, and enjoy the holidays ;-)
Werner

[Thomas Okken]

(03-20-2018 03:06 PM)Werner Wrote:  'x' (lowercase x) as multiplication character is not recognized, and I think it used to be.

Not in Free42 as far as I recall, but maybe in txt2raw. Either way, that's a reasonable change to make, and so is...

(03-20-2018 03:06 PM)Werner Wrote:  But then why does it not recognize 'RCL* ST Z' ? There, the only option is the real 42S character.
I prefer having lowercase x's, but I can live with '*' if they would be accepted everywhere.

Just found out this one:

RCL/ ST Z is not recognized, but
STO/ ST Z is

Hm apparently it's the RCL's that are the problem here as STO* is accepted.

Basically, the parser expects 42S spellings, but it applies certain substitutions to make it handle 41 listings as well. It does not, as a rule, handle mixtures of those spellings within an instruction, but I guess it would be better if it did, since not all listings are actual 100% consistent print-out captures, and humans shouldn't have to worry about the differences between STO*, ST*, STOx, and STO×, or between STO ST Z and STO Z, etc. etc. etc.

[toml_12953]

(03-20-2018 12:06 PM)Thomas Okken Wrote:  Numbers are complicated because a number can be a line number, or it can be a number without a line number. The logic that chooses between these two cases could probably use some improvement. The way it works now, "1 @" is considered a numbered line with an unrecognized command, so it is skipped. It's not easy to see how this *should* work

I'd say it should be interpreted just as if the @ wasn't there.

Code:

LBL A
1
RTN

would just return a 1 on the stack, wouldn't it?

[Thomas Okken]

(03-20-2018 03:37 PM)toml_12953 Wrote:  I'd say it should be interpreted just as if the @ wasn't there.

That's only the obvious approach if you say @ is a comment delimiter.

Consider:

10 SIM

where SIM is a mis-typed SIN.
The current code treats this as a bad line and skips it; aggressively recognizing numbers as unnumbered number literals would cause this to be interpreted as 10.

I decided not to use comment delimiters because most commented program listings that I've seen don't have them (not needed because those listings were written to be read by humans only), or they use arbitrary ones, including @ but also ; or : etc.

[Werner]

(about lowercase x for multiplication)

Quote:Not in Free42 as far as I recall, but maybe in txt2raw

Yes, that was probably where I used it.

In the same vein, please allow '#' for '!=' as in
X#0?
etc.
That's maybe the case in txt2raw as well ;-)

Cheers, Werner