World: r3wp
[Parse] Discussion of PARSE dialect
older newer | first last |
BrianH 13-Oct-2009 [4490] | The BREAK/return proposal was proposed before Carl added the RETURN paren option, which makes BREAK/return unnecessary. |
Pekr 13-Oct-2009 [4491] | OK, so we are almost done with parse, right? (As I don't expect Carl changing his mind about the deferred proposals, at least not for 3.0) |
BrianH 13-Oct-2009 [4492] | The only still-missing proposals that aren't easy or efficient to work around are OF and REVERSE. They will be missed if not included. Unfortunately, the same reasons why they will be hard to work arond if missing, are the reasons why they would be difficult to implement :( |
Pekr 13-Oct-2009 [4493] | btw - what is the outcome of so called - complementing? Will we get it enhanced, so that we can use it even with Unicode? I noticed Carl said that complements could be enhanced .... |
BrianH 13-Oct-2009 [4494x2] | I expect that PARSE release features will be done in a89 - the rest will be bug fixes. |
One of the bitset! bugs was fixed in a88, but complementing is yet to come. It will probably be the using a bit for a flag method. | |
Pekr 13-Oct-2009 [4496] | Shouldn't be such enhancement part of the proposal doc? (just in order to have it documented :-) |
BrianH 13-Oct-2009 [4497] | Yes, it should. Care to add it? |
Pekr 13-Oct-2009 [4498] | I can add it, just not sure I would describe it precisely :-) |
Pekr 14-Oct-2009 [4499] | Carl asks about the usability of Until proposal - if not answered/defined, it will not be part of 3.0 - http://www.rebol.net/r3blogs/0271.html |
BrianH 14-Oct-2009 [4500] | Did an initial answer, but Ladislav really needs to expand on it. |
Pekr 14-Oct-2009 [4501x3] | hmmm ....http://www.rebol.net/r3blogs/0272.html |
Interesting how Carl asks for naming convention opinion, there was no single vote for 'loop, yet such word was chosen ;-) http://www.rebol.net/r3blogs/0273.html | |
We have one hour to decide, if we want 'loop being renamed to 'while .... | |
Graham 14-Oct-2009 [4504] | Tim Berners-Lee is quoted today to say that he can't think of a good reason to keep the // in http://, and that if he did it again, he would have done without them. I wonder if he spoke to people who write parsers .... |
Gabriele 15-Oct-2009 [4505x2] | the reason for the // is to allow relative paths like: //www.rebol.com/ where the scheme is the same as the base url. Nobody has ever used this; also, it could have been achieved by using :www.rebol.com/ instead... so, yeah, it was not really a good idea. I also don't think ftp:file.txt (meaning, change scheme, but keep host and path) has ever been used and not sure it's supported by software. so in practice http:www.rebol.com/ would have worked. |
it has to be said, that the www subdomain is also a silly habit. | |
Pekr 15-Oct-2009 [4507] | As for parse docs - why is 'then not being among the keywords? Isn't it a keyword? |
BrianH 15-Oct-2009 [4508] | It's an operator, like |, and mentioned in that section near the top. |
Pekr 15-Oct-2009 [4509] | isn't AND operator too for e.g.? |
Chris 17-Oct-2009 [4510] | First pass at converting my AltXML to R3: http://www.ross-gill.com/r/r3xml.r -- almost a literal translation, doesn't yet utilise new parse features... |
Pekr 17-Oct-2009 [4511x2] | The DO keyword was added to A91 - Gabriele should be happy now :-) http://www.rebol.net/r3blogs/0276.html |
http://www.rebol.net/r3blogs/0277.html- Trouble renaming BREAK to ACCEPT in following case: some [break | "b"] .... where it returns FALSE. Carl seems to suggest, that unless that case is solved, it can't be renamed ... | |
Maxim 17-Oct-2009 [4513] | gave my two cents on the blog... hehehe |
Pekr 17-Oct-2009 [4514] | Max - we are close to finish parse. It is clear Carl will move to other priorities. Sorry to hunt you here or there, but any chance you get your Extensions short doc done? No doc = no callback probably :-) |
Maxim 17-Oct-2009 [4515] | I really want to do it... but I'm so deep into parsing right now I don't want to loose the few GB of information in my brain's cache. I'm writing self-modifying parse rules and its pretty nightmarish. although it works. |
Gabriele 17-Oct-2009 [4516] | Ah, 6 years of wait finally over. Now, if we could get those changes ported to R2... |
Maxim 17-Oct-2009 [4517] | hehehe you finally got your DO ;-) |
Henrik 17-Oct-2009 [4518] | Do we have a list of PARSE changes that are no longer compatible with R2? I think that would be important in porting parse scripts from R2 to R3. |
Pekr 17-Oct-2009 [4519x3] | Gabriele - wrong perception :-) The correct claim should be - "An now nothing prevents me from fully switching to R3 ..." :-) |
An=And | |
So - we don't need complementing to be enhanced? Because we talked about it, but it is not defined in proposal, it is not part of Carl's feature table, and I also got no reaction on R3 Chat .... | |
BrianH 17-Oct-2009 [4522x2] | Gabriele, these changes can be backported to R2 in the form of a rule compiler that generates (unreadable) R2 parse rules. |
Pekr, we still need complementing to be enhanced. Even Carl has said so. | |
Maxim 17-Oct-2009 [4524x3] | but wouldn't work with remark ;-) |
one situation which complemet can't handle very well (ram wise): union charset "a" complement charset "b" | |
you end up with a full codepoint bitset minus one byte if it complemented or not | |
BrianH 17-Oct-2009 [4527x2] | Maxim, Remark could be adjusted to use the rule compiler. For that matter, Remark could use R2/Forward (which needs some work, but is already better than R2 on its own). |
Maxim, that is what Pekr was talking about. That is planned to be fixed. | |
Maxim 17-Oct-2009 [4529x4] | a rule compiler doesn't adapt very well to self-modifying rules |
laden with many paren expressions and a stack on top of it. | |
the rule I am writing now actually does JIT rule compilation... hairy to debug :-) | |
since I use binding to map inner rules which are also constructed on the fly but have to be pushed and poped from the stack as I traverse data... its a lot of fun :-D | |
BrianH 17-Oct-2009 [4533x2] | If the self-modifying rules are strung-together basic blocks, you can use the rule compiler to generate the blocks. And the R3 changes make self-modifying rules less necessary, so you can have even larger basic blocks. |
Of course the *result* of the compilation would be self-modifying rules :) | |
Maxim 17-Oct-2009 [4535x2] | really, the problem is not the parsing itself... its getting the darn rules to generate the proper rules hehehe. |
and its not simple parsing since I use parsing index manipulation, which is also dictated by the source data in encounters. its like swatting flies using a fly swatter at the end of a rope, while riding a roller coster which changes layout every time you ride it ;-) | |
BrianH 17-Oct-2009 [4537] | Which is what a rule compiler does :) Actually, it sounds like you could adapt the tricks of the ruule compiler to *your* rule compiler, which would let you use the new operations in your rule source and have the workarounds generated in the output. |
Maxim 17-Oct-2009 [4538x2] | well, build it and I will try it ;-) |
I promise. | |
older newer | first last |