[mercury-users] Deconstruct/construct existential types

[Peter Ross]

On 11/24/06, Zoltan Somogyi <zs at csse.unimelb.edu.au> wrote:
> 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.
>
This is the solution that I imagined and is what we do now with our
hand-written de-serialization code.

>   - 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).
>
I can't imagine a situation where we would need this behaviour.  We
are using this code to build a scalable server where one has multiple
instances of the server running and between requests the session data
is saved to a database to allow any server to handle the next request
from one user.

> 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.
>
So in summary the first solution is all we need.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------