newRPL: Comments revisited

[matthiaspaul]

(11-04-2015 03:21 AM)Claudio L. Wrote:  Wow, never thought something like comments would require so much thinking...

Well, you asked for comments... ;-)

(11-04-2015 03:21 AM)Claudio L. Wrote:  

(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.

Okay, sounds good as it is, but still leaves some tiny potential for further improvement.

(11-04-2015 03:21 AM)Claudio L. Wrote:  

(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-04-2015 03:21 AM)Claudio L. Wrote:  

(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.

Well, before your answer (above) I had no insight into your implementation. Since you mentioned that newlines at the end of a comment are a special case, I can see potential implementations which would be breakable by inserting newlines into a comment. Since you asked for comments on your specification, I was just going through my mental checklist of things that could go wrong or could get into the way of future expansion, and wanted to make sure, that they are non-issues in your implementation...

Quote:Patching comments can only be done through low-level access

I was thinking about stuff like libraries with embedded comments in a cross-development environment, where f.e. a version control system and PC tools might be used to patch files. In-system patching might, perhaps, be useful for tools like runtime profilers or debuggers (to store some kind of "metadata" in comments).

Greetings,

Matthias