newRPL: Comments revisited

[Claudio L.]

(11-04-2015 04:31 PM)matthiaspaul Wrote:  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...

You are right, the way it was implemented (as a universal string object for all comment types) leaves no room for crashes due to newlines (hence you left me scratching my head wondering how that could be), but perhaps if I had coded a different kind of object for the single liners and you added a newline it wouldn't be allowed.
But the current implementation only distinguishes the type of comment during compile time, to determine if a newline ends the comment or not. After compile is finished, a comment is a comment, nothing can break it.

(11-04-2015 04:31 PM)matthiaspaul Wrote:  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).

Yes, although we could have a dedicated metadata object too... so comments remain just comments, and true metadata cannot be removed with STRIPCOMMENTS. I wrote a post about a structured data object a short while back that didn't get any attention, but that's probably where metadata belongs, in some sort of opaque LIBDATA object.