<self-plug> The struct-plus-plus module also provides reflection, so you might take a look to see if there are any ideas in there that would be useful for your own module. Accessors are included, as are constructors, rules, wrappers, default values, and predicates. spp has two primary limitations: You cannot use a base type and you cannot mark individual fields mutable, only the entire struct.
https://docs.racket-lang.org/struct-plus-plus/index.html#%28part._.Reflection%29 </self-plug> On Sun, Dec 20, 2020 at 3:34 PM Dominik Pantůček < dominik.pantu...@trustica.cz> wrote: > Hello Racketeers, > > there were some discussions about structs' introspection on the IRC > lately and one of the questions that arose was how to get field index > for arbitrary struct's arbitrary field. > > Not that it is possible... But the general discussion made me think > about why there are no unsafe variants for structs' accessors and mutators. > > And given my work on some performance-demanding projects I started > testing unsafe-struct*-ref and unsafe-struct*-set! in one of my > simulations (yes, that raycasting/raytracing project). It bumped the > speed from roughly 110-120 fps to about 140-150 fps on my laptop. So > definitely worth the try. > > But unsafe-struct*-ref/set! degrade structs basically to strange > vectors. And also - in my code I use struct hierarchy to decide what to > do with different kinds of data. > > It didn't take long and my unsafe-struct[1] proof-of-concept was created. > > The code is still a bit messy. However it keeps all the semantics of > structs and enables usage of unsafe accessors and mutators without any > hassle. Basically the unsafe-struct and unsafe-struct-out are drop-in > replacements or struct and struct-out. > > A typical usage would be: > > (unsafe-struct my-struct (a b (c #:mutable)) #:transparent) > (define my-val (my-struct 1 2 3)) > (unsafe-set-my-struct-a! my-val 4) > (displayln (unsafe-my-struct-b my-val)) > > Of course, the procedures are inherently unsafe ... > > In a typical scenario I am using these immediately after checking the > type of given value using the struct predicate (like my-struct? in this > case) and getting the performance boost without any real un-safety. > > And now some questions (I bet you knew I will have some): > > 1) Is there anyone else reading this that could actually leverage these > unsafe-structs for something useful? > > 2) If yes, what do you miss there before I create a package from the > code? (Yes, scribblings, yes, slightly cleaning the code up - but what > else?) > > 3) In the syntax pattern I was unable to create a sub-pattern to get the > field-mutable for all fields (including those without any field options) > - that's the reason for most of the long let* later on. Is there a > better way? (I will think about this one, but more eyes ...) > > > Cheers, > Dominik > > P.S.: I didn't abandon the flalgebra module, I am actually working on > another approach that should move the resulting "DSL" closer to the > flonums unboxing and register allocation code. More on that later. > > > [1] https://gitlab.com/racketeer/unsafe-struct > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/90b3e86a-db1d-c658-111b-ae4010c5bea2%40trustica.cz > . > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAE8gKoeJHs9Pg%3DvMn%2BzP9V-1CEdv0kU26A7sRMa1E0mV3E0eLQ%40mail.gmail.com.
