Hi Antonio Antonio Cuni wrote:

I've spent last hours reading sources in the rpython directory, trying to deeper understand how lltypesystem and ootypesystem work: I've noticed that the low level representations of strings and lists are the same in both typesystem.

My question is: is it a design choice or nobody has not refactored that part, yet?

Nobody has refactored this, yet. I ported rtuple to the ootypesystem last week. But I took a very simple approach, representing different types of tuples with classes. Basically, if your backend supports classes, it will automatically support tuples, too.

I think that if a target natively supports classes and other object oriented constructs probably it supports strings and sequences, too, so we should try to use these facilities as much as possible.

Yes, for strings, lists and dicts you want to use the facilities of the host language as much as possible. This is different from the approach I used for tuples. I had some discussion with Samuele about this, but I'm still hazy about how we should signal to the backend, that e.g. an RPython list should be replaced with a native list. Maybe Samuele can share his ideas here. Otherwise, we'll talk about it at the Leysin sprint (I'll be there on Sunday) and I'll report the results here.

I don't remember which people are working on ootypesystem, but if they agree I could try to refactory such things.

You are very welcome to work on this! Go ahead, people will complain if you break something. ;) But for these kinds of invasive refactorings, be sure to run the whole PyPy test suite and maybe even translation before commits.

If I have understood the source well I should begin by adding 'rlist' and 'rstr' to the list of lazily imported modules in rpython.typesystem.TypeSystem, shouldn't I?

Correct. But the next step after that is not clear to me at this point. But maybe you can figure something out, I don't have time to think about it right now. Cheers Nik

Hi Antonio Antonio Cuni wrote:

I've spent last hours reading sources in the rpython directory, trying to deeper understand how lltypesystem and ootypesystem work: I've noticed that the low level representations of strings and lists are the same in both typesystem.

My question is: is it a design choice or nobody has not refactored that part, yet?

Nobody has refactored this, yet. I ported rtuple to the ootypesystem last week. But I took a very simple approach, representing different types of tuples with classes. Basically, if your backend supports classes, it will automatically support tuples, too.

I think that if a target natively supports classes and other object oriented constructs probably it supports strings and sequences, too, so we should try to use these facilities as much as possible.

Yes, for strings, lists and dicts you want to use the facilities of the host language as much as possible. This is different from the approach I used for tuples. I had some discussion with Samuele about this, but I'm still hazy about how we should signal to the backend, that e.g. an RPython list should be replaced with a native list. Maybe Samuele can share his ideas here. Otherwise, we'll talk about it at the Leysin sprint (I'll be there on Sunday) and I'll report the results here.

I don't remember which people are working on ootypesystem, but if they agree I could try to refactory such things.

You are very welcome to work on this! Go ahead, people will complain if you break something. ;) But for these kinds of invasive refactorings, be sure to run the whole PyPy test suite and maybe even translation before commits.

If I have understood the source well I should begin by adding 'rlist' and 'rstr' to the list of lazily imported modules in rpython.typesystem.TypeSystem, shouldn't I?

Correct. But the next step after that is not clear to me at this point. But maybe you can figure something out, I don't have time to think about it right now. Cheers Nik