[PD] Multi dimensional [list]

[Mathieu Bouchard]

On Tue, 2 Jan 2007, Martin Peach wrote:
> Mathieu Bouchard wrote:
>
>> but A_LIST can't work because the name "list" is already taken for a type 
>> of non-atom message. (an atom message is one carries exactly one atom which 
>> is always supposed to be of the type indicated by the selector)
>
> A list is just a bunch of atoms laid out contiguously in memory: I guess 
> that makes it a molecular message? ;)

That's the paradox. If a list is to be just a bunch of atoms, and you 
don't want to complicate the definition, but you want to support nested 
lists in a proper way, then you have to accept that an atom may be a list 
(or may represent a list via some kind of pointer, which amounts to the 
same...)

> What about extending the pointer type so that it can point to any kind 
> of atom, including a list of atoms?

That may be a good idea. I have the following questions about it:

1. What do you do with the fact that an A_POINTER atom points to a 
t_gpointer which points to a t_gstub ? Isn't that too much indirection for 
just a list? (The t_gstub may be skipped, but it's required in order to 
know whether we really are pointing to atoms!)

2. What do you do with types of pointees? gpointers are expected to be 
either pointer-to-array-element or pointer-to-scalar-in-glist (where glist 
is supposed to be canvas nowadays, but is still called glist in the 
source, even DesireData's). The assumption made by pointer-using patches 
is that if one has a pointer that is not null, then it points to a struct. 
Do you break the assumption that a pointer points to a struct, or do you 
introduce a way of looking at an atom as if it were a struct?

3. Even though the gpointer type for scalars is GP_GLIST (meaning 
"canvas"), the type of the corresponding fielddesc is DT_LIST, and the 
associated typename is the symbol "list"... what should be done about it?

4. I'm really going to introduce plain refcounts already for another 
reason, and I think that it would be important to not tie those new lists 
to a specific canvas, I want them to fly around in a carefree manner; 
therefore, should the list atoms be distinct from t_gpointer stuff, or
should t_gpointer (as we know it) die? I'm open to either, really, and 
it's possible that both would happen - it needs not be either/or.

And also, here's a plan for making t_gpointer die:

1. Move gs_refcount to t_array and t_canvas.

2. add a t_pd header to t_array so that it can be recognised by its 
t_class*.

3. Remove gs_which because we can already figure it out: if (!gs_un) then 
it's a GP_NONE, else we check whether *(t_pd*)gs_un == t_array_class to 
figure out whether it's GP_ARRAY or GP_LIST.

4. nuke gp_valid, a_valid and gl_valid, because if they ever are useful, 
they'll cause spurious warnings from valgrind, and because there are 
better ways of taking care of stale pointers. Note that the currently 
implemented gp_valid doesn't even work, because a_valid isn't cleared when 
freeing the t_array, so a matching a_valid is not a guarantee of whatever. 
I'd rather have pointers never go stale, by making deallocation completely 
automatic (refcounts and nothing else).

5. nuke t_gstub completely, by replacing gp_stub by gs_un.

6. at this point, the only remaining things are the element pointer 
(gp_un) and the container pointer (gp_stub aka gs_un). If the unused 
portion of a_type is recycled (only compatible if no externals check for 
A_POINTER) then we could make it hold the index, but in the case of 
GP_LIST this wouldn't be efficient until t_glist stops holding its 
elements as a linked-list. If it does become efficient, then a_type may 
hold the gpointer index, and so t_gpointer will only need to store 
gp_stub, so t_gpointer can be nuked completely, by replacing w_pointer by 
gp_un.

Does that look good? (I admit that step 6 is more difficult, but I expect 
that DesireData's t_canvas/t_gobj will stop using linked-lists pretty soon 
- they're getting too cumbersome to use, for some of the upcoming 
features).

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada