[isabelle-dev] Additional type variable(s) in specification

Makarius makarius at sketis.net
Thu Dec 2 20:26:18 CET 2010

On Thu, 2 Dec 2010, Alexander Krauss wrote:

> I'll have a look at the code and see if packages can reject this from 
> the user, while still being composable. This applies to all packages.

In fact I've made this error already in 2005, and it was Alex himself who 
convinced me more recently that packagages cannot realistically do any 
check here, because the thing is so obscure that hardly any package author 
will get to the point.

Back to history: in 2005 Brian had a paper on TPHOLs with a footnote about 
an unexpected crash of the typedef package due to hidden polymorphism in 
the set involved, not the type.  What I did then is to make the typedef 
package insert "itself" arguments in the way one would think of as a first 
idea.  This made the problem go away for the moment, although it 
complicated the package implementation.  When Larry was asking me about 
that change of typedef later, I also failed to explain to him both the 
problem and its solution.

After Local_Theory.define started handling the problem uniformly once and 
for all, I could remove lots of strange code from typedef, and be sure at 
the same time that all other (localized) packages would stop crashing
on the same kind of problem.

When we speak about "users" of packages it covers both ML and Isar theory 
sources, e.g. the function package is a user of the inductive package. 
It is important to keep modularity here.

The system is able to distinguish between things that are visible in the 
source vs. internal uses of the same specifciation mechanisms to some 
extent, but one needs to look very closely at that when modifying the 
behaviour here.  We have already a long track record of very abscure 
crashes due to errors that are emitted too eagerly, e.g. in declaration 
attributes that insist in certain input and choke on the transformed 
version after some interpretations.

Part of the inherent complexity of local theory specifications is due to 
interpretation wrt. the "target context", which always happens when 
writing down specifications like 'definition' or 'inductive'.  This is not 
the primitive consts + defs that we had many yours ago.  And of course, 
the extra complexity localized specifications was not introduced for fun, 
but to address concrete problems that had accumulated over a couple of 
years of less systematic treatment of these issues.  Compared to the 
situation before it, there are very little problems left that need some 
fine tuning.


More information about the isabelle-dev mailing list