World: r3wp
[Parse] Discussion of PARSE dialect
older newer | first last |
Steeve 28-Sep-2009 [4051] | but if you can perform a do/next then parameters are allowed |
BrianH 28-Sep-2009 [4052x2] | Yeah. If you pass a function as the replacement value, that function will be called with the series at the replacement position as a parameter, and its return value is used. ARRAY does something similar too. My changes. |
Say that the series position parameter is passed with APPLY rules. If the function takes a parameter it sees it; if not it doesn't. | |
Steeve 28-Sep-2009 [4054] | Or we can provide 2 index by default, maintained by the parse engine. & = the head of last rule matched &&= the tail of the last matched rule. |
BrianH 28-Sep-2009 [4055x3] | Not a bad idea, but... this is how it starts. This is what led to the rule! type suggestion :( |
See, your method would allow REPLACE/part to be called directly. | |
Sorry, REMOVE/part. | |
Steeve 28-Sep-2009 [4058x2] | or even INSERT, REMOVE, CHANGE, without the need to develop a specific inlinned method for those functions |
wer just need 2 pointers auto-handled by parse | |
BrianH 28-Sep-2009 [4060x3] | Except your replacement code for those functions was wrong. And would be wrong in this case. Those inline operations were added to reduce common errors, not to provide missing functionality. |
I am also concerned about the security implications of having PARSE call functions outside of parens. In parens you know what you're getting. This is why QUOTE and IF require parens for the REBOL code they execute. | |
All of the added operations could have been done before with code in parens and/or explicit position setting. It's easier this way. | |
RobertS 28-Sep-2009 [4063] | I put a note up because of my silly misunderstanding of the intent of adding AND to PARSE. But I get odd results with the likes of parse "abeabd" [and [thru "e"] [thru "d'"]] which behaves like ANY |
BrianH 28-Sep-2009 [4064x2] | Not a silly misunderstanding, a bug, bug#1238 in particular. |
One of 4 parse bugs in a83. | |
RobertS 28-Sep-2009 [4066] | OF course in STSC APL "laod" was as good as "load" and in Smalltalk I still long for "slef" and "sefl" but I draw the line at "elfs" which is clearly unfit in the age of "octopuses" |
BrianH 28-Sep-2009 [4067] | And that doesn't even count the stuff not implemented yet. |
RobertS 28-Sep-2009 [4068] | I thought ONE (but no move) on the model of SOME and ANY when I was misunderstanding AND as "all" as [ ONE [rule1 rule2 rule3 ] ] |
BrianH 28-Sep-2009 [4069] | ONE would be an interesting name for the OF proposal. |
RobertS 28-Sep-2009 [4070] | Shorter than UNIQUE |
BrianH 28-Sep-2009 [4071x3] | Sorry, that would be a different operation. |
Shorter than FROM or GATHER though. | |
Wait, ONE wouldn't work, since you actually get all of the rules, just not in order. | |
Steeve 29-Sep-2009 [4074] | I posted examples to show why a84 is more rebolish. http://www.rebol.net/cgi-bin/r3blog.r?view=0255#comments |
Pekr 29-Sep-2009 [4075x2] | looks good ... |
Steeve - will better parse help with editor? IIRC it was you and Shadwolf, who did it? | |
Steeve 29-Sep-2009 [4077] | A little, but the main drawback i have with parsing in editor is that parse doesn't handle incremental parsing. Because i do parsing line by line to be able to parse only modified lines. So that, i have to rewrite all the rules (describing the document) in an obfuscated way to deal with incremental parsing. |
Pekr 29-Sep-2009 [4078] | BrianH has some plans towards "streamed" parsing. Hopefully it can be done over ports in the future ... |
Steeve 29-Sep-2009 [4079] | Actually, we can simulate streamed/incremental parsing. But we need to transform all the input rules (it can be automatized). I would prefer an inlined behavior of parse for such purpose. It's why i asked to Carl if we could return the rule stack during parsing (i.e. with a special command). |
Pekr 29-Sep-2009 [4080] | What was the answer? I missed your request during yesterday's chat probably ... |
Steeve 29-Sep-2009 [4081] | Request delayed for R3.1 |
Pekr 29-Sep-2009 [4082] | 3.1 - that will be in Spring, so I think that we can wait ... |
Steeve 29-Sep-2009 [4083x3] | it seems |
parse is in mode parse/all by default now, but we can remove the option, a bug ? | |
*we can't | |
BrianH 29-Sep-2009 [4086x2] | /all still affects simple parse (splitting instead of rules). |
With the PARSE changes, this puts us within the range of a parsing model with a reasonably solid theoretical foundation and a lot of experience with parser generators. We could compile PARSE rules into equivalent incremental rules. | |
Steeve 29-Sep-2009 [4088x2] | yep we could start by building a compiler of rules into incremental ones (with rebol i mean) |
i made some tests in the past | |
Steeve 30-Sep-2009 [4090x2] | About STAY, i don't see the interest to continue even if the following rule is not matched . Can someone give an use case ? because when i do this: >> parse [1] [stay skip ?? to end] to: [1] == true or >> parse [ ] [stay skip ?? to end] to: [ ] == true it's like doing: >> parse [ ...] [?? to end] STAY have no purpose to my mind... |
It's just a little annoying, see: >> parse a: "12" [remove copy val skip] print [a val] ==2 none So, the [remove] treats well the [skip], but discard the content of [copy val] Now, see: >> parse a: "12" [remove [copy val skip]] print [a val] == 2 1 The content of [val] is preserved in that case, don't know why here, but not above... | |
Pekr 30-Sep-2009 [4092x2] | I would expect 'val being 1 in both cases ..... |
But maybe reading the "expression" the REBOL way - from left to right, is not correct? | |
Steeve 30-Sep-2009 [4094] | i rather think it's a bug |
Anton 30-Sep-2009 [4095] | Is it that REMOVE takes one argument? |
Pekr 30-Sep-2009 [4096] | Yes, it takes on argument - the rule ... |
Anton 30-Sep-2009 [4097] | (I'm just reading that new blog article about it... Sorry for adding new ignorant question before doing anything to alleviate my ignorance.) |
Pekr 30-Sep-2009 [4098] | sometimes getting reply here on altme is faster than reading corresponding article :-) |
Steeve 30-Sep-2009 [4099] | That's not the problem, SET VAR ot COPY VAR are not rules, they should not be "viewed" by REMOVE |
RobertS 30-Sep-2009 [4100] | I am still guessing at what is intended in R3-a84 but the first looks OK and the second looks like a bug >> parse "abad" [thru "a" stay [to "b"] (print "at b") thru "d"] at b == true >> parse "abad" [stay thru "c" (print "at c") [to "b"] thru "d"] at c == true ; BUT must still be a bug |
older newer | first last |