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

Reply via email to