Comments on: 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

Comments:

Brian Hawley 9-Oct-2009 17:39:05	A few comments: BREAK/return: Can be handled by the RETURN paren operation instead. DO: Cool, Gabriele will be happy to get this. This feature lets you mix REBOL code into an overall structuring dialect without nested structures (like parens). It's doable with the new DO/next inside an IF operation if need be though. LIMIT: Sorry to hear that this operation is so complex, but the workaround sounds workable. USE: No problem, the new function context model means that we can call PARSE inside a function, and recursively call that function inside an IF operation. No bind/copy overhead required unless the function is a closure. All that's needed is to nest the rules in the function block. FUNCT can even collect the locals if need be. OF: You may think that only you want this, but remember what you wanted it for: the GUI dialect. This was one of the two proposals that started this process, and a good one. I don't like the name OF (ALL is better), but I like the semantics. REVERSE: I will miss this one, particularly if it is the REVERSE rule variant. This would speed up functions like CLEAN-PATH that need to reverse their input to parse it. /ignore: I only suggested it as an alternative to the old default behavior. As with that old default, we are likely better off without it. That RETURN paren variant was a good idea, Carl. Between that, the QUOTE paren variant, and IF, there are a lot of tricks that we can do that were really difficult before. And the subject data switch get-word trick is going to be really interesting :)
Maxim Olivier-Adlhoch 9-Oct-2009 22:05:39	BH: on the use of 'USE workaround, you'll have to make nice example in the docs, cause I'm reading what you're saying, and its not obvious at all. 'USE in the rules would have been so clean and tidy for rules requiring a stack of some kind. I would like something like a standard push/pop mechanism within the parse... can we add that as a deferred item?
reisacher 11-Oct-2009 5:38:04	As nice as parse will be, I think, it's more important, to go on with Rebol Core and finish some parts instead of defining a new language, the parser language. Especially as many of the new features just make it easier to define the rules, but do not really bring rebol nearer to be a production ready release
xuanin 11-Oct-2009 6:18:47	What I miss in your summary is the special treatment of parens for CHANGE and INSERT value argument, the same way that the quote command does. This is a nice feature suggested in the original parse proposal by BrianH: CHANGE rule (expression) INSERT (expression) As pointed out by Steeve and others the ability to use a REBOL expression in parens is a very useful addition. Has this feature been dismissed or is pending?
Giuseppe Chillemi 11-Oct-2009 7:52:56	I vote for REVERSE being implemented in 3.0. Despite many of us will miss it a lot. It is ok for all the other timings and decisions.

Post a Comment:

You can post a comment here. Keep it on-topic.