Home

HOT Pickles

Alice ML team members Andreas Rossberg, Guido Tack & Leif Kornstaedt write about the implications of pickling for higher-order-type systems in their latest paper on HOT Pickles ...and how to serve them.

The need for flexible forms of serialisation arises under many circumstances, e.g. for doing high-level inter-process communication or to achieve persistence. Many languages, including variants of ML, thus offer pickling as a system service, but usually in a both unsafe and inexpressive manner, so that its use is discouraged. In contrast, safe generic pickling plays a central role in the design and implementation of Alice ML: components are defined as pickles, and modules can be exchanged between processes using pickling. For that purpose, pickling has to be higher-order and typed (HOT), i.e. embrace code mobility and involve runtime type checks for safety.

The paper makes the point that pickling should be considered an important aspect for programming language design. By making pickles first class, a number of related problems in open programming (serialization, distribution, modularity) can be directly addressed.

By Chris Rathman at 2007-06-21 15:11 | General | other blogs | 9749 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Neat stuff!

Alice ML seems way, way cool. It is interesting to see something that appears to this newbie to be in-between distributed objects vs. not. I hope backwards compatibility for pickles could some day be do-able; Java classically had similar issues I think until people started using XML (yuck) serialization?

By raould at Thu, 2007-06-21 18:23 | login or register to post comments

Planned obsolescence

I suspect that Alice ML team figured that backwards compatibility was not an important consideration at this juncture of the project - though it always becomes an issue sooner or later for any PL. Versioning is an issue with pickles (or any form of serialization/persistance) but XML doesn't really solve the problem (except for making parsing compatible across versions). You still have to have logic that deals with old elements which were dropped, new ones which were added, and previous ones that have changed structure and meaning. And in a distributed system you have to worry about different versions of the software having to exchange pickles with each other across the wire.

By Chris Rathman at Thu, 2007-06-21 20:02 | login or register to post comments

Acute

Acute tries to address some of these problems. They consider access to local resources (from mobile code), versioning, and type (dis)identity between different processes (running different versions of a program or completely different programs) more thoroughly than I remember seeing in work on Alice.

By Brandon Moore at Thu, 2007-06-21 22:55 | login or register to post comments

Re: Acute

The article mentions Acute and compares it to Alice in the Related Work section:

"Acute [28] is an ML-based language for distributed programming that is closest to Alice ML and provides a similar generic pickling mechanism. Unlike in Alice ML, pickling is not separated from dynamic typing, and all inter-process communication hence dynamically typed. Also, Acute supports implicit rebinding of resources, which we exclude for security reasons. As in the current Alice system, no pickle verification is possible."

By Catalin Hritcu at Sun, 2007-06-24 08:32 | login or register to post comments

Used to be a big fan of generic serialization...

...until I started considering the upgrade problem, ie. how to upgrade serialized code. You quickly realize that upgrade simply isn't possible to do transparently since it requires application-specific knowledge of the data structures, so the application needs to be involved in its own persistence. This is in fact the same approach E is taking, and they make a good case for it: In praise of manual persistence. Pickler combinators would certainly relieve some of the tedium of persistence.

Note that transparent persistence is still possible in this framework (for recovery from faults), but transparent upgrade isn't.

By naasking at Thu, 2007-06-21 21:18 | login or register to post comments

tools to aid?

upgrade simply isn't possible to do transparently

relieve some of the tedium of persistence

Presumably one could break the issue down somewhat, and see if some parts are more solvable than others, and build tools to aid in those custom situations.

Like, are there are changes of a 'syntax' nature vs. changes of a 'semantic' nature? Changes to data structures or code which can be directly mapped vs. changes which probably bend things so much that a mapping is really hard, or not do-able. What tools would be relevant for solving that range of situations?

If you then have the chain of mappings, you could have bi-directional compatibility? Sounds like basic theory of functions and categories would be relevant. Too bad I'm math clueless.

By raould at Fri, 2007-06-22 19:39 | login or register to post comments