World: r3wp
[Parse] Discussion of PARSE dialect
older newer | first last |
BrianH 24-Dec-2008 [3322] | The phrase [end skip] will always fail and return false. |
[unknown: 5] 24-Dec-2008 [3323x2] | What I'm talking about is this: words: [this that blah] result: parse [this that bleh blah][some [set w word! (unless find words w [do something to return false here)]] |
result should evaluate to false in my example | |
BrianH 24-Dec-2008 [3325] | For now, you want a continuation variable. Like this: result: parse [this that bleh blah][some [set w word! (cont: unless find words w [[end skip]]) cont]] |
Steeve 24-Dec-2008 [3326x2] | continue: none ;means continue is ok stop: [end skip] result: parse [this that bleh blah][some [set w word! (unless find words w [continue: stop]) continue]] |
ahah, same idea | |
[unknown: 5] 24-Dec-2008 [3328x2] | Brian, I thought I tried that. |
checking that one hold on. | |
Maxim 24-Dec-2008 [3330x2] | I was working on another idea where only THAT rule failed ! |
for a general failure, the above works for sure. | |
[unknown: 5] 24-Dec-2008 [3332] | yeah that will work Brian. i think I was setting the word that I had placed at the end and that is why it failed before. |
BrianH 24-Dec-2008 [3333] | That is the equivalent of the CHECK proposal. |
[unknown: 5] 24-Dec-2008 [3334] | What is the Check proposal? |
Maxim 24-Dec-2008 [3335] | look in: http://www.rebol.net/wiki/Parse_Project |
BrianH 24-Dec-2008 [3336] | Read the parse proposals linked above. |
Maxim 24-Dec-2008 [3337] | its also a good read to know many of the "tricks" in parse :-) |
[unknown: 5] 24-Dec-2008 [3338] | By the way what I currently have been doing is setting a value to another word to differentiate why the parse failed - whether it was syntax or because of an invalid word. |
Maxim 24-Dec-2008 [3339] | (of R2) |
BrianH 24-Dec-2008 [3340] | I was the editor of the proposals and manager of the proposal process. |
Maxim 24-Dec-2008 [3341] | I remember posting on the blogs a long time ago... its nice to see it was all compiled.... thanks brian ! |
[unknown: 5] 24-Dec-2008 [3342] | Yeah currently I would just set another value called 'flag in the parens and then check it after the parse was complete. If it was true then I know a word wasn't found. |
BrianH 24-Dec-2008 [3343] | In theory, the best proposals (I have a list in my head) will be able to be compiled to R2 parse rules. Tested theory :) |
Maxim 24-Dec-2008 [3344x2] | the whole of the enhancements will make PARSE SOOOOOOO much more conscice and fun to use for advanced stuff. :-) |
I now have a real reason to want R3. | |
[unknown: 5] 24-Dec-2008 [3346] | I don't know if 'Check functionality really needs to be BUILT as much as just communicated. |
BrianH 24-Dec-2008 [3347] | Did you see my advanced example at the bottom? :) |
[unknown: 5] 24-Dec-2008 [3348] | It shows the power of parse. |
Maxim 24-Dec-2008 [3349] | not yet... reading it as I chat, cook and do some income tax stuff... I' m a bit like reichart... I've got an exec kernel in my brain ;-) |
[unknown: 5] 24-Dec-2008 [3350] | In fact that method I was showing is how TRETBASE will be parsing search criteria to ensure only acceptable words are used in the block that will be reduced. |
BrianH 24-Dec-2008 [3351] | A lot of the workarounds require variables, which can be difficult to use concurrently. The proposals are all attempts to get around that. |
[unknown: 5] 24-Dec-2008 [3352] | That idea is to put all the operators (since they are words in the words containers along with field names which get later set to values and other set-words as desired). |
Maxim 24-Dec-2008 [3353] | the main thing is about the recursiveness. |
[unknown: 5] 24-Dec-2008 [3354] | I do that will calling my rule inside the rule. |
Maxim 24-Dec-2008 [3355] | remark has a stack which it must manage manually... proposals might make some of that management useless. |
BrianH 24-Dec-2008 [3356] | The CHECK workaround is the easiest way to do reserved words that can change at runtime. |
[unknown: 5] 24-Dec-2008 [3357x2] | Here is what I currently had: rule: [some [set w word! (unless find valid-A w [flag: true]) | into [rule] | any-type!]] ; rule for parsing the Ablock |
Actually the last part of that rule was for testing something currently. | |
Maxim 24-Dec-2008 [3359] | I might have a new proposal brian. but I am reading the whol... to make sure its not somewhere in the current ideas. |
BrianH 24-Dec-2008 [3360x3] | You would be surprised. The modifying proiposals are not going to be expanded though. |
Still, if we missed something suggest it here first :) | |
I had enough trouble with someone who was making hostile changes without discussing them first :( Not that your changes would be hostile, but discussing them is still good. | |
Maxim 24-Dec-2008 [3363] | I love the idea of 'REVERSE :-) |
BrianH 24-Dec-2008 [3364x2] | Particularly the REVERSE rule variant. There are some sweet ones in there :) |
Whoops, Peta added some more false comments. Must fix... | |
Maxim 24-Dec-2008 [3366] | the new stuff allows what I want to do, but still makes it non-trivial... a bit like the first example. a lot is done in so few lines... but its not obvious to analyse... my idea was for a system called 'PERSIST |
BrianH 24-Dec-2008 [3367] | Please go on - we already rejected something with a name like that, perhaps yours is different. |
Maxim 24-Dec-2008 [3368x2] | as in : PERSIST rule1 rule2 its a mixture of [any change at only ] as your first example |
the idea being, as long as rule1 matches, return the AT of that rule, executing the second one there. | |
BrianH 24-Dec-2008 [3370x2] | ? |
It sounds like AT. | |
older newer | first last |