prefab structs in guile

prefab structs in guile

[Andy Wingo]

Hi,

We should think about supporting prefab structs in Guile.  For more
details, see:

  http://docs.racket-lang.org/guide/define-struct.html?q=prefab#%28part._prefab-struct%29
  http://docs.racket-lang.org/reference/structures.html?q=record&q=structs&q=records#(tech._prefab)

The reason is that sometimes you want to allow structures to be
serialized (to Scheme or into object code) and read back in.  See bug
11198 for an example.

I don't have time for this currently, but here's one plan on how you
would do it.

  You would create a new Scheme module, (ice-9 prefab) or
something.  It would contain a map from (name, number of fields) ->
record type descriptor.  (We don't have #:mutable, #:auto, or
supertypes; these would be separate projects.)

  Then you would modify the reader to call out to (ice-9 prefab) with
the list after #s, e.g. the (foo ...) in #s(foo ...).  (ice-9 prefab)
would return the record, creating the RTD if needed.

  You also modify the printer.

  You also modify SRFI-9's define-record-type to recognize #:prefab, or
some other name.

  You also add code to the glil->assembly compiler to recognize prefab
structs, and you add an opcode to look up a prefab struct RTD.

I think that would be it.

Anyone interested?

Andy
-- 
http://wingolog.org/

Re: bug#11198: prefab structs in guile

[Thien-Thi Nguyen]

() Andy Wingo <wingo@pobox.com>
() Thu, 05 Jul 2012 10:00:17 +0200

   For more details, see:

     [...]

See also (info "(elisp) Byte Packing")
which describes Emacs' bindat.el.

The context there is network protocols,
but the design requirements are the same.

Re: bug#11198: prefab structs in guile

[Andy Wingo]

On Thu 05 Jul 2012 15:42, Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> See also (info "(elisp) Byte Packing")
> which describes Emacs' bindat.el.
>
> The context there is network protocols,
> but the design requirements are the same.

Interesting.  The use cases are a bit different though; much of bindat
seems to be covered by bytevectors, whereas prefab "structs" (really,
records) can contain arbitrary Scheme data -- symbols, strings, arrays,
etc.

Andy
-- 
http://wingolog.org/

Re: bug#11198: prefab structs in guile

[Ludovic Courtès]

Hello,

Andy Wingo <wingo@pobox.com> skribis:

>   Then you would modify the reader to call out to (ice-9 prefab) with
> the list after #s, e.g. the (foo ...) in #s(foo ...).  (ice-9 prefab)
> would return the record, creating the RTD if needed.

The problem with this is that one could precisely forge instances of a
given record type, thereby breaking the type safety we currently have
(each instance of a record type is genuine, in the sense of Rees’ “A
Security kernel Based on the Lambda-Calculus”.)

Does Racket address this somehow?

Thanks,
Ludo’.

Re: bug#11198: prefab structs in guile

[Andy Wingo]

On Thu 05 Jul 2012 22:57, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> skribis:
>
>>   Then you would modify the reader to call out to (ice-9 prefab) with
>> the list after #s, e.g. the (foo ...) in #s(foo ...).  (ice-9 prefab)
>> would return the record, creating the RTD if needed.
>
> The problem with this is that one could precisely forge instances of a
> given record type, thereby breaking the type safety we currently have
> (each instance of a record type is genuine, in the sense of Rees’ “A
> Security kernel Based on the Lambda-Calculus”.)
>
> Does Racket address this somehow?

See:

  http://docs.racket-lang.org/guide/define-struct.html?q=record&q=structs&q=records#(part._prefab-struct)

Specifically:

  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. As discussed in the next
    section, 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. Opaque and transparent structures also can be serialized,
  however, if they are defined with define-serializable-struct as
  described in Datatypes and Serialization.

Andy
-- 
http://wingolog.org/

Re: bug#11198: prefab structs in guile

[Ludovic Courtès]

Hi,

Andy Wingo <wingo@pobox.com> skribis:

>   Since the expression reader can generate prefab instances, they are
>   useful when convenient serialization is more important than
>   abstraction. Opaque and transparent structures also can be serialized,
>   however, if they are defined with define-serializable-struct as
>   described in Datatypes and Serialization.

So I’d be in the ‘define-serializable-struct’ camp, so to speak.

Prefabs raise an number of interesting issues.  For instance, what’s the
meaning of #s(sprout bean #f 17) in a module where ‘sprout’ is unbound?
In a module where it’s bound to a given RTD vs. in a module where it’s
bound to a different RTD?  Does ‘read’ have to be current-module-aware?
Etc.

This example is a bit scary to me:

    > (define lunch '#s(sprout bean))
                                     
    > (struct sprout (kind) #:prefab)
                                     
    > (sprout? lunch)                
    #t                               

since it implies that types are compared by name.

Thanks,
Ludo’.

Re: bug#11198: prefab structs in guile

[Andy Wingo]

On Thu 05 Jul 2012 23:55, ludo@gnu.org (Ludovic Courtès) writes:

> So I’d be in the ‘define-serializable-struct’ camp, so to speak.

That's a valid position to have in general.  I can also imagine cases in
which you would choose other things.  It's a spectrum.

> Prefabs raise an number of interesting issues.  For instance, what’s the
> meaning of #s(sprout bean #f 17) in a module where ‘sprout’ is unbound?

Prefab structs are not modular.  It is the same as in a module where
`sprout' is bound.  Reading #s(sprout bean #f 17) may create an RTD if
needed, but it does not create any bindings.

> types are compared by name.

As the documentation clearly indicates :), prefab structs are indeed
compared by name, though in a combination with other characteristics
(number of fields, and more characteristics for racket).

Andy
-- 
http://wingolog.org/

Re: bug#11198: prefab structs in guile

[Andy Wingo]

On Thu 05 Jul 2012 23:55, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> skribis:
>
>>   Since the expression reader can generate prefab instances, they are
>>   useful when convenient serialization is more important than
>>   abstraction. Opaque and transparent structures also can be serialized,
>>   however, if they are defined with define-serializable-struct as
>>   described in Datatypes and Serialization.
>
> So I’d be in the ‘define-serializable-struct’ camp, so to speak.

To be clear: in Racket, serializable structs are not readable.  That's
the whole point of prefab structs: a struct that is readable.

Andy
-- 
http://wingolog.org/

Re: bug#11198: prefab structs in guile

[Ludovic Courtès]

Hi,

Andy Wingo <wingo@pobox.com> skribis:

> On Thu 05 Jul 2012 23:55, ludo@gnu.org (Ludovic Courtès) writes:
>
>> So I’d be in the ‘define-serializable-struct’ camp, so to speak.
>
> That's a valid position to have in general.  I can also imagine cases in
> which you would choose other things.  It's a spectrum.

Yes, sure.  It can be convenient to have something that makes it easy to
serialize structs.  But given that prefabs have to be “built in”, and
that they look can-of-wormey to my demanding eye ;-), I’d be in favor of
anything built atop structs.

And actually, there’s (oop goops save), which is extensible and
everything.  :-)

Side note: while writing readers/writers by hand may look tedious, the
advantage is that it makes it easy to leave room for future extensions,
like allowing the reader to suitably map an old version of a serialized
struct to the new data structure.

>> Prefabs raise an number of interesting issues.  For instance, what’s the
>> meaning of #s(sprout bean #f 17) in a module where ‘sprout’ is unbound?
>
> Prefab structs are not modular.  It is the same as in a module where
> `sprout' is bound.  Reading #s(sprout bean #f 17) may create an RTD if
> needed, but it does not create any bindings.

OK.  So there can only be one ‘sprout’ prefab RTD in the whole process,
I guess.

>> types are compared by name.
>
> As the documentation clearly indicates :), prefab structs are indeed
> compared by name, though in a combination with other characteristics
> (number of fields, and more characteristics for racket).

Right.  Argh.

Thanks,
Ludo’.