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
