On Mon, Apr 21, 2008 at 5:11 AM, Martin Rubey <[EMAIL PROTECTED]> wrote: > Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > >> Martin Rubey <[EMAIL PROTECTED]> writes: >> >> >> [...] >> >> | > I can see how this can be limiting in some cases, but I suspect it makes >> an >> | > interesting language design choice. A fundamental question (to me) is: >> | > beside optimizations such as the one you want, is there any programming >> | > technique that benefit a lot from that? >> | >> | Hm? This behaviour -- as currently implemented and as explained by >> yourself >> | and Ralf -- actually *allows* the optimization. No, I do not want other >> | behaviour. I was just trying to say that I could live with both ways. >> >> I suspect I did not explain myself clearly. >> >> I acknowledge the current implementation allows the transformation. >> The debate over the last couple of weeks was whether it was intended >> or whether it was a desirable behaviour. >> >> The question I'm asking now is: Beside the optimization (which I'm not >> dismissing), are there any programming techniques (or classes of >> algorithms) that benefit from that choice (as opposed to having >> virtual functions)? I'm curious. > > OK, sorry about my misunderstanding. No, as far as I can see, it really > doesn't matter much which way one goes. Waldek listed some possible > advantages > if one goes the other way, but I doubt they outweigh the cons. I tend to > believe it is cleaner to have a parent category from which one inherits, > rather > than taking an existing domain and overriding the parts one doesn't like.
I have been considering implementing the optimization based on this semantics, until this afternoon where I wasted two hours because of this (too subtle to my taste) semantics. The problem I had is that I wanted to use a LeftFreeModule, but only a FreeModule is available. So I decided to cook one. That should be easy. In addition, the lack of facility to specify `coordinates' was really very annoying. I wrote (simplifying) )abbrev domain LFREEMOD LeftFreeModule LeftFreeModule(R: Ring, S: OrderedSet): Join(LeftModule R, IndexedDirectProductCategory(R,S)) with linearCombination: List Pair(R,S) -> % == IndexedDirectProductAbelianGroup(R,S) add Rep == List Pair(R,S) linearCombination x == per [u for u in x | first u ~= 0$R] if R has EntireRing then (r: R) * (x: %) == r = 0$R => 0$% r = 1$R => x per [pair(r * first u, second u) for u in rep x] else (r: R) * (x: %) == r = 0$R => 0$% r = 1$R => x per [pair(c, second u) for u in rep x | (c := r *first u) ~= 0$R] coerce(x: %): OutputForm == x' := rep x null x' => 0$R :: OutputForm res : List OutputForm := nil for u in reverse x' repeat first u = 1$R => res := cons(second(u)::OutputForm, res) res := cons(first(u)::OutputForm * second(u)::OutputForm, res) reduce("+",res) Testing revealed that I was getting system errors, and I could not spot the error from the (short code). Until I realized just a few minutes ago that my `*' was not being picked if I test with R=Integer. Rather the one from IndexedDirectProductAbelianMonoid was being used, yet my coerce to OutputForm was used for printing => return disaster. This semantics is too subtle. One needs to be aware of all possible cases where an operation might be subsumed by the parents domains for particular instantiations, all implementation details of the parents domains, and so on. That isn't good. At least, I'm less enthusiastic about it. Of course, changing it means that one also needs to audit the entire library to see where semantics might differ. -- Gaby ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ open-axiom-devel mailing list open-axiom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-axiom-devel