REBOL 3.0

Comments on: PARSE: allow paths?

Carl Sassenrath, CTO
REBOL Technologies
21-Sep-2009 3:33 GMT

Article #0246
Main page || Index || Prior Article [0245] || Next Article [0247] || 8 Comments || Send feedback

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.

Name:

Blog id:

R3-0246


Comment:


 Note: HTML tags allowed for: b i u li ol ul font span div a p br pre tt blockquote
 
 

This is a technical blog related to the above topic. We reserve the right to remove comments that are off-topic, irrelevant links, advertisements, spams, personal attacks, politics, religion, etc.

REBOL 3.0
Updated 29-Mar-2017 - Edit - Copyright REBOL Technologies - REBOL.net