> On Mar 26, 2018, at 11:03 AM, Eric Griffis <ded...@gmail.com> wrote: > > The `struct` form is defined in `struct.rkt` [1]. As you can see, `struct` > wraps `define-struct/derived` [2], which uses many things exported from > `struct.c` [3]. The "Inside: Racket C API" doc [5] describes some of these > functions -- see section 16. > > On the matter of structs being essentially vectors: Again in `struct.c` [3], > the C function `scheme_make_struct_instance` (line 2388) instantiates a > `Scheme_Structure`, which is declared in `schpriv.h` [4], line 1113. The > field values go into a `slots` array, which points directly to the > `Scheme_Object`s (i.e. arbitrary Racket values) supplied to > `scheme_make_struct_instance`. Assuming Racket vectors are essentially C > arrays, Racket structs are like vectors in this way. > > Looking at `Scheme_Struct_Type`, defined just above `Scheme_Structure` in > `schpriv.h` [4], it's clear there's nowhere to store field names. We can > confirm this by looking at `_make_struct_type` in `struct.c` [3], starting at > line 4778, as this is the function used (indirectly) by > `define-struct/derived`. > > Eric
Thanks, Eric! So maybe the solution for that would not be rewriting the struct definition altogether, but providing that additional information in something equivalent to a le over lambda, which would contain that meta information? I ran into an issue that felt similar to this when I was trying to pass method names around in Racket objects. I’ve no idea, but I would think the “solution” to both issues would be similar. Admittedly, I’ve not dug down into either structs or objects deep enough. Kevin -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
