[plt-scheme] prefab structure types (3.99.0.18)

What about sharing and space issues?

Or field accesses? Are prefabs just as fast (vector-ref)?

I'm wondering if I should convert the web language's serializable
closures into prefabs. The current code is quite hairy, so it might be
nice to have a simple "#:prefab", but I don't want to lose too much.

Jay

On Fri, Mar 14, 2008 at 10:05 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> Serialization of prefab structures via `write' and `read' should be
>  faster than sending `define-serializable-struct' instances through
>  `serialize'+`write' and `read'+`deserialize', but I haven't run any
>  benchmarks.
>
>  Matthew
>
>
>
>  At Fri, 14 Mar 2008 09:48:03 -0700, "Jay McCarthy" wrote:
>  > What is the efficiency, etc, relative to define-serializable-struct
>  > and the serialize library?
>  >
>  > Jay
>  >
>  > On Thu, Mar 13, 2008 at 2:08 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
>  > > Version 3.99.0.18 adds "prefab" (i.e., "previously fabricated")
>  > >  structure types for non-abstract, easily serialized structures.
>  > >
>  > >  A prefab structure type is a built-in type that is distinct from all
>  > >  other types, but that `read' and `write' know about. So, you can write
>  > >  a prefab structure as a literal:
>  > >
>  > >   > '#s(sprout bean #t 17)
>  > >   #s(sprout bean #t 17)
>  > >
>  > >  The "#s" notation means "prefab structure", `sprout' is the name of the
>  > >  structure type, and 'bean, #t, and 17 are the values of the structure's
>  > >  fields.
>  > >
>  > >  A prefab structure datum is self-quoting:
>  > >
>  > >   > #s(sprout bean #t 17)
>  > >   #s(sprout bean #t 17)
>  > >
>  > >
>  > >  A prefab structure type is keyed mainly on its symbolic name and field
>  > >  count. So,
>  > >
>  > >   #s(sprout bean)
>  > >
>  > >  is an instance of a different prefab structure type --- also named
>  > >  'sprout, but with a single field instead of three fields.
>  > >
>  > >
>  > >  If you use `define-struct' with the new #:prefab keyword, then instead
>  > >  of generating a new type, it binds to the prefab structure type with
>  > >  the same name and field count:
>  > >
>  > >   > (define s1 #s(sprout bean))
>  > >   > (define-struct sprout (kind) #:prefab)
>  > >   > (sprout? s1)
>  > >   #t
>  > >   > (sprout-kind s1)
>  > >   bean
>  > >   > (sprout-kind #s(sprout alfalfa))
>  > >   alfalfa
>  > >   > (make-sprout 'alfalfa)
>  > >   #s(sprout alfalfa))
>  > >   > (sprout? #s(cat "Garfield"))
>  > >   #f
>  > >   > (sprout? #s(sprout bean #t 17)) ; three fields instead of one
>  > >   #f
>  > >
>  > >
>  > >  A prefab structure type is similar to an R6RS nongenerative record
>  > >  type. One difference is that a generative record type might be defined
>  > >  multiple times in incompatible ways, in which case something has to
>  > >  notice and signal an error. By keying a prefab structure type on all of
>  > >  its attributes, there is no possibility for incompatible definitions,
>  > >  and so no question of when/how an error might be signaled. There's also
>  > >  no need to declare a prefab structure type before it can be recognized
>  > >  by the reader or printer.
>  > >
>  > >
>  > >  If a prefab structure type has a supertype (which must also be a prefab
>  > >  type) or if it has mutable or automatic fields, then the prefab key
>  > >  gets more complex:
>  > >
>  > >   > (define-struct cat (name) #:prefab)
>  > >   > (define-struct (cute-cat cat) ([shipping-dest #:mutable]) #:prefab)
>  > >   > (make-cute-cat "Nermel" "Abu Dahbi")
>  > >   #s((cute-cat #(0) cat 1) "Nermel" "Abu Dahbi")
>  > >
>  > >  The reference manual documents the prefab key format. It's designed to
>  > >  be easy to read and write in simple cases, but complete enough to cover
>  > >  more complicated structure types.
>  > >
>  > >  You're not allowed to write a literal that is mutable, so
>  > >
>  > >   #s((cute-cat #(0) cat 1) "Nermel" "Abu Dahbi")
>  > >
>  > >  is not a valid expression. Nevertheless, `read' can parse it and
>  > >  create a mutable instance, in much the same way that `read' can
>  > >  produce a mutable vector.
>  > >
>  > >
>  > >  Every prefab structure type is transparent --- but even less abstract
>  > >  than a transparent type, because instances can be created without any
>  > >  access to a particular structure-type declaration or existing examples.
>  > >  Overall, the different options for structure types offer a spectrum of
>  > >  possibilities from more abstract to more convenient:
>  > >
>  > >   * Opaque (the default) : Instances cannot be inspected or forged
>  > >        without access to the structure-type declaration. Constructor
>  > >        guards and properties can be attached to the structure type to
>  > >        further protect or to specialize the behavior of its instances.
>  > >
>  > >   * Transparent : Anyone can inspect or create an instance without
>  > >        access to the structure-type declaration, which means that the
>  > >        value printer can show the content of an instance. All instance
>  > >        creation passes through a constructor guard, however, so that
>  > >        the content of an instance can be controlled, and the behavior
>  > >        of instances can be specialized through properties. Since the
>  > >        structure type is generated by its definition, instances cannot
>  > >        be manufactured simply through the name of the structure type,
>  > >        and therefore cannot be generated automatically by the
>  > >        expression reader.
>  > >
>  > >   * Prefab : Anyone can inspect or create an instance at any time,
>  > >        without prior access to a structure-type declaration or an
>  > >        example instance. Consequently, the expression reader can
>  > >        manufacture instances directly. The instance cannot have a
>  > >        constructor guard or properties.
>  > >
>  > >  Since the expression reader can generate prefab instances, they are
>  > >  useful when convenient serialization is more important than
>  > >  abstraction. The `define-serializable-struct' form is still available
>  > >  to support serialization of opaque and transparent structures.
>  > >
>  > >
>  > >  Assuming that prefab structures turn out to be a good idea, it will
>  > >  probably take a little while for us to get prefab support everywhere
>  > >  you'd like, such as in `match'. The `quasiquote' form, syntax patterns,
>  > >  and syntax templates already support them.
>  > >
>  > >
>  > >  After next build, you can find more information here:
>  > >
>  > >   http://docs.plt-scheme.org/guide/define-struct.html
>  > >   http://docs.plt-scheme.org/reference/structures.html
>  > >
>  > >  but I've copied or paraphrased above much of the guide material.
>  > >
>  > >
>  > >  Matthew
>  > >
>  > >  _________________________________________________
>  > >   For list-related administrative tasks:
>  > >   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>  > >
>  >
>  >
>  >
>  > --
>  > Jay McCarthy <jay.mccarthy at gmail.com>
>  > http://jay.teammccarthy.org
>  > _________________________________________________
>  >   For list-related administrative tasks:
>  >   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>



-- 
Jay McCarthy <jay.mccarthy at gmail.com>
http://jay.teammccarthy.org