Comments on: PARSE: allow paths?

Currently:

>> ob: object [str:]
>> parse "test" [ob/str: "test"]
** Script error: invalid argument: ob/str:
>> parse "test" [:ob/str "test"]
** Script error: invalid argument: :ob/str

But, shouldn't it be allowed?

Update: Added in A83

Test cases so far are:

[
    obj: object [p: "abc" n: 3 s: none b: ["abc"]]
    parse "abc" [obj/p]
]
[
    parse "abc" [obj/b]
]
[
    parse "aaabc" [obj/n "a" "bc"]
]
[
    parse "abc" [obj/s: "abc"]
    obj/s = "abc"
]
[
    parse "abc" [obj/s: "a" (obj/s: head obj/s) :obj/s "abc"]
]
[
    parse "abc" [obj/s: "a" (obj/s: tail obj/s) :obj/s end]
]

[
    obj: object [p: ['a 'b 'c] n: 3 s: none b: [obj/p]]
    parse [a b c] [obj/p]
]
[
    parse [a b c] [obj/b]
]
[
    parse [a a a b c] [obj/n 'a ['b 'c]]
]
[
    parse [a b c] [obj/s: 3 skip]
    obj/s = [a b c]
]
[
    parse [a b c] [obj/s: (obj/s: next obj/s) :obj/s ['b 'c]]
]
[
    parse [a b c] [obj/s: (obj/s: tail obj/s) :obj/s end]
]

and not to forget that this is TRUE:

parse [a/b/c] ['a/b/c]

All above tests pass, but I'm sure you can find many other cases worth verifying.

Parse Summary updated.

8 Comments

Comments:

Brian Hawley 21-Sep-2009 23:49:06	Yes, please, allow paths wherever non-keyword words are. It would help with scan-and-grab apps, collections of rules, and other such situations.
Henrik 22-Sep-2009 2:19:27	I have no objections. (OK, now you get feedback :-))
Maxim Olivier-Adlhoch 22-Sep-2009 12:45:01	YAY !!!! we can now make rule sets :-D Switch an entire set of rules based on one word !!!!
Gerard Cote 23-Sep-2009 22:06:45	For a long time, when I began learning about REBOL and Parse I tried hard to do this path notation working right - and finally left aside my first printf implementation because I didn't read well about this limitation ... Nice to see it implemented. Another problem I had when trying to implement some APL like functionality was that some characters were not available for use because REBOL already uses them. The only way I found to circumvent this was to work on a string input instead of using block input. Furthermore if I could have been able to get some user-defined datatypes recognized by REBOL it would have been helpful in some way. But this is somewhat not to the point here. Just wanted to not forget them later... But what I missed the most was that the model PARSE was linked to was the PEG as I found later and as is defined in : http://en.wikipedia.org/wiki/Parsing_expression_grammar Is this model always valid? or something near explained elsewhere ? I found it useful as a starting basis and maybe it could be used to help starters in this parsing and grammars domain !!! Regards
Brian Hawley 23-Sep-2009 22:29:13	PEG was invented later than parse, but it's a good model that fits pretty well. We are filling in the blanks with this revamp :)
Ladislav 24-Sep-2009 3:20:41	Re history: PEG is a descendant of the "family" of Top down parsing languages (probably the last one at present), and the PARSE dialect certainly fits in too. It looks, that the TDPL family existed before PARSE was invented, but PEG was defined later?
Brian Hawley 25-Sep-2009 4:23:08	TDPL was originally a description of the algorithm of a particular parser that wasn't originally based on a formal theory. GTDPL was based on another related parser. PEG was a formal theory to provide a framework for a wide range of existing incompatible ad-hoc parsers with no theory behind them, including the Packrat parsers (which were described 2 years earlier). A lot of documentation for PEG says that Packrat parsers were invented to implement the theory, rather than vice-versa. None of the PEG or Packrat parsers I know of are implemented using the same method as PARSE. All of them are parser generators, even Perl 6 rules. PARSE is interpreted, apparently with a one-pass-per-block recursive state machine, according to what Carl has revealed in blog 249 comments. This is the main reason why the syntax of PARSE isn't anything like the other PEG parsers.
Ladislav 25-Sep-2009 11:41:39	"This is the main reason why the syntax of PARSE isn't anything like the other PEG parsers." - yes, the PARSE implementation clearly prefers prefix operators, like: any "a" instead of postfix like "a"* , which is its PEG equivalent. On the other hand, (for Gerard) the differences are so small, that it is trivial to transcribe PEG to PARSE, especially when FAIL, NOT and AND keywords are directly supported.

Post a Comment:

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