Parse ccc delimited by the delimiter char.
c-addr is the address (within the input buffer) and u is the length of the parsed string. If the parse area was empty, the resulting string has a zero length.
- WORD always skips leading delimiters. This
behavior is appropriate for use by the text interpreter,
which looks for sequences of non-blank characters, but is
inappropriate for use by words like ( , .(,
and .". Consider the following (flawed) definition
This works fine when used in a line like:
but consider what happens if the user enters an empty string:
The definition of .( shown above would treat the
)as a leading delimiter, skip it, and continue consuming characters until it located another
)that followed a non-
)character, or until the parse area was empty. In the example shown, the
5. would be treated as part of the string to be printed.
With PARSE, we could write a correct definition of .(:
This definition avoids the "empty string" anomaly.
- WORD returns its result as a counted string.
This has four bad effects:
- The characters accepted by WORD must be
copied from the input buffer into a transient buffer,
in order to make room for the count character that
must be at the beginning of the counted string. The
copy step is inefficient, compared to PARSE,
which leaves the string in the input buffer and doesn't
need to copy it anywhere.
- WORD must be careful not to store too many
characters into the transient buffer, thus overwriting
something beyond the end of the buffer. This adds to
the overhead of the copy step. (WORD may have
to scan a lot of characters before finding the trailing
- The count character limits the length of the string
returned by WORD to 255 characters (longer
strings can easily be stored in blocks!). This
limitation does not exist for PARSE.
- The transient buffer is typically overwritten by the next use of WORD.
- The characters accepted by WORD must be copied from the input buffer into a transient buffer, in order to make room for the count character that must be at the beginning of the counted string. The copy step is inefficient, compared to PARSE, which leaves the string in the input buffer and doesn't need to copy it anywhere.
JamesNorris What happens when parse reaches the end of the parse area and the parse delimiter was not found?Request for clarification2020-08-01 13:42:29
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.)