newRPL: persistent comments in RPL code

[Claudio L.]

I just read in another thread that RPL is unmaintainable and write-only, mainly because the code cannot be properly commented. While I always keep my commented source code in a separate directory, that's not the point.
Is there interest in having comments permanently inserted into the code? It's not difficult to achieve.
What I'm proposing is that the character @, used for comments in RPL code, should compile like a string, but as a special type of object (a comment object), which gets compiled and decompiled with the code, but does nothing when executed.

Code size would increase to hold the text, of course. Execution speed would be slightly decreased by skipping those comments.

Persistence of comments could be activated/deactivated via a flag, although it should probably be on permanently, and comments should only be stripped using a special command to compile "release" versions.

I think it's worth it, any objections?

[BruceH]

(06-04-2015 04:38 PM)Claudio L. Wrote:  I think it's worth it, any objections?

What would happen with program checksums? Should the checksum be affected by the persistent comments or not? (I can imagine that it would be useful to be able to include additional comments for my own understanding but still keep the author's original checksum so I know that I haven't inadvertently changed the program).

Also, some people (not many I suspect) may keep a library of programs on a PC with comments that they then expect to be stripped when loaded on the calc. So perhaps the @ character can retain this stripping behaviour and @@ (or similar) used to indicate persistent comments?

[Claudio L.]

(06-04-2015 11:42 PM)BruceH Wrote:  What would happen with program checksums? Should the checksum be affected by the persistent comments or not? (I can imagine that it would be useful to be able to include additional comments for my own understanding but still keep the author's original checksum so I know that I haven't inadvertently changed the program).

Didn't even cross my mind. I don't see much utility in the old checksums so it is not implemented yet.
But of course, throwing in a command to calculate a CRC32 of an object would be almost trivial.

The way I see it: yes, it will change. A checksum should include all bytes in the program and that will include comments as well. You may not want to include the comments, but other people might be interested in seeing ANY changes, including comments.
To do a checksum without comments you could simply strip the comments and run the checksum afterwards. Programs should match after stripping comments if they weren't modified.

(06-04-2015 11:42 PM)BruceH Wrote:  Also, some people (not many I suspect) may keep a library of programs on a PC with comments that they then expect to be stripped when loaded on the calc. So perhaps the @ character can retain this stripping behaviour and @@ (or similar) used to indicate persistent comments?

Do you mean @ comments may be stripped and @@ will persist even after stripping comments? It could be done almost trivially, using 2 different object types (the "stripper" code would only remove one type).
The only real use I see for this would be to include a permanent copyright string at the beginning of a program, which cannot be stripped automatically, but the user can always edit the code, delete the copyright and recompile (which would indicate malice).
I like this idea. When you open a binary file on another device with a text editor, you'd see 8 bytes of garbled characters and then your nice copyright message in UTF8, followed by more garbled text.