[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Texmacs-dev] Nested environments (was: Using STL)
From: |
David Allouche |
Subject: |
Re: [Texmacs-dev] Nested environments (was: Using STL) |
Date: |
Fri, 17 May 2002 11:40:26 +0200 |
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 --
- [Texmacs-dev] Using STL, David Allouche, 2002/05/14
- Re: [Texmacs-dev] Using STL, Joris van der Hoeven, 2002/05/14
- Re: [Texmacs-dev] Using STL, Joris van der Hoeven, 2002/05/14
- Re: [Texmacs-dev] Using STL, David Allouche, 2002/05/14
- Re: [Texmacs-dev] Using STL, Joris van der Hoeven, 2002/05/14
- Re: [Texmacs-dev] Using STL, David Allouche, 2002/05/15
- Re: [Texmacs-dev] Using STL, Joris van der Hoeven, 2002/05/15
- Re: [Texmacs-dev] Nested environments (was: Using STL),
David Allouche <=
- [Texmacs-dev] Optimizing assignations in TMSL, David Allouche, 2002/05/17
- Re: [Texmacs-dev] Optimizing assignations in TMSL, David Allouche, 2002/05/17