World: r3wp
[Parse] Discussion of PARSE dialect
older newer | first last |
Steeve 8-Nov-2008 [3039] | yes but who do such things ? |
BrianH 8-Nov-2008 [3040] | The reason you would enable this option is to catch sub-rule logic errors. |
Steeve 8-Nov-2008 [3041x2] | i always take care to advance in the serie |
ah ok, it's to help for debugging purposes ? | |
BrianH 8-Nov-2008 [3043] | Yeah, or malicious rules from third parties because you can't easily statically determine whether the bug would happen. Most malicious rules can be screened for, but others can't. It's a bad idea to run third-party rules anyway, but some people can't avoid it. |
Steeve 8-Nov-2008 [3044] | but i see the interest to set no backwards capabilities in some case, we coold have a special command (like FREEZE) to throw an error when we have a backward effect |
BrianH 8-Nov-2008 [3045] | Backwards isn't a problem (especially with REVERSE) - stasis is. |
Steeve 8-Nov-2008 [3046] | i have to reread the effect of REVERSE |
BrianH 8-Nov-2008 [3047x4] | At the very least the infrastructure should be added to detect this kind of error so that PARSE tracing can warn about it. |
REVERSE changes the direction of PARSE. This helps with recognizing language patterns that LR is better at than LL is. | |
I have some ideas about how REVERSE and should work with backtracking that I haven't written down yet. | |
and -> | |
Steeve 8-Nov-2008 [3051] | i just have a doubt, in my scripts i like using parse to change a serie. Some of this rules are recursives so that they can apply several modifications on modifications. In such a case i would break your rule to not return in the same point. |
BrianH 8-Nov-2008 [3052x2] | That is why it would be optional. |
By recursives you meant iteratives. Recursives don't use loops. | |
Steeve 8-Nov-2008 [3054x2] | I have a set of rules in an any block wich apply modifications, the same block of rules is applied until there is no more modifications. I don't know h |
how to call that | |
BrianH 8-Nov-2008 [3056] | That is iterative changes. Each round of changes is an iteration. |
Steeve 8-Nov-2008 [3057] | ok |
BrianH 8-Nov-2008 [3058] | That kind of thing can be very powerful. As long as you have a fixpoint (a reachable condition to break you of the loop) you'll be fine. |
Steeve 8-Nov-2008 [3059] | yeah i know it's difficult to create, but when it works it's incredibly compact and powerfull, i like compactness |
BrianH 8-Nov-2008 [3060] | Rewrite rules usually work this way. |
Steeve 8-Nov-2008 [3061] | about your proposal i just will say that is not an high request but if it's free i take it |
BrianH 8-Nov-2008 [3062] | I think it will be better to include this in the tracing infrastructure. |
Steeve 8-Nov-2008 [3063x3] | ok another proposal |
currently when we parsing a serie we can't mix constant string! and constant binaries together | |
we have to choose depending of the type of the serie | |
BrianH 8-Nov-2008 [3066x3] | That will be moreso in R3 because string! and binary! aren't compatible any more. |
Unicode changes. A binary is a series of bytes, a string is a series of codepoints. | |
AS-STRING and AS_BINARY are gone. | |
Steeve 8-Nov-2008 [3069] | but at certain point a string can be converted to a binary an vice versa |
BrianH 8-Nov-2008 [3070x2] | Yes, but that is a real conversion, with encoding and decoding. |
Just like converting from a .jpg to an image! and back. | |
Steeve 8-Nov-2008 [3072] | when u say 'real' u mean a large time consuming conversion ? |
BrianH 8-Nov-2008 [3073x2] | Hopefully not time-consuming but definitely large, depending on the size of the string. |
The Unicode changes were pretty significant and deep. | |
Steeve 8-Nov-2008 [3075x3] | not the subject, but speaking of consuming operations, what about the old idea to have subset of serie (range) without the need to copy/part series ? |
Carl spoken of that in the past | |
*abouty | |
BrianH 8-Nov-2008 [3078] | It was rejected as a base type because it was deemed unnecessary, but could be added as a UDT. |
Steeve 8-Nov-2008 [3079x3] | UDT ? |
about proposals, currently we have only one atom operation to control advance in the serie: [skip]. We could had some other atom operations, like DROP,SWAP,ROT,DUP. (any reference to FORTH language are intentional) | |
don't ask me an usage, it's only because i'm currently working on a FORTH engine | |
BrianH 8-Nov-2008 [3082x3] | UDT = user-defined datatype!, a planned feature of R3. Yes, this includes user-defined function types in theory. |
DROP, SWAP, ROT and DUP are stack modification operations, not parse advancement operations like SKIP. Don't forget REVERSE and matching operations - they advance too. | |
My bad: REVERSE doesn't advance. | |
Steeve 8-Nov-2008 [3085x4] | i know what they are (trust me) it was a sort of transposition to parse |
image just that parsing a serie is like working with a stack, the analogy is not as bad as you think | |
*imagine | |
in an other way, SWAP, ROT, DUP or DROP are not just advance operations , they modify the serie too. | |
older newer | first last |