[yonik]

First I would like to congradulate you on ICE! Finally a spec that doesn't make me cringe or make my eyes bleed ;-)

I have only spent an hour browsing the docs so far, just looking at the protocol and slice sections. There are a couple of things I don't really agree with at first blush, but I think I'll try to split them up into separate threads as I have time instead of one long email.

There are a few places where "can't easily be supported in all languages" is used as rational for a restriction. My own design philosophy is to make the general case nice, and the outliers possible. The first that jumps out at me are the restrictions on exceptions.

"""
Exceptions are not first-class data types and first-class data types are not exceptions:
•You cannot pass an exception as a parameter value.
•You cannot use an exception as the type of a data member.
•You cannot use an exception as the element type of a sequence.
•You cannot use an exception as the key or value type of a dictionary.
•You cannot throw a value of non-exception type (such as a value of type int or string).

The reason for these restrictions is that some implementation languages use a specific and separate type for exceptions (in the same way as Slice does).
"""

All of the object oriented languages in wide use support exceptions as first class types. C++, Java, and C# must make up at least 90% of the OO languages in wide use, and exceptions are objects and can be copied in all of them AFAIK. Lesser known languages such as Python also support this fine.

The first 3 restrictions you impose would seem to prevent the following scenarios:
- nesting exceptions (throwing a new type of exception but including the info about the old)
- forwarding exceptions, passing them to a logging server as part of a larger amount of info.
- serializing exceptions

For the rare languages that are OO, but don't support "exception is also an object" semantics, then a simple specific mapping for that language could be developed. This appears to be the exception rather than the rule, however ;-)

-Yonik