newRPL: Comments revisited

[Claudio L.]

Wow, never thought something like comments would require so much thinking...

(11-03-2015 10:01 PM)matthiaspaul Wrote:  This is somewhat different from what I assumed. I assumed only @@ comments would end up in the compiled object, whereas @ and @@@ comments would be removed immediately - and therefore just useful when using an external editor. According to your description it depends on a special flag.

Correct, the whole idea is to make comments more persistent for in-calc editing. On an external editor comments are the same as they've always been.

(11-03-2015 10:01 PM)matthiaspaul Wrote:  Is there a length limit for comment lines?

No limit. Same as strings.

(11-03-2015 10:01 PM)matthiaspaul Wrote:  How are the comments stored internally? Is it a header indicating the type of comment and its size, so it can be "skipped", or are the @, @@, @@@ characters actually stored as part of the comment and thus wasting additional space?

Just a string with a different prolog.
Right now, the way it's implemented is that the prolog is the same for all comments. Then the second and possibly the third @ symbol are stored as part of the text (the first one isn't). The ending characters are always stored as part of the text (be it a newline or an @ symbol) to preserve the original formatting.

(11-03-2015 10:01 PM)matthiaspaul Wrote:  Are comments patchable from outside (that is, no checksums etc.)? This would be desirable to implant version control info, serial numbers, perhaps even fixup data. Is it even possible to change the size of an embedded comment in a binary without invalidating the compiled object?

newRPL does not use checksums (yet). So yes, in theory you could write self-commenting code, but I don't see any reason to create RPL commands to do such a thing. You'd have to use the low-level functions available from C, but it's possible.

(11-03-2015 10:01 PM)matthiaspaul Wrote:  If comments are patchable, is the system safe when the number of newline characters in the comment changes through patching?

Why would the number of newline characters compromise the system? I can see a million ways to crash the system if you try to patch the comments in a binary object, but adding newlines won't necessarily do it.
Patching comments can only be done through low-level access, and once you are doing low-level things, not only you can patch a comment, you can also overwrite the whole object, and write outside the object, and the stack, and the whole RAM, even erase the Flash and brick your calculator.
But not from within RPL, you'd have to write a library in C to do that.

(11-03-2015 10:01 PM)matthiaspaul Wrote:  Is it possible for the RPL system to somehow retrieve data from inside comments? If so, build date or version info could be extracted from comments and processed or displayed (instead of putting this in some specially crafted variables).

All you have to do is decompile the object and analyze the resulting source code to detect those specially crafted comments and do something useful. Doxygen comes to mind, as the best example of using specially crafted comment lines to do something good.
Same thing works for "patching" comments by decompiling the code, patching the text and recompiling it. This is the correct RPL way of doing it, since objects should all be copy-on-write, no in-place patching should be allowed.