On 27/02/14 14:58, Marcus Denker wrote:
On 27 Feb 2014, at 13:56, Jan Vrany <[email protected]> wrote:
On 24/02/14 19:06, Marcus Denker wrote:
Pharo uses (right now) RBParser as the main Parser… in Pharo4 we will remove
the old Parser (subclass of Scanner ;-),
on the TODO is to check if PetitParser can be used instead (but there are many
open questions related to e.g. error handling,
speed…)
This is interesting for me. I would not go for petitparser personally.
My experience, speaking of performance and error reporting, not so
great.
Yes… sadly. Especially good error reporting is very crucial. Yet it would be so
nice if Pharo would contain a hight level
reflective meta model of it’s own grammar!
I have one question: If you replace RBParser with green-field implementation,
how would you deal with the rest of RB stuff?
Refactorings, lint etc, which are all based of RBParser API?
The RBParser itself has a very small API… “give me an AST for a string”
(#parseMethod: and #parseExpression:, in addition
#parseMethodPattern: and some special ones for rewrite rules (which is kind of
a DSL on top of Smalltalk, these methods
already forward to RBPatternParser, a subclass of RBParser)
Well, I meant RBParser and RB AST API, actually :-)
In Pharo3 we already replaced all the references to Parser, Scanner and
Compiler with a call to get the Opal compiler
facade. Wen we remove the old compiler in Pharo4, the next step is to do the
same with *all* direct references
to RBParser.
(we could not yet do that as, when you enable the old compiler, you get the old
AST back… for code generation it has
the same API, for refactoring not as the old AST does not support that. So for
now we kept the code in a state that
you can disable Opal, yet refactoring still uses RBParser explicitly. When
there is just one compiler, we can simplify
that even further).
So after doing that, the actual implementation of the Parser can then be easily
exchanged, the only thing it needs to do
is to create a RB AST.
OK, so the idea is remove RBParser but keep all RBProgramNode classes?
Jan
