Why are remote tables and StaticLabels still used in CloudHaskell?

Question

I am reading the source code for distributed-process and related packages. In distributed-static we have a definition of StaticLabel :

 data StaticLabel = StaticLabel String | StaticApply !StaticLabel !StaticLabel | StaticPtr SDynamic deriving (Eq, Ord, Typeable, Show) 

which is then used to define Static as newtype wrappers around StaticLabel with a phantom variable attached to a security type:

 newtype Static a = Static StaticLabel deriving (Eq, Ord, Typeable, Show) 

I have no questions about StaticApply , it just thickens two static values. However, StaticLabel and StaticPtr seem to achieve the same goal in different ways.

If we go with StaticLabel , we just have a / transimt a String label, which can then be used to find the Dynamic value from RemoteTable :

 newtype RemoteTable = RemoteTable (Map String Dynamic) 

Where Dynamic (defined in rank1dynamic ):

 data Dynamic = Dynamic TypeRep GHC.Any 

This is almost the same as SDynamic contained in StaticPtr :

 data SDynamic = SDynamic TypeRep (StaticPtr GHC.Any) 

The difference is that Dynamic has GHC.Any without indirection, with SDynamic we have to look for value. The result is the same: we get that Any value we can unsafeCoerce , if the TypeRep target is equal to instanceOf of the TypeRep we store in SDynamic or Dynamic .

Remote table management, although automated to some degree through TH, is still annoying, so why not use only StaticPtr s? Does StaticLabel exist only for backward compatibility with older GHCs, or am I missing something?

Answer 1

One of the main reasons for this is that we must have backward compatibility and support 3 major versions of GHC. It was also unclear whether we wanted to go straight to the solution of static pointers. For example, their "stability" is weaker. Basically, the only guarantee is that for the same library compiler version the same source code - static pointers will be compiled with the same value. In fact, a distributed process has been defined with this in mind, but some people want to have more stable pointers, and static labels give this, because you can define your own rules for the label and have the same label even in different executable files.

If the guarantees of static pointers are enough for you, then there is a distributed-closure package that provides links to static-pointer-based links. In this package, you do not need to use remote relocation at all and leave it only for the internal components of the distributed process and backward compatibility.