Hi Florian,What is called mixin in the implementation is a transfer principle that is applied in addition to the interpretation morphism. Currently users can only give equations, which yield rewrite morphisms, and consequently, the term 'mixin' appears nowhere in the documentation. On the other hand, the locale core 'knows' nothing about the equations. For it, their are just general transfer principles.
Regarding your questions:a) This is intentional. Mathematics is full of examples where a concept can be defined differently (more easily) in a situation that is more concrete. I might have to tweak inheritance of rewrite morphisms in the future, though, and that's why the documentation is relatively vague.
b) I don't yet see how one could reliably predict which equations should be unfolded. This might be more obvious in the class package. For interpretation, we don't even know whether a rewrite morphism is related to a definition.
An alternative proof avoiding the 'OF construction' in your example is attached.
Clemens Quoting Florian Haftmann <florian.haftm...@informatik.tu-muenchen.de>:
Hi Clemens,
I stumbled over two issues in locale interpretation.
a) According to the tutorial, in situation like these
locale A = ?
--[ interpretation A: instantiation phi + mixin eqn]--> theory
locale B = A + ?
--[ interpretation B: instantiation phi] --> theory
the mixin eqn is implicitly propagated to interpretation B. I can
observe this (cf. theory Locale_Mixin_Subsumption_2.thy).
However, in a slightly more general situation
locale A = ?
--[ interpretation A: instantiation phi + mixin eqn]--> theory
locale B = A + ?
--[ interpretation B: instantiation phi'] --> theory
where phi' is a more special variant of phi wrt. types, this does not
hold, i.e. eqn is not part of B (cf. theory
Locale_Mixin_Subsumption_1.thy, in which this situation appears quite
natural).
Is this behaviour intentional or a misfit?
b) The examples also show another issue: equations stemming from mixins
in interpretations are not applied to the interpretation proposition to
prove itself; consequently, if the assumption part of a locale to
interpret refers to derived definitions inside the locale, the proof of
this requires to handle the primitive expanded version of those
definitions rather than the definitions modulo the given mixins (hence
the ? [OF this] ? construction in the proofs in the examples).
This situations reminds of similiar experiences with derived definitions
and the class target, or even the target infrastructure in general,
where the equations stemming from derived definitions must be folded and
unfolded in critical situation, cf. e.g.
http://isabelle.in.tum.de/repos/isabelle/file/064394a1afb7/src/Pure/Isar/class_declaration.ML#l69
where the fundamental introduction rule for class membership is
preprocessed with those equations (»Class.these_defs«). Maybe something
similar needs to be done here; due to the dynamic nature of the
problem, I forsee no other possibility than to extend unfold_locales to
consider mixin equations also by folding them in the remaining goals.
Btw. these question have arisen when I spent some thought about the
future of Tools/interpretation_with_defs.ML
All the best,
Florian
--
PGP available:
http://home.informatik.tu-muenchen.de/haftmann/pgp/florian_haftmann_at_informatik_tu_muenchen_de
Locale_Mixin_Subsumption_3.thy
Description: Binary data
_______________________________________________ isabelle-dev mailing list isabelle-...@in.tum.de https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev
