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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
