Re: [Pharo-users] Pillar parser rewrite: PetitParser or not?

[stepharo]

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 
mailto:damien.cas...@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"

Re: [Pharo-users] Pillar parser rewrite: PetitParser or not?

[Christophe Demarey]

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. 



smime.p7s
Description: S/MIME cryptographic signature

Re: [Pharo-users] Pillar parser rewrite: PetitParser or not?

[Thierry Goubier]

2015-03-12 9:46 GMT+01:00 kilon alios :

> 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

Re: [Pharo-users] Pillar parser rewrite: PetitParser or not?

[kilon alios]

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  wrote:

>
> > Am 11.03.2015 um 23:03 schrieb Damien Cassou :
> >
> > 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
>
>
>
>
>

Re: [Pharo-users] Pillar parser rewrite: PetitParser or not?

[Norbert Hartl]

> Am 11.03.2015 um 23:03 schrieb Damien Cassou :
> 
> 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

Re: [Pharo-users] Pillar parser rewrite: PetitParser or not?

[Tudor Girba]

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 
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"