Context: I cannot find where a comment is stored in a returnNode or its child like the comment at the end of this method.
Stephen, I've pretty much decided that Squeak's parse nodes are best left for *compiling*, not for analysis. I had a rough time just decoding what variable a variable referred to, for example. This would appear to be another example of the problem.
I'd recommend my "Lucid" parser, but actually, I think it completely discards comments, so no luck. :| There are other Smalltalk parsers floating around, however.
It would be nice if Squeak had an analysis-friendly parser in it. But Smalltalk is such a simple language, everyone seems to just cobble together a parser for their own needs.
-Lex
hi lex
It would be nice if Squeak had an analysis-friendly parser in it. But Smalltalk is such a simple language, everyone seems to just cobble together a parser for their own needs.
But the do it syndrome is something that I hate (when I arrived in Smalltalk people where telling me that I just have to do it if I need it and I hated that.)
For the moment I will try to continue with the current parser and stabilize Gutenberg but this is true that I will certainly look at the RBparser because I would like to have something that is documented (not patched several times) and that I can understand.
I think that one way to go is to see if we can have enough momentum to create projects that can survive chronicle image changes. So where is the Lucid parser? Do you have tests? Because I could look at it as a basis for starting one.
For me the definitive test for squeak will be after the modules and the start of the SqueakFoundation. If after the modules and Squeak Foundation start the code of Squeak stays the same state meaning
- if people willing to help improving the internal code of Squeak can't do it because it is too difficult to change, improve and - if the code continue to be in such a state that I cannot lose my software engineer credibility: randomly look at SystemDictionary, Utilities, Morph). - if the process is not more open and responsibilities distributed
I will just give up Squeak which will stay a nice experimental blob with fancy facilities. Sadly. Shouting in the desert is cool for one moment but fighting with a blob that keeps growing is not fun.
VW is not open source (at least we do not expect too much from them) but they are moving and they are giving some good signs. I know that we can have the code of the VW VM if we sign non-disclosure agreement so this also may a way to go for experimenting with alternate designs.
Stef
So I hope 2002 will be the year of Squeak. Because I would be sincerly sad if it stays the same.
ducasse wrote:
Lex Spoon wrote:
Stephen, I've pretty much decided that Squeak's parse nodes are best left for *compiling*, not for analysis. I had a rough time just decoding what variable a variable referred to, for example. This would appear to be another example of the problem.
It would be nice if Squeak had an analysis-friendly parser in it. But Smalltalk is such a simple language, everyone seems to just cobble together a parser for their own needs.
But the do it syndrome is something that I hate (when I arrived in Smalltalk people where telling me that I just have to do it if I need it and I hated that.)
Henrik Gedenryd posted some changes recently which improve the current parser somewhat, at least to separate the optimizing parse (for compiling) from non-optimizing (for pretty-printing, etc.). (See http://groups.yahoo.com/group/squeak/message/36808) I think we should try to include these in the next round of harvesting.
On the other hand, I'm not sure if those changes are a big enough step toward a really analysis-friendly parser or not. I haven't done a lot of work with parsers.
For the moment I will try to continue with the current parser and stabilize Gutenberg but this is true that I will certainly look at the RBparser because I would like to have something that is documented (not patched several times) and that I can understand.
If the Refactoring Browser becomes a relatively standard tool for Squeak (maybe when the modules stuff happens), then the RBparser might become the de facto alternate parser. (Of course anyone is free to roll their own parser, but it'd be good to have one well-supported analysis-friendly parser.)
For me the definitive test for squeak will be after the modules and the start of the SqueakFoundation. ...
So I hope 2002 will be the year of Squeak. ...
Me too. :-)
- Doug Way dway@riskmetrics.com
Doug Way wrote:
Henrik Gedenryd posted some changes recently which improve the current parser somewhat, at least to separate the optimizing parse (for compiling) from non-optimizing (for pretty-printing, etc.). (See http://groups.yahoo.com/group/squeak/message/36808) I think we should try to include these in the next round of harvesting.
On the other hand, I'm not sure if those changes are a big enough step toward a really analysis-friendly parser or not. I haven't done a lot of work with parsers.
I was able to write a partial evaluator into the current parse node classes without having to make any invasive changes. PE is probably more complex than most analysis tasks, so the parser isn't totally hopeless. I did however also consider adding a parent reference to the parse nodes, so this seems like a generally useful feature to have; I'd probably be in favor of adding that if necessary.
You can get indices to the source code by using the decompiler, there is an example somewhere in the Environments code.
I also recall there being some weirdness in the inheritance structure that made some things less elegant than they could be.
There is a fair share of non-parsing code in the parse nodes, but that is what you get with the limitations of inheritance. I saw Eric Gamma confess in a talk (in relation to downsides with patterns) that Visitor wasn't such a great idea after all. And it probably means something that parsers are a favorite example used by the aspect people...
So I hope 2002 will be the year of Squeak. ...
Me too. :-)
Every year is the year of Squeak! The good thing about not being in fashion is that you cannot go out of fashion.
My wish for the Squeak future is to see more work breaking new ground, and less of "a Squeak version of X", or other variants of reproducing what others have already done. But that is of course my personal point of view.
Henrik
Hi Henrik
I was able to write a partial evaluator into the current parse node classes without having to make any invasive changes. PE is probably more complex than most analysis tasks, so the parser isn't totally hopeless.
I was not saying that but when you have information that is available only on the satck (this is was I presume else why this data would disappear when I just proceed after a self halt.) I think that the state is shaky.
Then you are certainly smarter than me. I never said that I was bright I need simple and clear design.
I did however also consider adding a parent reference to the parse nodes, so this seems like a generally useful feature to have; I'd probably be in favor of adding that if necessary.
You can get indices to the source code by using the decompiler, there is an example somewhere in the Environments code.
You see why do we need to decompile byte code to get source code element. I was thikning that nodes and tree elements were made for that purpose.
I should be able to work only the the tree and not a really specific result of the tree processing that is byte-code emission.
I also recall there being some weirdness in the inheritance structure that made some things less elegant than they could be.
There is a fair share of non-parsing code in the parse nodes, but that is what you get with the limitations of inheritance. I saw Eric Gamma confess in a talk (in relation to downsides with patterns) that Visitor wasn't such a great idea after all. And it probably means something that parsers are a favorite example used by the aspect people...
Gamma is certainly right. I was sherpherd at Plop last years and people are writing really ****silly**** about pattern. I reviewed a paper on visitor where the visitor intent was completely corrputed.
Here the visitor applies well because the tree element is stable and we want to do different computation and wisth them dynamically. And we do not want to have tons of switch statements in the methods. I'm sure you know that the logic of some node printOn: methods is not simple as it should be.
So I hope 2002 will be the year of Squeak. ...
Me too. :-)
Every year is the year of Squeak! The good thing about not being in fashion is that you cannot go out of fashion.
My wish for the Squeak future is to see more work breaking new ground, and less of "a Squeak version of X", or other variants of reproducing what others have already done. But that is of course my personal point of view.
I agree but first I would like to have tools that I can use to be as efficient as other environments.
You see for example the fact that I have to simple more than hour to discover (like Tim) that we should do window model: self before any other methods is frustrating.
Stef
squeak-dev@lists.squeakfoundation.org