Sorry, but this won't work for hayat: it uses cdisrep (alias rcdisrep) to
disrep genvars (which it passes around, and it needs to do so)
unfortunately, cdisrep uses the 'disrep property ...
(or did you mean to change cdisrep?)
Martin
On Sun, 9 Feb 2003, Richard Fateman wrote:
> The scope of symbols is global. The bindings of
> genvar and varlist have limited scope.
what does this imply?
>
> I suggest that all uses of the disrep property be eliminated
> (except POSSIBLY within pdisrep when it is supportable as
> an efficiency hack.)
>
> Instead of (get foo 'disrep)
>
> use (elt genvars (position foo varlist)) ; or some variant of that.
>
>
> If these are not equivalent, then I think there is a bug.
>
> RJF
>
>
>
>
> Martin RUBEY wrote:
> > It seems that there are 2 1/2 solutions to the varlist/genvar problem:
> >
> > 1. Solution
> >
> > protect all calls of those programs that use the genvars to communicate
> > internally to *any* exterior program. -- I realised that we would have to
> > protect all these calls because we cannot know whether the exterior
> > program will use rat or friends some time in the future.
> >
> > 2. Solution
> >
> > Of course, this can also done in the programs which are called, i.e.
> > progbind varlist and genvar at all "entrypoints" to programs that use $rat
> > or friends.
> >
> > This is the approach that you took when suggesting to progbind varlist and
> > genvar in fpolysum.
> >
> > 2 1/2. Solution (well, not really a solution, this leads the idea of
> > genvars ad absurdum)
> >
> > change rat and friends so that either the DISREP property agrees with
> > the varlist or a new symbol is created...
> >
> >
> > Because this has to be done systematically, I would like to have an answer
> > like "1" or "2" or "depends on ... "
> >
> > Thanks, Martin
> >
> > _______________________________________________
> > Maxima mailing list
> > Maxima@www.math.utexas.edu
> > http://www.math.utexas.edu/mailman/listinfo/maxima
>
>
>