The reference section on "Reading Structures" has more relevant details: http://docs.racket-lang.org/reference/reader.html#%28part._parse-structure%29
-Philip On Tue, Mar 20, 2018 at 6:48 AM, Philip McGrath <phi...@philipmcgrath.com> wrote: > Given your definition of `(struct f (a b) #:prefab #:mutable)`, you will > see that `(equal? (f 1 2) #s(f 1 2))` returns `#false`, because `#s(f 1 2)` > does not evaluate to an instance of your `f` structure type. The printed > form of a structure created with `(f 1 2)` is `'#s((f #(0 1)) 1 2)`. > > Per the reference <http://docs.racket-lang.org/reference/structures.html>, > "Exactly one prefab structure type exists for each combination of name, > supertype, field count, automatic field count, automatic field value (when > there is at least one automatic field), and field mutability." The > expression `#s(f 1 2)` evaluates to an instance of a prefab structure type > named "f" with no mutable fields, which is a distinct structure type from > the mutable variant of "f". > > Again, given your definitions, you will see this with the very helpful > error message for `(set-f-a! #s(f 1 2) 5)`: > set-f-a!: contract violation; > given value instantiates a different structure type with the same name > expected: f? > given: '#s(f 1 2) > > -Philip > > On Tue, Mar 20, 2018 at 6:37 AM, 'Paulo Matos' via Racket Users < > racket-users@googlegroups.com> wrote: > >> >> >> On 20/03/18 11:56, Philip McGrath wrote: >> > Mutable values generally cannot be sent as messages on place channels. >> > ("To a first approximation, place channels support only immutable, >> > transparent values as messages." >> > http://docs.racket-lang.org/reference/places.html The documentation for >> > `place-message-allowed?` is also specific that only "immutable prefab >> > structures containing message-allowed values" are accepted.) >> > >> > The reason for this restriction becomes clear if we think of places as >> > separate instances of the Racket VM. With Racket threads, mutable values >> > can be shared among all threads running concurrently, so mutation has >> > the expected effect and changes that shared structure. With places, only >> > values explicitly created in the shared memory space (via functions like >> > `shared-bytes`) are shared. An instance of a struct received from a >> > place channel isn't connected to the instance sent from a different >> > place: mutating one wouldn't change the other. With things like vectors >> > and hash tables where Racket has both mutable and immutable variants, >> > place channel operations automatically convert mutable values to >> > immutable ones for convenience, but there is no such substitution for >> > user-defined data types. >> > >> >> I understand all you say but allowing prefab structs to be mutable and >> then creating different behaviours with #s() and through direct >> constructor call is a gotcha I did not expect and my question was >> really, why is this allowed? >> >> What's then the advantage of allowing prefab structs to be marked as >> mutable? >> >> > If you need to send mutable structures across place channels, I would >> > suggest that you first serialize them with racket/serialize, then send >> > the serialized representation across the place channel.> >> >> Yes, that seems to be the alternative, thanks. >> >> > -Philip >> > >> > On Tue, Mar 20, 2018 at 5:39 AM, 'Paulo Matos' via Racket Users >> > <racket-users@googlegroups.com <mailto:racket-users@googlegroups.com>> >> > wrote: >> > >> > Hi, >> > >> > I was quite surprised by a 'feature' of prefab mutable structures: >> > #lang racket >> > >> > (struct f (a b) >> > #:prefab >> > #:mutable) >> > >> > (place-message-allowed? (f 1 2)) >> > (place-message-allowed? #s(f 1 2)) >> > >> > I was expecting both to return true but to my amazement it was not >> the >> > case. The one created with #s(...) returned true while the other >> > returned false. This is surprising because I thought I had read >> > everything about prefabs and never seen this distinction being >> > discussed. >> > >> > Any reasons for this to happen? >> > >> > -- >> > Paulo Matos >> > >> > -- >> > 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 >> > <mailto:racket-users%2bunsubscr...@googlegroups.com>. >> > For more options, visit https://groups.google.com/d/optout >> > <https://groups.google.com/d/optout>. >> > >> > >> > -- >> > 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 >> > <mailto:racket-users+unsubscr...@googlegroups.com>. >> > For more options, visit https://groups.google.com/d/optout. >> >> -- >> Paulo Matos >> >> -- >> 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. >> > > -- 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.
