[Cython] Draft for compile-time calculation inliner

[Gary Furnish]

I think A is quite acceptable (and probably a good idea).  Anytime I
hear "very contrived" in the design phase I get worried, so I don't
like B.  I think C might make a good topic to talk about eventually,
but I think it is far more important to get numpy support in now
(without worrying about optimization at all).  Making C happen will
probably require some design changes in Cython, so it is important in
my book to define a public API to the parse tree and not let plugins
poke around and do whatever they want.

On 3/15/08, Dag Sverre Seljebotn <dagss at student.matnat.uio.no> wrote:
>
>  > Having a full python interperter around to get around the fact that we
>  > don't have decent dependencies is almost certainly not the way to do
>  > this.  My dislike of parse tree optimizations mainly centers around
>  > using it for very complicated things that can be much better served by
>  > other algorithms.
>
>
> I'll admit (as you've probably concluded) that I'm out of my field of
>  knowledge here. Still, seeing that you don't think my hack isn't ideal,
>  what do you think would be the best way forward to get clean NumPy
>  integration in, say, six weeks of full-time work by somebody who has no
>  experience with compilers, but knows programming and text-book algorithms
>  well?
>
>  a) Custom plugin doing custom NumPy rewrites on the parse tree. (Easily
>  done in one week for that matter...)
>  b) Find a (very contrived) declarative syntax instead of Cython function
>  calls for making the kind of code we need
>  c) Just forget it, and start the long route of figuring out dependencies
>  etc. towards a full-fledged optimizing compiler.
>
>  I sort of figured my hack could provide a quick way forward...
>
>  (BTW, reading books on compiler design would be an option.)
>
>
>  Dag Sverre
>
>