Re: Pry v0.3.1 is out!
On Sunday, 15 January 2017 at 01:26:07 UTC, Dmitry Olshansky wrote: Two key areas of focus are (compared to say Pegged): - performance, on par with hand-written code or die I didn't profile, but apart from the time-complexity that is inherent to straight forward recursive descent parsers like Pegged (improved by memoization), my impression is that Pegged's main performance problem is due to a very high constant: it is concatenating strings, all the time. A LOT of strings, and a LOT of concatenations. Almost all of them are discarded, of course. Finding a way to do the same without string concatenation would have a big impact. Bastiaan.
Re: Pry v0.3.1 is out!
On Tuesday, 17 January 2017 at 21:10:17 UTC, Dmitry Olshansky wrote: On 1/17/17 1:16 PM, Bastiaan Veelo wrote: On Monday, 16 January 2017 at 22:29:01 UTC, Dmitry Olshansky wrote: I think left-recursion is better handled at the grammar level. What I currently have is parser combinators level where adding this transformation is awkward and too much magic IMO. Handling left-recursion by grammar transformation often has unwanted side-effects (operator precedence) and eliminating indirect left-recursion this way can be impossible in practice. Depending on the complexity of the grammar, even identifying the recursive loop can be a challenge. I do not suggest to change the grammar itself, I think that processing of the grammar may perform hidden transformations internally. Interesting. Would that work with indirect left-recursion? That would be daunting, I fear. It'l still mess with order of operation / associativity, won't it? Hardening Pegged to deal with the various kinds of left-recursion was very challenging, but easier than transforming the grammar I was dealing with (ISO 10206). Interesting, what kind of hardening? The trick is to recurse, but knowing when to stop. At a certain point, recursing once more will reduce the length of the matched string. So if you can break recursion when the match stops growing, you are good. This is implemented by memoizing previous recursions. There is an explanation along with literature references in my first PR on left-recursion [1]. However, the PR itself was flawed [2] and received several makeovers [3-5]. In the end, the solution was considerably more complex than the initial PR, involving introspection of the grammar to identify left-recursive loops and the appropriate rules to memoize. We now have complete support for direct, indirect and hidden left-recursion, including multiple intersecting loops and mixed left- and right-recursion. And it does not interfere with general memoization, which is important to speed up PEG parsers [6]. There are some illustrative unit tests in [7] and further. Bastiaan. [1] https://github.com/PhilippeSigaud/Pegged/pull/164 [2] https://github.com/PhilippeSigaud/Pegged/pull/165#issuecomment-158914006 [3] https://github.com/PhilippeSigaud/Pegged/pull/168 [4] https://github.com/PhilippeSigaud/Pegged/pull/186 [5] https://github.com/PhilippeSigaud/Pegged/pull/196 [6] Pegged does not memoize at CT though, at the moment. [7] https://github.com/PhilippeSigaud/Pegged/blob/master/pegged/grammar.d#L2965
Re: Pry v0.3.1 is out!
On 1/17/17 1:16 PM, Bastiaan Veelo wrote: On Monday, 16 January 2017 at 22:29:01 UTC, Dmitry Olshansky wrote: I think left-recursion is better handled at the grammar level. What I currently have is parser combinators level where adding this transformation is awkward and too much magic IMO. Handling left-recursion by grammar transformation often has unwanted side-effects (operator precedence) and eliminating indirect left-recursion this way can be impossible in practice. Depending on the complexity of the grammar, even identifying the recursive loop can be a challenge. I do not suggest to change the grammar itself, I think that processing of the grammar may perform hidden transformations internally. The trouble is that one can be happily implementing a parser or designing a grammar when suddenly for some input the parser hangs indefinitely. Users are likely quick to blame the parser lib, while in fact it is the grammar that has left-recursion. Hitting that roadblock is a real bummer. In some cases the grammar is a given (by a standard for example) and transforming it to combat left-recursion can obfuscate it beyond recognition. Hardening Pegged to deal with the various kinds of left-recursion was very challenging, but easier than transforming the grammar I was dealing with (ISO 10206). Interesting, what kind of hardening? --- Dmitry Olshansky
Re: Getters/setters generator
On 1/17/17 12:08 PM, Mark wrote: On Tuesday, 17 January 2017 at 09:17:56 UTC, Andrei Alexandrescu wrote: On 1/17/17 9:32 AM, Eugene Wissner wrote: Ah, well thanks. I don't think it makes much sense since it would be easier to write a complete setter if the user needs extra checks. Accessors are there only for the generation of the standard methods, that just get or set some object property. Hmmm... that's a bit of a bummer because it helps only the degenerate case (accessors are there as placeholders for future extensions, and otherwise offer no protection whatsoever compared to a public value). The question would be then what would be use cases for the accessors. Predicated setters are not just a random thing one might want out of many possibilities, it's a frequent pattern. -- Andrei Given that D supports class invariants, is there a real need for predicated setters? The invariant is evaluated after the setter has taken place, i.e. after the object has been corrupted. The setter guard prevents corruption from happening. -- Andrei
Re: Pry v0.3.1 is out!
On Monday, 16 January 2017 at 22:29:01 UTC, Dmitry Olshansky wrote: I think left-recursion is better handled at the grammar level. What I currently have is parser combinators level where adding this transformation is awkward and too much magic IMO. Handling left-recursion by grammar transformation often has unwanted side-effects (operator precedence) and eliminating indirect left-recursion this way can be impossible in practice. Depending on the complexity of the grammar, even identifying the recursive loop can be a challenge. The trouble is that one can be happily implementing a parser or designing a grammar when suddenly for some input the parser hangs indefinitely. Users are likely quick to blame the parser lib, while in fact it is the grammar that has left-recursion. Hitting that roadblock is a real bummer. In some cases the grammar is a given (by a standard for example) and transforming it to combat left-recursion can obfuscate it beyond recognition. Hardening Pegged to deal with the various kinds of left-recursion was very challenging, but easier than transforming the grammar I was dealing with (ISO 10206).
Re: Getters/setters generator
On Tuesday, 17 January 2017 at 09:17:56 UTC, Andrei Alexandrescu wrote: On 1/17/17 9:32 AM, Eugene Wissner wrote: Ah, well thanks. I don't think it makes much sense since it would be easier to write a complete setter if the user needs extra checks. Accessors are there only for the generation of the standard methods, that just get or set some object property. Hmmm... that's a bit of a bummer because it helps only the degenerate case (accessors are there as placeholders for future extensions, and otherwise offer no protection whatsoever compared to a public value). The question would be then what would be use cases for the accessors. Predicated setters are not just a random thing one might want out of many possibilities, it's a frequent pattern. -- Andrei Given that D supports class invariants, is there a real need for predicated setters?
Re: Getters/setters generator
On 1/17/17 9:32 AM, Eugene Wissner wrote: Ah, well thanks. I don't think it makes much sense since it would be easier to write a complete setter if the user needs extra checks. Accessors are there only for the generation of the standard methods, that just get or set some object property. Hmmm... that's a bit of a bummer because it helps only the degenerate case (accessors are there as placeholders for future extensions, and otherwise offer no protection whatsoever compared to a public value). The question would be then what would be use cases for the accessors. Predicated setters are not just a random thing one might want out of many possibilities, it's a frequent pattern. -- Andrei
Re: Getters/setters generator
On 1/17/17 8:26 AM, Eugene Wissner wrote: On Friday, 9 December 2016 at 18:53:55 UTC, Andrei Alexandrescu wrote: Love it, and was toying with similar ideas too. One good extension is to add a predicate to the setter, which guards the assignment. -- Andrei What kind of predicate do you mean? Can you give an example please? Say you have a property "percent". The setter should do an enforce(value >= 0 && value <= 100) before the assignment. -- Andrei
