[EMAIL PROTECTED] (Ludovic Courtès) writes: > > I propose the following simple fix. Ok to apply?
Yep, looks good. After I posted I wondered if the values struct is an actual "s" or if there's some strange extra I couldn't spot. Testing eq avoids worrying about that. Dunno why values are a struct and not a smob cell. > Actually, `scm_i_struct_equalp ()' should also compare the "tail > elements" (when there are tail elements), Yes. > but their semantics are a > little fuzzy to me. In particular, I don't understand why the size of > the tail array can be specified in both `make-vtable-vtable' and > `make-struct': What does that mean? Which one should really be taken > into account? Dunno :). > It seems that the code is a bit unclear on this too: > > guile> (define v (make-vtable-vtable "pr" 0)) > guile> (define s (make-struct v 123)) > guile> (struct-ref s 10) > Segmentation fault A segv is a bug, obviously, whichever way it's actually meant to be. > (Looks like the API is so complex that few people actually bothered to > use it to its full extents. ;-)) The records level is friendlier I guess. For a long time I couldn't understand what "vtable" meant, I still don't think I quite do. Maybe the docs should be tweaked, to help show what structs are typically meant to be. > --- orig/test-suite/tests/structs.test > +++ mod/test-suite/tests/structs.test > @@ -82,12 +82,18 @@ > (set-owner! ball "Bill") > (string=? (owner ball) "Bill"))) > > - (pass-if "equal?" You can make a with-test-prefix group if you like. An exercise of an actual values too will be good, maybe in eval.test. _______________________________________________ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile