11.6.1.0080 ( paren FILE

Actually the current behaviour for blocks is that comments work within a block, but end at block boundaries. Lines in blocks are something that LIST, , and the block editor know about, but PARSE and PARSE-NAME just see the block as if it was one line, so a standard ( will do multi-line comments in blocks.

As for your questions:

1. I have not had problems due to the difference. This may be because I use ( only for stack comments and (rarely) for commenting out code withing a line, and so never use it across lines; instead, I use '' for big blocks of comments. I guess the current scheme might lead to problems if you copy and paste code containing a multi-line comment from a file onto the user input device.

2. We certainly cannot change how comments are handled in files (it would break the files). If anybody uses open (end-of-block-terminated) comments in blocks, we cannot change the block handling. For the user input device, the question of multi-line comments should not be one of breaking existing code, except if people do things like piping code with open (eol-terminated) comments into a Forth system. So if any change is possible at all, it's that of making 6.1.0080 multi-line.

Alternatively, one could de-standardize the behaviour of end-of-parse-area-terminated '(' comments in order to allow some systems to continue the current behaviour and some to change it to multi-line (and maybe some to produce an error message). But that means that you could not rely on a standard behaviour in this case, so if it's really something you want, it's not desirable.

3. If you make a proposal, somebody might come up with a real case that would break, but I don't expect it. Somebody might be nervous about breaking some unknown usage of end-of-parse-area-terminated '(' comments. And I guess the biggest problem will be that people will fail to see enough benefit in such a change to merit it. But you will only find out if you try.

4. No. I expect that several people will come up with real cases that would break.

Johan's durexForth comes with a vi-clone screen editor. It allows you to edit files on disk and press a key to evaluate them as if they were included. In an older version it had noncompliant \ ( evaluate etc that worked together to allow this. After making them compliant the editor cannot support \ comments by evaluating the buffer since it's specified to dump the entire parse area. He fixed it by having the editor split into individual lines first but that breaks ( comments. It cannot support both without essentially rewriting included.

IMO it's a flaw that included introduces the concept of "individual lines" but \ isn't extended to support them for this use case.

Hi Anton, indeed I once again misunderstood the standard, I had the wrong impression about the Block behaviour. I would agree that Interpret behaviour being different is maybe not enough of a problem to bother about. Sorry for wasting your time on a stupid question, although for sure your questions were illuminating to me.

I am interested in your comment about using '' for big block of comments. What word is that? What does it do? All the best /Johan

The word I meant is \ (it's tricky to render in markdown). I put it at the start of every commented line, and my editor helps me to do that.

I am closing this as it seems the issue is clarified.