PARSE: status of changes

It's time to wrap up parse changes and move on to the next priority related to finishing R3.

Here is a summary and status of the remaining requested features:

Keyword	Status	Notes
BREAK	pending	The definition is still being debated, but the use cases are not yet obvious. See the earlier blog on the topic. (Note that this is BREAK as a rule keyword, you can still use BREAK within a paren productions.)
BREAK/return	pending	This is not a keyword, but rather a definition of BREAK within productions. Do they apply to the parse function, or to a loop function prior to that? This must be defined one way or the other.
DO	pending	This feature evaluates a single REBOL expression for obtaining the next rule. It's an interesting feature, but I need to hear someone say that they really need it, otherwise it will be deferred until later.
LIMIT	deferred	To limit the range of TO/THRU. This is non-trivial because it requires deeper changes for code-shared search algorithms. The work around requires that buffer (chunkify) your input parsing. This is now much easier to do now that get-words are allowed to change the input series.
USE (1)	dismissed	While it may be handy to embed USE within parse rules, it does not seem practical. The overhead would be very high due to the deep BIND/COPY required on the rules as they are processed. If the USE commands were pre-processed somehow, the problem becomes what to do about variable references that may refer to rules outside the lexical scoping of the block (hence, they are not bound to the USE context.) The current method of binding parse rules within an object, module, or function seems a more clear and is a common pattern in REBOL.
OF	deferred	I requested this feature as a way of parsing un-ordered dialects (such as those defined by DELECT.) I think I'm the only one who wants this, so it can be deferred.
REVERSE	deferred	Another feature I requested, but it requires a lot more definition, and depending on how it is defined, might require substantial effort to implement.
/ignore	dismissed	This feature would let you specify characters or datatypes that are ignored by the parse. They would be hidden from the rules. More use cases are needed to determine if this is worth the effort, because it has a major affect on the internals of parsing (the input must constantly be checked for matches on the ignored values). Also, it may generally be better that such values be specified in the rules where they can be seen.

A status of "deferred" means that it will not be implemented in 3.0.0.

This table will be updated as needed.

Post comments below.

5 Comments