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