This is the mail archive of the guile@cygnus.com mailing list for the guile project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
On Wed, 21 Oct 1998 21:13:54 mike@olan.com (Michael N. Livshin) wrote: > *** Bits 1 and 3 of the tag denote the vector storage/access model. > > 00 - managed > 01 - freed > 10 - indirect > 11 - indirect read-only > > *** Bits 4 and 5 denote the type. > > 01 - chars (for strings) > 10 - SCM (regular Scheme vectors) > 11 - explicit type (for all the rest, more on this later). > > *** Summary of changed tags. > > Current Proposed Notes > -------------------------------------------------------------------------- [...] > 0100101 - uvect 010x1x1 - SCM vectors > 0100111 - lvector | > 0101101 - fvect | > 0101111 - dvect | Maybe that's a stupid question, but why should there be any non-managed SCM vector? I can understand having the indirect flags for strings: strings from user space can be used witout need for duplicating them. In this case, additional conversion functions (in addition to str2scm and str02scm) would be required. Looks like a sensible thing to have. > 0110101 - cvect 011x1x1 - typed vectors All the rest. > 0110111 - svect | > 0111101 - contin | > 0111111 - cclo | Why not have the managed/freed/indirect/indirect-read-only flag put into the scm_contained_type_info struct? This would mean that there is only _1_ type tag left for uniform vectors. In this case we had: 4 tags for strings: managed/freed/indirect/indirect-read-only 1 tag for SCM vectors: managed 1 tag for uniform vectors: flag contained in scm_contained_type_info struct The system suggested by Michael is more uniform, but I don't know where in the guile code this uniformity would bring much benefit, since the actual handling of strings, SCM vectors and uniform vectors would be quite different anyway. One could even go further and put the less-likely string types into one of the uniform-vectors category, thus potentially needing only 3 tags. > Please feel free to critique this to little pieces. You asked me to ... :-) Otherwise, I think the proposal is definitely a step in the right direction due to the potential to share code between the different uniform vector types and flexibility. Best regards, Dirk Herrmann