Losing my latin

ducasse ducasse at iam.unibe.ch
Wed Jan 9 19:34:52 UTC 2002


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





More information about the Squeak-dev mailing list