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)

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.

The Opal compilationContext has already a #parserClass accessor that right now 
returns RBParser, but that any user
can override. (this is not yet used so it might not work, but the machinery is 
there).

        Marcus

Reply via email to