[plt-scheme] prefab structure types (3.99.0.18)

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Fri Mar 14 13:21:44 EDT 2008

At Fri, 14 Mar 2008 10:14:04 -0700, "Jay McCarthy" wrote:
> What about sharing and space issues?

Marshaled data might be bigger or smaller. I think it probably depends
on the details of the structure type, including how many layers of
supertypes are involved. Support for sharing should be the same, though
you'd have to explicitly set `(print-graph #t)' to preserve all sharing
(of there are no cycles).

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

Prefab structures are represented and implemented the same way as other
structures, so the field-access cost, etc., is exactly the same.

> 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.

If you don't need the stronger abstraction that you get from
`define-serializable-struct', then my guess is that you'll win with
prefab structure types. It's difficult to be certain, though.

Matthew

> 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


Posted on the users mailing list.