Pillar parser rewrite: PetitParser or not?
Hi, The current pillar parser has several problems: - it is hard to understand and change - it discards input locations I think a refactor or rewrite is necessary. What are the pros and cons of using PetitParser to do that? Best
I completely agree. I think there are mostly pros. It can be that the parsing will be slower, but I do not think this is a critical issue for Pillar. It would be more important to have an extensible parser. Cheers, Doru On Wed, Mar 11, 2015 at 11:03 PM, Damien Cassou <damien.cassou@gmail.com> wrote:
Hi,
The current pillar parser has several problems:
- it is hard to understand and change - it discards input locations
I think a refactor or rewrite is necessary. What are the pros and cons of using PetitParser to do that?
Best
-- www.tudorgirba.com "Every thing has its own flow"
Le 11 mars 2015 à 23:07, Tudor Girba a écrit :
I completely agree.
I think there are mostly pros. It can be that the parsing will be slower, but I do not think this is a critical issue for Pillar.
not sure about the speed. I hope we will adopt pillar for class / packages comments. Then, you need a fast parsing to render it nicely and quickly on the browser. Fast/slow always depends on your comparison point. To be more precise, I would say we need to render (parsing + syntax highlighting) Pillar documents (at least one page) in less than 10 ms.
I do not think that we want to have many extensions of the syntax. We should enhance it but I do not see it changing and getting extended more. Le 11/3/15 23:07, Tudor Girba a écrit :
I completely agree.
I think there are mostly pros. It can be that the parsing will be slower, but I do not think this is a critical issue for Pillar. It would be more important to have an extensible parser.
Cheers, Doru
On Wed, Mar 11, 2015 at 11:03 PM, Damien Cassou <damien.cassou@gmail.com <mailto:damien.cassou@gmail.com>> wrote:
Hi,
The current pillar parser has several problems:
- it is hard to understand and change - it discards input locations
I think a refactor or rewrite is necessary. What are the pros and cons of using PetitParser to do that?
Best
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
Am 11.03.2015 um 23:03 schrieb Damien Cassou <damien.cassou@gmail.com>:
Hi,
The current pillar parser has several problems:
- it is hard to understand and change - it discards input locations
I think a refactor or rewrite is necessary. What are the pros and cons of using PetitParser to do that?
The cons are that petit parser is a heavier component and we should never underestimate that (just a reaction to a notion on this list). So we should avoid making things more complex, especially dependency wise. The pros is that petit parser will make it easier to extend and maintain the pillar parser. I've read something about a new version of petit parser that has a speedup of aprox. 1.000.000x. If that is the case then it is no downgrade speed wise :) Another pro is IMHO that are some people that would like to move petit parser closer (not too close) to the core. That again would make it a more standard component that makes it easy to write parsers for everyone. A good companion if you have regex and you exceed to possibilities it provides. I really have a bad feeling while saying: It would be good to have pillar based on petit parser. Norbert
It would be nice to have a parser to rule them all. I am currently using SmaCC and gets the job done. I really like its condense syntax and its syntax tool but also love the smalltalky feel of pettit parser. Maybe one must bite the bullet and write perfomance critical parts in C or even use a C parsing engine as a back end of pettit parser ? On Thu, Mar 12, 2015 at 12:39 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 11.03.2015 um 23:03 schrieb Damien Cassou <damien.cassou@gmail.com>:
Hi,
The current pillar parser has several problems:
- it is hard to understand and change - it discards input locations
I think a refactor or rewrite is necessary. What are the pros and cons of using PetitParser to do that?
The cons are that petit parser is a heavier component and we should never underestimate that (just a reaction to a notion on this list). So we should avoid making things more complex, especially dependency wise. The pros is that petit parser will make it easier to extend and maintain the pillar parser. I've read something about a new version of petit parser that has a speedup of aprox. 1.000.000x. If that is the case then it is no downgrade speed wise :) Another pro is IMHO that are some people that would like to move petit parser closer (not too close) to the core. That again would make it a more standard component that makes it easy to write parsers for everyone. A good companion if you have regex and you exceed to possibilities it provides.
I really have a bad feeling while saying: It would be good to have pillar based on petit parser.
Norbert
2015-03-12 9:46 GMT+01:00 kilon alios <kilon.alios@gmail.com>:
It would be nice to have a parser to rule them all. I am currently using SmaCC and gets the job done. I really like its condense syntax and its syntax tool but also love the smalltalky feel of pettit parser.
Maybe one must bite the bullet and write perfomance critical parts in C or even use a C parsing engine as a back end of pettit parser ?
This would be overkill. Smalltalk is fast enough.
From what Doru was talking about, we should have at least some knowledge on what is slow in PetitParser by ESUG. I saw some things by just profiling it once.
My position on that is that PetitParser reliance on PEG is a weakness, especially compared to the current state of competing tools (GLR in SmaCC, LL(*) in ANTLR, Parsing with Derivatives, GLL). And if you combine it with performance problems, then that doesn't look so good. On the other hand, PetitParser has a lot going for it: parser combinators (but PwD and GLL also have that), parser reuse, parsing debug. Now, if you tell me a Pillar based parser in SmaCC, I'd say: easy and fast. With a nice, formal grammar defining/documenting the Pillar as a side benefit, which would make maintaining Pillar parsing very easy for the long term. (and that formal grammar would make writing a PetitParser pillar parser a breeze :)). Thierry
participants (7)
-
Christophe Demarey -
Damien Cassou -
kilon alios -
Norbert Hartl -
stepharo -
Thierry Goubier -
Tudor Girba