Re: [isabelle] Formalisations of infinite streams



I strongly believe that different coinductive formalizations should be unified,
if that's what they need. As much of it as possible should be in one place, and
the AFP is the right place for larger libraries. We could mark some entries as
"subsumed by ..." afterwards.

I would not try and unify the two models (coinductive and  nat => 'a),  they
have their own advantages and disadvantages. Nor would I unify different entries
using the nat => 'a model: that should be driven by some application, rather
than proactively.

Tobias


Am 13/06/2012 16:36, schrieb Andreas Lochbihler:
> Dear all,
> 
> there is a growing number of formalisations of infinite streams in the Archive
> of Formal Proofs. I am aware of the following, but I guess there might be even
> more hidden in other entries:
> 
> 1. David Trachtenherz' entry Infinite Lists develops a stream view on the type
> "nat => 'a". It tries to reuse as many standard operations on functions as
> possible for the list operations. For example, List.map corresponds to "op o",
> List.set to range. Additionally, he defines the sum type of finite and infinite
> lists called generalised lists.
> 
> 2. Stefan Friedrich's entry Lazy List II develops finite and infinite lists over
> a given alphabet based on coinductive lists from the entry Coinductive.
> 
> 3. Peter Gammie recently defined coinductive streams as a codatatype which I
> have now added to Coinductive in the development AFP. Support for operations on
> streams is still quite limited.
> 
> 4. Stephan Merz' entry Stuttering Equivalence models infinite strings as
> functions "nat => 'a" and defines a suffix operation.
> 
> Since there is considerable redundancy, I wonder whether and how we should unify
> these developments. Some questions are:
> 
> - Should we have a type of its own ('a stream) or operations on functions (nat
> => 'a) or both versions?
> - Should we do equality proofs by coinduction or induction on all indices?
> - Should we provide any of these versions as part of the Isabelle library such
> that there is an "official" version to be used in future developments?
> - Should/can we rework the existing formalisations to use the new one?
> - If yes: Can we somehow estimate the required effort?
> 
> I'll be happy to help in consolidating all this. However, at the moment, I
> cannot estimate at the moment how much of the AFP and the theories in the wild
> depend on these formalisations.
> 
> Any opinions?
> 
> Andreas
> 





This archive was generated by a fusion of Pipermail (Mailman edition) and MHonArc.