Dear Gaby,
thanks for looking into this!
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> I spent some time thinking about this issue, pondering pros and cons, looking
> at the compiler code. My conclusion is that the existing behaviour was a
> deliberate design choice to mimic `forgetful functors'. E.g., once one
> decides to reuse a domain to (partially) implement exported operations, all
> relevant operations are taken from there, The only way to get the `object
> oriented' feature of virtual functions (or non-static methods, Java parlance)
> is to use defaults in categories. This is not well (if at all!) explained in
> the Axiom Book.
Yes, I think that's exactly what Ralf said. It makes me happy in fact.
> 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.
Now, that all of us seem to agree, I think we really should try to implement
the optimization, i.e., inline functions from the same domain.
| minRowIndex m == mnRow
| minColIndex m == mnCol
|
| qelt(m,i,j) ==
| qelt(qelt(m,i - minRowIndex m)$Rep,j - minColIndex m)
should compile to
(DEFUN |IIARRAY2;qelt;$2IR;10| (|m| |i| |j| $)
(ELT (ELT |m| (- |i| (|IIARRAY2;minRowIndex;$I;4| |m| $)))
(- |j| (|IIARRAY2;minColIndex;$I;5| |m| $))))
instead of
(DEFUN |IIARRAY2;qelt;$2IR;10| (|m| |i| |j| $)
(ELT (ELT |m| (- |i| (SPADCALL |m| (QREFELT $ 24))))
(- |j| (SPADCALL |m| (QREFELT $ 25)))))
The main problem -- as far as I can see -- is that in the current compilation
process, the precise function name, eg. |IIARRAY2;minRowIndex;$I;4| is only
known after the function (in this case: minRowIndex) has been compiled. Since
it might happen (in the case at hand it doesn't, but that's a coincidence) that
|IIARRAY2;qelt;$2IR;10| is compiled before |IIARRAY2;minRowIndex;$I;4|, we
cannot do the inlining in the first pass, without modifying the compile process
so as to determine all function names before compilation.
It might be relatively easy to do the inlining in a second pass, if we can get
hold of the infovec then: for domains and packages, in every function look for
the pattern
(spadcall arg1 arg2 ... (qrefelt $ nn)),
look up item nn in the infovec, if it's an atom XXX, replace
(spadcall arg1 arg2 ... (qrefelt $ nn))
with
(XXX arg1 arg2 ... $)
A similar thing should probably done for spadconst.
There is an argument for redoing the compilation process, however: I guess (!)
that it would enable us (psychologically, not technically!) at the same moment
to allow overloading of local functions, which would be very nice. (I hurry to
stress that I believe that the two items are independent, I only think that
redoing the way compilation is done may give enough energy to clean up these
issues.)
Finally, another question: the code in comp.lisp looks really hard to
understand for me, although I admit that I didn't really try. Wouldn't it be
better to do away with it and produce ANSI Common Lisp in the code.lsp? Or did
I misunderstand something here? Is comp.lisp another optimization pass?
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
