> I should now be able to say that monsToPol and
> polToMons should behave as id fo ``list'' polynomials
> thereby simplifying redPol to tail for list polynomials.
Yes, that's the idea. Ditto the rest. I think a major
application might be to specifying a useful (but, to the compiler,
unprovable) transformation algebra for abstract data types with
complex implementations.
Simon
>
> Also (if I am understanding this correctly) I should now
> be able to state that
> monsToPol . polToMons = id
> polToMons . monsToPol = id
> which should be useful for compositions of functions: e.g. in
> the (contrived) example:
> incrementPol.incrementPol
> which is basically
> monsToPol . standardIncrement .
> polToMons . monsToPol .
> standardIncrement . polToMons
> i.e.
> monsToPol . standardIncrement .
> standardIncrement . polToMons
> this could eliminate a lot of overhead for polynomial representations
> which are very different from lists (e.g. binary heap like
> representations)
>
> I think I should be able to find more usefull applications.
>
>
> Regards,
>
>
> Marc
>
