Hello, we were working on the issue 10983 plus smart suggestion, specially for a class definition. In a moment I need to parse a class definition, I treat as the normal case: root := OpalCompiler new source: context code; useFaultyForParsing: true; parse. And as a result we obtain a Method Node, browsing the code we saw that Opal can parse code as an expresion, but instead it is treating the code as method because of: "self compilationContext noPattern" is false, when we changed the boolean to true we obtain a return node for the class definition and everything got messy. Can someone help us to use Opal in the right way?
On 07 Nov 2013, at 22:14, Gisela Decuzzi <giseladecuzzi@gmail.com> wrote:
Hello, we were working on the issue 10983 plus smart suggestion, specially for a class definition. In a moment I need to parse a class definition, I treat as the normal case: root := OpalCompiler new source: context code; useFaultyForParsing: true; parse. And as a result we obtain a Method Node, browsing the code we saw that Opal can parse code as an expresion, but instead it is treating the code as method because of: "self compilationContext noPattern" is false, when we changed the boolean to true we obtain a return node for the class definition and everything got messy.
Can someone help us to use Opal in the right way?
The problem is that #noPattern is only used for compiling DoIts, and those are more than just an expression (return added, access to temps rewrittenâ¦). So for now, the best (yet ugly) thing is to just use RBParser directly, and we later have to think a bit about the API of the OpalCompiler facade, especially considering it is both a facade to just the parser *and* to the compiler, and e.g expression parsing is very different from parsing a doit, even though one would think they are the same. So for now, just use the RBParser directly, I would say (there are lots of direct users of it, we can only remove them in Pharo4 when we have just one AST). Marcus
Ok, it would be nice to avoid using the parser directly. But we can change it in the future, for now we have a new version for https://pharo.fogbugz.com/f/cases/10983/Represent-a-class-definition-with-AS... in inbox. Thanks! 2013/11/8 Marcus Denker <marcus.denker@inria.fr>
On 07 Nov 2013, at 22:14, Gisela Decuzzi <giseladecuzzi@gmail.com> wrote:
Hello, we were working on the issue 10983 plus smart suggestion, specially for a class definition. In a moment I need to parse a class definition, I treat as the normal case: root := OpalCompiler new source: context code; useFaultyForParsing: true; parse. And as a result we obtain a Method Node, browsing the code we saw that Opal can parse code as an expresion, but instead it is treating the code as method because of: "self compilationContext noPattern" is false, when we changed the boolean to true we obtain a return node for the class definition and everything got messy.
Can someone help us to use Opal in the right way?
The problem is that #noPattern is only used for compiling DoIts, and those are more than just an expression (return added, access to temps rewrittenâ¦).
So for now, the best (yet ugly) thing is to just use RBParser directly, and we later have to think a bit about the API of the OpalCompiler facade, especially considering it is both a facade to just the parser *and* to the compiler, and e.g expression parsing is very different from parsing a doit, even though one would think they are the same.
So for now, just use the RBParser directly, I would say (there are lots of direct users of it, we can only remove them in Pharo4 when we have just one AST).
Marcus
thanks gisela I love so much the suggestions :) Stef On Nov 8, 2013, at 11:28 AM, Gisela Decuzzi <giseladecuzzi@gmail.com> wrote:
Ok, it would be nice to avoid using the parser directly. But we can change it in the future, for now we have a new version for https://pharo.fogbugz.com/f/cases/10983/Represent-a-class-definition-with-AS... in inbox.
Thanks!
2013/11/8 Marcus Denker <marcus.denker@inria.fr>
On 07 Nov 2013, at 22:14, Gisela Decuzzi <giseladecuzzi@gmail.com> wrote:
Hello, we were working on the issue 10983 plus smart suggestion, specially for a class definition. In a moment I need to parse a class definition, I treat as the normal case: root := OpalCompiler new source: context code; useFaultyForParsing: true; parse. And as a result we obtain a Method Node, browsing the code we saw that Opal can parse code as an expresion, but instead it is treating the code as method because of: "self compilationContext noPattern" is false, when we changed the boolean to true we obtain a return node for the class definition and everything got messy.
Can someone help us to use Opal in the right way?
The problem is that #noPattern is only used for compiling DoIts, and those are more than just an expression (return added, access to temps rewrittenâ¦).
So for now, the best (yet ugly) thing is to just use RBParser directly, and we later have to think a bit about the API of the OpalCompiler facade, especially considering it is both a facade to just the parser *and* to the compiler, and e.g expression parsing is very different from parsing a doit, even though one would think they are the same.
So for now, just use the RBParser directly, I would say (there are lots of direct users of it, we can only remove them in Pharo4 when we have just one AST).
Marcus
participants (3)
-
Gisela Decuzzi -
Marcus Denker -
Stéphane Ducasse