Hi Marcus,
thank you for the deep explanation. I have just started to play with parsing
source code. And I have found out the OpalCompiler example.
Now I understand it is better to use this:
root2 := RBParser parseMethod: 'foo1
^Color blue'.
node5 := root2 bestNodeFor: (14 to: 14).
node6 := root2 bestNodeFor: (20 to: 21).
There is even RBParser>>parseExpression:, if I need it.
Cool! Thanks to point me to the right direction.
Jura
El 23-11-2013, a las 5:33, Marcus Denker <[email protected]> escribió:
>
> On 22 Nov 2013, at 21:58, Juraj Kubelka <[email protected]> wrote:
>
>> Hi!
>>
>> I am interested how to use Opal for parsing peace of code. I have supposed
>> to use something like this:
>>
>> | root node1 node2 |
>> root := OpalCompiler new
>> source: 'Color blue yourself';
>> useFaultyForParsing: true;
>> parse.
>> root doSemanticAnalysis.
>> node1 := root bestNodeFor: (2 to: 2).
>> node2 := root bestNodeFor: (7 to: 7).
>>
>> But node1 is a RBMethodNode, and node2 is a RBVariableNode.
>>
>> Does it matter if source for OpalCompiler is peace of code or method source?
>>
>
> Yes, by default it parses methods. When you tell it to parse expressions, it
> parses them
> as doit-methods (it wraps them into a method node named DoIt and adds a
> return at the end).
> We need to provide a way that it can parse expressions… or maybe hide the
> Doit transform in the
> “compile” while the parse gives you an untransformed expression?
>
> We need to do some more iterations on the API to make it nice to use as a
> general facade for the Parser.
> Right now the API was driven purely by replacing existing usage without too
> much change,
> as both Compiler and OpalCompiler have the same API (they are exchangeable).
>
> Doing the second iteration with keeping compatibility would be quite a
> challenge (and not fun to do),
> so I will start with that as soon as we retire the old compiler and thus are
> in a position to really clean up.
>
> other notes:
>
> - the faulty (code with syntax error) parsing is very much an experiment. Do
> you need it?
> - maybe for now just using RPParser directly is better.
>
> Yes, we need to enhance the OpalCompiler API to be good enough to not need
> any direct references to
> any Parser (so people can plug their own).
> E.g. there are lots of references to RBParser in the Refactoring Engine. The
> problem is that is we replace
> them now, then all these uses break when you switch to the old Compiler as it
> uses a different API.
>
> So summary: it needs more work, but we can only do that in Pharo4.
>
> Marcus
