Samuele Pedroni wrote:
Armin Rigo wrote:
On Tue, Nov 02, 2004 at 06:09:57PM +0100, Samuele Pedroni wrote:
(...) In Java, lisp etc is not that much a relevant problem because for example Java arrays carry a length anyway and are heap allocated.
Ops, by the way: we can't use a Java array to implement a RPython list because
you can't resize Java arrays. So there is an extra indirection even in Java
and there is a need to remove it with enough analysis and optimizations...
Or am I missing something?
it depends on how you implement things, realloc needs to be expressed as alloc and copy but I don't see what force you to incapsulate the array
in an extra layer object.
oops, sorry now I see, you want RPython lists to be lists, that's probably different that what we wanted originally.
listobject is still written asssuming that ob_item is a chunk of memory (i), but in other parts we are assuming RPython list can be extended and appended to (ii).
(btw question is btw whether resizing policy should be in listobject on in the RPython list sematics.)
With approach 2 we would go from all the fields necesessary from a general list to just len+items for the first case because some thing are constants.
It's still true that both an ad-hoc approach given knowledge about the specific type that exist in RPython, or a general one is possible.
In Java as first approx you would use an array for (i) and ArrayList for (ii)
I still think that a baseline intepreter with straightforward optimizations is a good first goal, also because we can use it as reference to track our progress and see what gives the biggest payoffs.
_______________________________________________
[EMAIL PROTECTED]
http://codespeak.net/mailman/listinfo/pypy-dev
