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.
My feeling is that (in IIARRAY2)
minRowIndex m == mnRow
minColIndex m == mnCol
qelt(m,i,j) ==
qelt(qelt(m,i - minRowIndex m)$Rep,j - minColIndex m)
and
minRowIndex m == mnRow
minColIndex m == mnCol
qelt(m,i,j) ==
qelt(qelt(m,i - mnRow)$Rep,j - mnCol)
should have the same semantics. If we allow virtual functions, and, for
example, I reimplement minRowIndex in Matrix (which adds to IIARRAY2), the two
versions will differ.
> In fact, my view is that once we have produced a Lisp code, we have lost hope
> of getting the code faster.
I disagree, but only slightly: it turned out that optimizing the function calls
away (in SPADCALL) made a *huge* difference.
> Spad is strongly typed. We should not first generate Lisp and then try to
> optimze the Lisp.
Yes. So, this means, when compiling a functor, we should determine the (lisp)
function names of all operations in a first pass. Hm, I forgot whether one can
see in comp3 whether the function call we are compiling is conditional or not.
If the function call is unconditional, we should inline as if it were a local
function...
Ideally, of course, inlining would also happen if we are in the same
conditional branch:
if cond then
op1 xxx == ...
op2 yyy == ... op1 xxx ...
else
op2 yyy == ...
We could safely, inline op1 here, I believe.
It'd be great if you could make some progress there!
Martin
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
open-axiom-devel mailing list
open-axiom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
