[Pharo-project] Issue 3525 in pharo: Compiler>>parserClass is broken and does not querying the class for providing the parser class
Status: Accepted Owner: siguctua New issue 3525 by siguctua: Compiler>>parserClass is broken and does not querying the class for providing the parser class http://code.google.com/p/pharo/issues/detail?id=3525 In the following: Compiler>>parserClass ^parser ifNil: [self class parserClass] ifNotNil: [parser class] 'self class' should actually be 'class parserClass' So, any class could override the default parser by own. In that way a default parser class is answered by Behavior, not by Compiler. A Compiler class>>parserClass is useless. But even more than that, due to initializing 'parser' ivar in Compiler>>new, it never gets to that code, and evaluating 'parser class' So, a class can't specify a custom parser class to compiler.
Comment #1 on issue 3525 by Torsten....@astares.de: Compiler>>parserClass is broken and does not querying the class for providing the parser class http://code.google.com/p/pharo/issues/detail?id=3525 But that would ONLY associate A CLASS with its own parser/compiler. But wouldnt it make more sense on the method level. Default is Smalltalk and for any other syntax you can use a pragma: foo <language: 'JavaScript'> alert('hi'); bar <language: 'C'> _export(...) You could return a script for Seaside or store an XML in a method, write VMMaker in C in the ST browser, ... I think VW has something similar since I've seen this once in a VW browser. Smalltalk/X too since you can write C directly in the ST browser. Depending on the pragma you could do syntax highligting, provide tools, ...
Comment #2 on issue 3525 by siguctua: Compiler>>parserClass is broken and does not querying the class for providing the parser class http://code.google.com/p/pharo/issues/detail?id=3525 Here the test case, which covers this issue Attachments: CustomParserTest.1.cs 1005 bytes
Comment #3 on issue 3525 by siguctua: Compiler>>parserClass is broken and does not querying the class for providing the parser class http://code.google.com/p/pharo/issues/detail?id=3525
Default is Smalltalk and for any other syntax you can use
Default is 'Parser' :) a pragma: foo
<language: 'JavaScript'>
before you get there, you should use some kind of parser to parse the pragma, and i don't see why it should be prohibited from changing a default parser for source code. It should be possible to instruct the compiler to use different parser for parsing a source code of my class methods, so a method's source code could look like: <xml> <method name="foo"> <return> <message><receiver><self/></receiver> <selector value="foo"/> </message> </return> </method> </xml> :)
Comment #4 on issue 3525 by siguctua: Compiler>>parserClass is broken and does not querying the class for providing the parser class http://code.google.com/p/pharo/issues/detail?id=3525 For example, OMeta using custom parser/compiler for own source code. So, custom parsers for parsing methods in fact are common.
Updates: Status: Fixed Comment #5 on issue 3525 by siguctua: Compiler>>parserClass is broken and does not querying the class for providing the parser class http://code.google.com/p/pharo/issues/detail?id=3525 Here the fix. Test are green afterwards. AFAIK, this bug+fix applicable to Squeak as well. Attachments: CompilerParser-class-fix.1.cs 408 bytes
Updates: Labels: Milestone-1.2 Comment #6 on issue 3525 by siguctua: Compiler>>parserClass is broken and does not querying the class for providing the parser class http://code.google.com/p/pharo/issues/detail?id=3525 (No comment was entered for this change.)
Updates: Status: closed Comment #7 on issue 3525 by stephane.ducasse: Compiler>>parserClass is broken and does not querying the class for providing the parser class http://code.google.com/p/pharo/issues/detail?id=3525 in 12297
On Mon, Jan 10, 2011 at 9:46 AM, <pharo@googlecode.com> wrote:
Status: Accepted Owner: siguctua
New issue 3525 by siguctua: Compiler>>parserClass is broken and does not querying the class for providing the parser class http://code.google.com/p/pharo/issues/detail?id=3525
In the following:
Compiler>>parserClass
^parser ifNil: [self class parserClass] ifNotNil: [parser class]
Who writes this stuff ?? ;) <blush> I suggest the attached: parserClass ^parser ifNil: [(class ifNil: [self class]) parserClass] ifNotNil: [parser class]
'self class' should actually be 'class parserClass'
So, any class could override the default parser by own. In that way a default parser class is answered by Behavior, not by Compiler. A Compiler class>>parserClass is useless.
But even more than that, due to initializing 'parser' ivar in Compiler>>new, it never gets to that code, and evaluating 'parser class' So, a class can't specify a custom parser class to compiler.
Will it work ? because Compiler class>>new ^ super new parser: self parserClass new sets the parser ivar with Compiler parserClass new. Maybe you'll need to remove this definition of new too. Nicolas 2011/1/10 Eliot Miranda <eliot.miranda@gmail.com>:
On Mon, Jan 10, 2011 at 9:46 AM, <pharo@googlecode.com> wrote:
Status: Accepted Owner: siguctua
New issue 3525 by siguctua: Compiler>>parserClass is broken and does not querying the class for providing the parser class http://code.google.com/p/pharo/issues/detail?id=3525
In the following:
Compiler>>parserClass
    ^parser ifNil: [self class parserClass] ifNotNil: [parser class]
Who writes this stuff ?? ;) <blush> I suggest the attached: parserClass ^parser ifNil: [(class ifNil: [self class]) parserClass] ifNotNil: [parser class]
'self class' should actually be 'class parserClass'
So, any class could override the default parser by own. In that way a default parser class is answered by Behavior, not by Compiler. A Compiler class>>parserClass is useless.
But even more than that, due to initializing 'parser' ivar in Compiler>>new, it never gets to that code, and evaluating 'parser class' So, a class can't specify a custom parser class to compiler.
Parser is not hardcoded (except in tests), but parserClass is sometimes sent to the wrong class.. Example is Text>>makeSelectorBold (sent from Debugger) It should be replaced with makeSelectorBoldIn: Also notice that source code files cannot be analyzed if they contain classes absent from current system that define their own parserClass. That is a problem for change lists, and possibly for MC (it would be interesting to try). Nicolas 2011/1/10 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
Will it work ?
because Compiler class>>new     ^ super new parser: self parserClass new
sets the parser ivar with Compiler parserClass new. Maybe you'll need to remove this definition of new too.
Nicolas
2011/1/10 Eliot Miranda <eliot.miranda@gmail.com>:
On Mon, Jan 10, 2011 at 9:46 AM, <pharo@googlecode.com> wrote:
Status: Accepted Owner: siguctua
New issue 3525 by siguctua: Compiler>>parserClass is broken and does not querying the class for providing the parser class http://code.google.com/p/pharo/issues/detail?id=3525
In the following:
Compiler>>parserClass
    ^parser ifNil: [self class parserClass] ifNotNil: [parser class]
Who writes this stuff ?? ;) <blush> I suggest the attached: parserClass ^parser ifNil: [(class ifNil: [self class]) parserClass] ifNotNil: [parser class]
'self class' should actually be 'class parserClass'
So, any class could override the default parser by own. In that way a default parser class is answered by Behavior, not by Compiler. A Compiler class>>parserClass is useless.
But even more than that, due to initializing 'parser' ivar in Compiler>>new, it never gets to that code, and evaluating 'parser class' So, a class can't specify a custom parser class to compiler.
On 10 January 2011 20:52, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Parser is not hardcoded (except in tests), but parserClass is sometimes sent to the wrong class.. Example is Text>>makeSelectorBold (sent from Debugger) It should be replaced with makeSelectorBoldIn:
Also notice that source code files cannot be analyzed if they contain classes absent from current system that define their own parserClass. That is a problem for change lists, and possibly for MC (it would be interesting to try).
I think that there could be a solution to that. We could require that certain methods like #newParser, #newCompiler should be written in smalltalk. Then code import tools could rely on that and compile these methods first, and then could use them to compile the rest of class'es source code.
Nicolas
-- Best regards, Igor Stasenko AKA sig.
but igor for example in the case of soul, it means that you should load the SoulCompiler which is normal if you want to use soul compiled methods. Now having a reference to a class makes static warning easier than just an object. Stef On Jan 11, 2011, at 12:55 AM, Igor Stasenko wrote:
On 10 January 2011 20:52, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Parser is not hardcoded (except in tests), but parserClass is sometimes sent to the wrong class.. Example is Text>>makeSelectorBold (sent from Debugger) It should be replaced with makeSelectorBoldIn:
Also notice that source code files cannot be analyzed if they contain classes absent from current system that define their own parserClass. That is a problem for change lists, and possibly for MC (it would be interesting to try).
I think that there could be a solution to that. We could require that certain methods like #newParser, #newCompiler should be written in smalltalk. Then code import tools could rely on that and compile these methods first, and then could use them to compile the rest of class'es source code.
Nicolas
-- Best regards, Igor Stasenko AKA sig.
On 11 January 2011 09:14, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
but igor for example in the case of soul, it means that you should load the SoulCompiler which is normal if you want to use soul compiled methods. Now having a reference to a class makes static warning easier than just an object.
From that perspective it doesn't makes any difference: referencing a missing class in #compilerClass, or in #newCompiler would lead to same error/warning.
What makes these approaches different is where you controlling the creation and initialization of compiler instance.
Stef
On Jan 11, 2011, at 12:55 AM, Igor Stasenko wrote:
On 10 January 2011 20:52, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Parser is not hardcoded (except in tests), but parserClass is sometimes sent to the wrong class.. Example is Text>>makeSelectorBold (sent from Debugger) It should be replaced with makeSelectorBoldIn:
Also notice that source code files cannot be analyzed if they contain classes absent from current system that define their own parserClass. That is a problem for change lists, and possibly for MC (it would be interesting to try).
I think that there could be a solution to that. We could require that certain methods like #newParser, #newCompiler should be written in smalltalk. Then code import tools could rely on that and compile these methods first, and then could use them to compile the rest of class'es source code.
Nicolas
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On Mon, Jan 10, 2011 at 11:42 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Will it work ?
because Compiler class>>new ^ super new parser: self parserClass new
sets the parser ivar with Compiler parserClass new. Maybe you'll need to remove this definition of new too.
I think it works. Behavior>>parser class gets compilerClass parserClass: Behavior>>parserClass "Answer a parser class to use for parsing method headers." ^self compilerClass parserClass So one is supposed to implement a Compiler subclass that defines a class-side parserClass method. e.g. MySpecialClass>>compilerClass ^MySpecialCompiler MySpecialCompiler class>>parserClass ^MySpecialParser So then Compiler>>parserClass ^parser ifNil: [(class ifNil: [self class]) parserClass] ifNotNil: [parser class] will also find MySpecialParser. Yes, its heavyweight because the Compiler subclass isn't providing anything other than the reference to the parser. But that's the way the system is written so far. what do you think? best Eliot
Nicolas
2011/1/10 Eliot Miranda <eliot.miranda@gmail.com>:
On Mon, Jan 10, 2011 at 9:46 AM, <pharo@googlecode.com> wrote:
Status: Accepted Owner: siguctua
New issue 3525 by siguctua: Compiler>>parserClass is broken and does not querying the class for providing the parser class http://code.google.com/p/pharo/issues/detail?id=3525
In the following:
Compiler>>parserClass
^parser ifNil: [self class parserClass] ifNotNil: [parser class]
Who writes this stuff ?? ;) <blush> I suggest the attached: parserClass ^parser ifNil: [(class ifNil: [self class]) parserClass] ifNotNil:
[parser
class]
'self class' should actually be 'class parserClass'
So, any class could override the default parser by own. In that way a default parser class is answered by Behavior, not by Compiler. A Compiler class>>parserClass is useless.
But even more than that, due to initializing 'parser' ivar in Compiler>>new, it never gets to that code, and evaluating 'parser class' So, a class can't specify a custom parser class to compiler.
2011/1/10 Eliot Miranda <eliot.miranda@gmail.com>:
On Mon, Jan 10, 2011 at 11:42 AM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Will it work ?
because Compiler class>>new     ^ super new parser: self parserClass new
sets the parser ivar with Compiler parserClass new. Maybe you'll need to remove this definition of new too.
I think it works.  Behavior>>parser class gets compilerClass parserClass: Behavior>>parserClass "Answer a parser class to use for parsing method headers." ^self compilerClass parserClass So one is supposed to implement a Compiler subclass that defines a class-side parserClass method.  e.g. MySpecialClass>>compilerClass    ^MySpecialCompiler MySpecialCompiler class>>parserClass    ^MySpecialParser So then Compiler>>parserClass ^parser ifNil: [(class ifNil: [self class]) parserClass] ifNotNil: [parser class] will also find MySpecialParser. Yes, its heavyweight because the Compiler subclass isn't providing anything other than the reference to the parser. But that's the way the system is written so far. what do you think? best Eliot
I think you are right, the system is like that, and if I remember already was in st80 v2.3. I used this feature, but my CustomCompiler didn't have many methods, mostly #parserClass. So we have a right to question this implementation. Nicolas
On Mon, Jan 10, 2011 at 12:42 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2011/1/10 Eliot Miranda <eliot.miranda@gmail.com>:
On Mon, Jan 10, 2011 at 11:42 AM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Will it work ?
because Compiler class>>new ^ super new parser: self parserClass new
sets the parser ivar with Compiler parserClass new. Maybe you'll need to remove this definition of new too.
I think it works. Behavior>>parser class gets compilerClass parserClass: Behavior>>parserClass "Answer a parser class to use for parsing method headers." ^self compilerClass parserClass So one is supposed to implement a Compiler subclass that defines a class-side parserClass method. e.g. MySpecialClass>>compilerClass ^MySpecialCompiler MySpecialCompiler class>>parserClass ^MySpecialParser So then Compiler>>parserClass ^parser ifNil: [(class ifNil: [self class]) parserClass] ifNotNil:
[parser
class] will also find MySpecialParser. Yes, its heavyweight because the Compiler subclass isn't providing anything other than the reference to the parser. But that's the way the system is written so far. what do you think? best Eliot
I think you are right, the system is like that, and if I remember already was in st80 v2.3. I used this feature, but my CustomCompiler didn't have many methods, mostly #parserClass. So we have a right to question this implementation.
I think the bug is that classes are expected to answer compiler and parser classes, not compiler and parser instances. If things were organized like this: Behavior>parserClass ^Parser Behavior>compilerClass ^Compiler Behavior>newParser ^self parserClass new Behavior>newCompiler ^self compilerClass new parser: self newParser and the compilation utility methods used "self newCompiler" then one could implement just parserClass to obtain the desired effect. What do you think? best Eliot
Nicolas
On 10 January 2011 22:50, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Mon, Jan 10, 2011 at 12:42 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2011/1/10 Eliot Miranda <eliot.miranda@gmail.com>:
On Mon, Jan 10, 2011 at 11:42 AM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Will it work ?
because Compiler class>>new     ^ super new parser: self parserClass new
sets the parser ivar with Compiler parserClass new. Maybe you'll need to remove this definition of new too.
I think it works.  Behavior>>parser class gets compilerClass parserClass: Behavior>>parserClass "Answer a parser class to use for parsing method headers." ^self compilerClass parserClass So one is supposed to implement a Compiler subclass that defines a class-side parserClass method.  e.g. MySpecialClass>>compilerClass    ^MySpecialCompiler MySpecialCompiler class>>parserClass    ^MySpecialParser So then Compiler>>parserClass ^parser ifNil: [(class ifNil: [self class]) parserClass] ifNotNil: [parser class] will also find MySpecialParser. Yes, its heavyweight because the Compiler subclass isn't providing anything other than the reference to the parser. But that's the way the system is written so far. what do you think? best Eliot
I think you are right, the system is like that, and if I remember already was in st80 v2.3. I used this feature, but my CustomCompiler didn't have many methods, mostly #parserClass. So we have a right to question this implementation.
I think the bug is that classes are expected to answer compiler and parser classes, not compiler and parser instances.  If things were organized like this: Behavior>parserClass    ^Parser Behavior>compilerClass    ^Compiler Behavior>newParser    ^self parserClass new Behavior>newCompiler    ^self compilerClass new parser: self newParser and the compilation utility methods used "self newCompiler" then one could implement just parserClass to obtain the desired effect. What do you think?
+1000 i learned that requesting an initialized instance is much more convenient & flexible than requesting a class just for sending 'new' to it. Classes with complex API often don't giving the answer, how properly initialize its instances, which leads to confusion and inability to properly connect layers of framework and/or install proper hooks which in own turn leads to bad coding practices like attempts to control object initialization outside of its factory (a class, or object which is really should be responsible for providing it). In our concrete situation, a #newCompiler message is much more powerful expression, because it allows a responding object to answer partially of fully initialized object, and in this way shifting the responsibility of its initialization to right place. And in this way, an object which going to answer it, could take care and properly initialize it, like setting a custom parser. This is what you can't do by answering classes all the way, since the only guaranteed protocol of class is a #new message.. Limiting and not very helpful. I think that the rule of thumb in all such cases should be following: - if your code works with objects which implement a certain protocol, explicitly state that your code requires a preinitialized instance which comes from other objects, which you communicating with. Never require any intermediary object(s), because they are actually an information noise and really should not be a concern of your code.
best Eliot
Nicolas
-- Best regards, Igor Stasenko AKA sig.
participants (5)
-
Eliot Miranda -
Igor Stasenko -
Nicolas Cellier -
pharo＠googlecode.com -
Stéphane Ducasse