Re: src/Synopsis/PTree/operations.cc

Gilles J. Seguin wrote:
> stefan, recheck this
> they are not equal if both null, do they.
> 
> 
> --- src/Synopsis/PTree/operations.cc    (revision 1619)
> 
> @@ -64,10 +66,14 @@
> 
>  bool equal(Node const *p, Node const *q)
>  {
> -  if(p == q) return true;
> -  else if(p == 0 || q == 0) return false;
> +  // segg: even if both are null ?? eh eh
> +  if(p == 0 || q == 0) return false;
> +  else if(p == q) return true;

Why shouldn't they compare to 'true' if both are 0 ?
Imagine this to be part of a simple-declaration, such as
'class Foo {...};'. The declarator-list will be 0, and
so 'equal' for the declaration can be implemented in terms
of its children.


>    else if(p->is_atom() || q->is_atom()) return *p == *q;
> -  else return equal(p->car(), q->car()) && equal(p->cdr(), q->cdr());
> +  else return equal(static_cast<const List *>(p)->car(),
> +                    static_cast<const List *>(q)->car())
> +           && equal(static_cast<const List *>(p)->cdr(),
> +                    static_cast<const List *>(q)->cdr());
>  }
> 
>  /*
> 
> have a good day
> gilles
> 
> the others lines are because i have push down to subclass car(), cdr(),
> position() and length() from the Node class.

Well, this whole PTree API needs some more thought, I'm sure.
Right now I'm trying to put more accessors into the concrete node
classes, hoping that PTree visitors don't need to use the car/cdr
any more. I'm not sure yet how all this will work out.

Thanks,
		Stefan