Re: [Texmacs-dev] Nested environments (was: Using STL)

[David Allouche]

Ok, I am going to have a couple of days of work on transformations again, 
until the pending questions for nogencc are settled.

On Wednesday 15 May 2002 18:37, Joris van der Hoeven wrote:
> On Wed, 15 May 2002, David Allouche wrote:
> > I am thinking of imlementing the TMSL enviroment as a linked list of
> > tmsl_env objects. Each object can be either a VAL environment (the
> > top level, and environments created by WITH and APPLY) or a ARG
> > environment (created by EXPAND).
>
> This is probably a *bad* idea (I am sorry to be harsh).

Absolutely no problem.

I was aware that the linear(depth) environment resolution was 
problematic. However I consider it a good conceptual model and a 
necessary mental step in understanding that problem. I think I will try 
to write interfaces which make it clear we are conceptually working with 
nested environments regardless of the underlying optimizations.

I am going to examine your solution. By the way, it would be helpful if 
you could point me out the relevant methods in the edit_env class... I 
did not look at it because I found it quite overhelming.

> > But if you insist on it, and do not ask me to write or debug it, ok.
>
> Yes, I insist and will do it, if necessary of course...

Ok. We will rediscuss that when I have considered your environment 
implementation solution.

> > > OK. Please remind my remark on using NEW_TREES + tree for ttree.
> > > This will allow you to concentrate of the really essential stuff:
> > > the rewriters.
> >
> > I have already written ttree. But If you want, I may merge the code
> > with tree.
>
> Good, can you post your code to texmacs-dev?

Nah. The only meaningful parts of the code were about optimizing ip 
comparison. So, since I am going to drop that, there was nothing 
interesting.

> > I have already figured out that we must not consider the shared tail
> > structure; though I use it to reduce the quadratic(depth) complexity
> > induced by inverse path traversal to linear(depth)-best-case and
> > quadratic(depth)-worse-case.
>
> I do not see why we should not use it;
> it is very efficient, even though it is a bit dirty.
> But if we implement it well, then the dirtyness should
> be completely located in a well determined part of
> the source code (a bit like reference counting).

That is not what I meant. I think that inverse paths with shared tails is 
a nice and elegant trick. I generally do not like tricky code, but if you 
have ever made a bit of list processing in Lisp, it is quite obvious 
actually.

What I meant is that we should not consider the shared tail structure of 
a ttree while doing equality comparison. I had considered that because 
two ttrees with different shared tail structures are functionally 
distinct even if at a given point they have the same apparent value.
-- 

                                  -- David --