[mercury-users] Deconstruct/construct existential types

[Zoltan Somogyi]

On 24-Nov-2006, Peter Ross <pro at missioncriticalit.com> wrote:
> I've just written some code which serializes and de-serializes a
> generic mercury type, however this code doesn't work with existential
> types and we should be able to support that.
> 
> Does anyone have any ideas about how to do this?  From my inspection
> of the code, I can't see any way to do it generically without adding
> more RTTI support.

Suppose you are looking at an existentially typed argument, which has to be
prefaced in the serialized form by a description of its actual type. There
are two possibilities.

1 The actual type contains type constructors that do not occur in the program
  doing the reading. What do you do?

  - You can have the reading process fail, by returning "no" in a maybe type
    or throwing an exception.

  - You can have the serialized form contain a definition of the type
    constructor, and make the read-in process add the RTTI structures of the
    type constructor to the running process. In this case, what happens if
    later you read in another type constructor with the same name, possibly
    from  a different source? The only sane solution seems to be to rename
    every such type constructor, giving them a unique name from a reserved
    part of the name space, even though this means (a) lots of data structure
    duplication, and (b) an inability to usefully test whether two such
    arguments have semantically the same type (as opposed to isomorphic types).

2 All type constructors in the type *do* occur in the program doing the
  reading. However, what happens if some of them assume a different definition
  in the two places (program and data)? This can happen if e.g. the data was
  created by an earlier version of the program, e.g. before the addition of
  a field to a function symbol. Again, you can deal with such problems by
  making the read fail or by renaming all type constructors.

Which solution are you after? The first one (fail unless all type constructors
are known and have the same definition as in the program) is relatively easy
to implement (2-5 days). The second (include the definitions of all type
constructors used in existentially typed arguments in the serialized form,
and add renamed versions of these definitions to the running program) is
significantly harder.

Zoltan.
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------