Hi Oleg,<br><br><div class="gmail_quote">On Wed, Jul 21, 2010 at 09:36, <span dir="ltr"><<a href="mailto:oleg@okmij.org">oleg@okmij.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Jose Pedro Magalhaes wrote:<br>
> From what I understand, you are using a list of integers to encode a path to<br>
> a subterm. This is a practical and lightweight implementation, but less<br>
> type-safe: it is easy to encode annotations that do not correspond to any<br>
> value. Also, it cannot guarantee, with types alone, that every subterm is<br>
> annotated.<br>
<br>
Let us consider the type safety closely. Let us assume a very<br>
simple data type: lists of integers of length 10. Suppose we want to<br>
add string annotations to the elements. In my solution, I create an<br>
IntMap whose key is an integer 0..9 (the index in the original list)<br>
and the value is the string annotation. It is true that the type<br>
system does not prevent me from adding an annotation for key 11 (which<br>
corresponds to no element in the original list) or from forgetting to<br>
add annotation for key 7.<br>
<br>
As I understand it, your approach is to transform the original list of<br>
integers into the list of (Int,String) pairs. Now we are sure that<br>
each element is paired with an annotation and there are no orphan<br>
annotations. The annotation process creates this new list of pairs and<br>
returns it. However, how do you get _the type checker_ to ensure that<br>
the annotated list does correspond to the original list? That all old<br>
elements are present in the annotated list, and in the same order?<br>
<br>
It all boils down to enforcing the invariant<br>
proj al == l<br>
where l is the original list, al is the annotation list, and proj is<br>
the operation that removes annotations. It is true that my lightweight<br>
method generally cannot, in type system, enforce that invariant. (I<br>
can still enforce it if I design an appropriate security kernel and<br>
prove, _offline_, its correctness). But how could you enforce that<br>
invariant *in the type system*?<br>
<br>
</blockquote></div><br>Considering our library approach (using multirec), there is no type-level guarantee that the "generic" values correspond to their "normal" counterparts. From the type we can see that they have the same shape, but not that they have the same content. This would be an offline proof: that the embedding-projection pair really is an isomorphism (between "normal" and "generic" values).<br>
<br>However, this proof is external to the annotations system: it belongs in the generic library (since the library generates the embedding-projection pair automatically), and only needs to be done once. Once the embedding-projection pair has been proven correct, the annotations are "shape-correct" by construction, and "value-correct" by the correctness of the generic library.<br>
<br>As I understand it, in your system you would need a proof of correctness for every annotated type.<br><br><br>Cheers,<br>Pedro<br><br>