Digest #107 2020-08-02
Contributions
requestClarification - What happens when parse reaches the end of the parse area and the parse delimiter was not found?
The text says if the parse area is empty a string of length zero is returned. This suggests that not finding the delimiter for something other than length zero also ends the parse. The reason I'm asking is there was something in the old standard about refilling the parse area when parsing from a file... I'm not sure if it's in this standard. If that's true then it conflicts with this. My forth currently loads the entire file into a buffer and treats the end of the buffer as the end of the parse area. And treats one line from the terminal also as one buffer. I figured it would be better to not have the interpreter get stuck in a looking for an end delimiter state over multiple lines if the user forgot to put one in... But when parsing from a file it does allow carriage returns to be in the string returned from parse. Is treating reaching the end of the parse area the same as finding the end delimiter the intent of the standard for PARSE? Also... I was wondering if loading an entire file into a buffer and doing EVALUATE on the whole file buffer in one go in keeping with the spirit of the standard? (It really is a lot faster and simpler than doing multiple reads from a file.)
Replies
requestClarification - Does the wording of the rules imply that if you SYNONYM a word with the same name in the same wordlist and then 'look it up', you will get the old word?
The part "For both strings skip leading space delimiters" is extra since the definition of parsing a name already covers this. Someone might wonder what kinds of strings since the word string is not used after oldname and newname. What about just removing "For both strings skip leading space delimiters"?
requestClarification - Does the wording of the rules imply that if you SYNONYM a word with the same name in the same wordlist and then 'look it up', you will get the old word?
Just thought of something else. Do the new word name strings and old word name strings have to be on the same line? Like if you are loading from a file? And some implementations have the same execution token while others do not... If not, then something like this might be clearer:
Parse two word name strings newname and oldname. Note that both word name strings may have more than one leading delimiter. Find the oldname in the search order, and get it's semantics (cfa pfa, runtime compiletime behavior... whatever you are calling it?). Define newname with the semantics of old name and add it to the current new word wordlist. Note that newname may be the same as oldname. Note that newname may have a different execution token than old name.
requestClarification - What happens when parse reaches the end of the parse area and the parse delimiter was not found?
The text says if the parse area is empty a string of length zero is returned. This suggests that not finding the delimiter for something other than length zero also ends the parse. The reason I'm asking is there was something in the old standard about refilling the parse area when parsing from a file... I'm not sure if it's in this standard. If that's true then it conflicts with this.
If the delimiter is not found, PARSE will normally return the same string as it would if the parse area was one char longer and the final char was the one sought. It's possible to check for this condition if you need to by comparing the length returned with the length of the remaining parse area before PARSE was called.
REFILL allows the same definition to be used for potentially multi-line parses from any source. The general form would be something like:
begin begin incomplete-parse while ... refill 0= until
Is treating reaching the end of the parse area the same as finding the end delimiter the intent of the standard for PARSE?
Yes.
Also... I was wondering if loading an entire file into a buffer and doing EVALUATE on the whole file buffer in one go in keeping with the spirit of the standard? (It really is a lot faster and simpler than doing multiple reads from a file.)
That's almost possible (I've done it in the past) if you convert all line delimiters to blank space when you load the load. But then you are treating the entire file as one line and you will run into problems if the code contains words like \ that are looking for line delimiters.
Alternatively, your system could have SOURCE return the length to the next line delimiter and REFILL skip over the line delimiter.
requestClarification - What happens when parse reaches the end of the parse area and the parse delimiter was not found?
"That's almost possible (I've done it in the past) if you convert all line delimiters to blank space when you load the load. But then you are treating the entire file as one line and you will run into problems if the code contains words like \ that are looking for line delimiters."
It works. I don't convert line delimiters to blank spaces. I use the loaded file buffer as is.
For parsing words I parse for a set of delimiters instead of just a space. This is in the current standard although it says control characters. The set of delimiters I use are: { space, line feed, tab, vertical tab, back space, carriage return, and form feed }
For line comment I use a modified PARSE. This is technically not in the standard. The modified wording used for if you include the block word set would make this follow the standard, but I'm not sure if this wording has been added for parsing from files yet. I'm kinda hoping it would be. Instead of parsing for just one character, I parse for a set, which is: { line feed, vertical tab, back space, carriage return, and form feed }