( paren FILE

( "ccc<paren>" -- )

Extend the semantics of 6.1.0080 ( to include:

When parsing from a text file, if the end of the parse area is reached before a right parenthesis is found, refill the input buffer from the next line of the file, set >IN to zero, and resume parsing, repeating this process until either a right parenthesis is found or the end of the file is reached.


T{ ( 1 2 3 
      4 5 6 
      7 8 9 ) 11 22 33 -> 11 22 33 }T


JohanKotlinskiavatar of JohanKotlinski [297] Multi-line ( behaviorRequest for clarification2023-05-02 21:22:18

I understand the standard requires a different behavior for multi-line comments, depending on whether the source is read from a text file or not. Multi-line comments shall work when read from a text file, but fail when pasted into an interpreter or read from a block.

For practical reasons, I think it would be preferable if the behavior was same between input sources.

It makes me wonder...

  1. do you agree?
  2. what would be your preferred behavior?
  3. would it be realistic to change the standard to allow multi-line comments for all input sources?
  4. would it be realistic to change the standard to disallow multi-line comments for all input sources?

AntonErtlavatar of AntonErtl

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.

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

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

NickMessengeravatar of NickMessenger

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.

JohanKotlinskiavatar of JohanKotlinski

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

AntonErtlavatar of AntonErtl

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.

Reply New Version