-
Notifications
You must be signed in to change notification settings - Fork 24
Description
Here's the list I promised, @mkohlhase @frabe :
-
Terms in sTeX can occur outside of declaration components - i.e. anywhere ("top-level terms"), but should be checked by the Solver, (possibly) have URIs etc.
- current solution: Signature/Language module split; top-level terms are represented as definientia for constants in the language module (only if term is a
ComplexTerm)
- current solution: Signature/Language module split; top-level terms are represented as definientia for constants in the language module (only if term is a
-
sTeX has
\usemodule- current solution:
\usemoduleis represented as an include in the language module. This makes sense in that the symbols imported via usemodule should not occur in components of declared symbols (which would imply a "real" dependency) - but maybe we would want them to be allowed to? e.g. they could be allowed in (formal) definientia, but just not further exported in TeX. Could add the includes to the signature theory instead.
- current solution:
-
statements (definition/example/theorem/sparagraph/...) - narrative elements that should be queryable for, amenable to (to some extent) being modified by "narrative theory morphisms" and/or document context (numbering, possibly choice of notations etc.)
- current solution: as with top-level terms; add them to the language module as constants with the HTML as
OMFOREIGN-definiens, add relational for e.g.is-example-of,is-definition-ofetc.
- current solution: as with top-level terms; add them to the language module as constants with the HTML as
-
notations for any symbol can be introduced anywhere where the symbol is in scope; this includes language-specific notations (e.g.
ggT(...)vsgcd(...))- current solution: again constants with HTML of the notation as
OMFOREIGN-definiens + relational info
- current solution: again constants with HTML of the notation as
-
variables can be declared and used local to the current TeX-Group
- current solution: declarations are tracked during import and references are abstracted away according to MMT rules (or roles?) at the outside of top-level terms and components; e.g. by
lambdain definientia,pi/forallin types, by default, by\bindin the sTeX meta theory. The binder symbols used should be set depending on e.g. a precise meta theory:\importmodule{?HOL}would give me the symbols,\begin{smodule}[meta=?HOL]would do the same, but also setHOLs lambda/pi symbols as the ones to use for abstracting away variables. Drawback: the declaration of the variable itself is not represented as OMDoc.
- current solution: declarations are tracked during import and references are abstracted away according to MMT rules (or roles?) at the outside of top-level terms and components; e.g. by
-
implicit variables: in MMT surface syntax, these are determined by notations. In sTeX, semantic macros have fixed arities though, so either we force users to always provide all arguments and hide them in the notations, or we allow for the same semantic macro to have different arities depending on the notation (dangerous, ugly to implement, unintuitive to use), or:
- current solution: variables not occuring in terms directly, but in types/definientia of other variables are considered implicit arguments; they are abstracted away on the outside of a component using
\implicitbindand become part of the type or definiens of a constant, rather than the notation. This means that every occurence of a symbol in a term requires a loopup of the type/definens to check for animplicitbindand introduce fresh variables to be solved accordingly.
- current solution: variables not occuring in terms directly, but in types/definientia of other variables are considered implicit arguments; they are abstracted away on the outside of a component using
-
sTeX allows for bound variables in any argument position; this is incompatible with
OMBINDCcurrently- current solution: sTeX-specific HOAS with wrapper
SOMB()for aOMBINDC(...)where the argument positions are attached to the bound variables
- current solution: sTeX-specific HOAS with wrapper
-
Module types: will become more ubiquitous in sTeX as the most convenient way to represent structured dependent data. Should be represented as a structural feature that generates a module/record type, but derived declarations can't "include" other derived declarations, because MMT currently does not support theory morphisms between derived declarations.
- current solution: nested theory instead, add a constant for the MOD type (marked as
GeneratedFromthe nested module)
- current solution: nested theory instead, add a constant for the MOD type (marked as
-
need conservative extensions; primarily for module types (e.g. to subsequently add the defined subtraction/division-operation to a group)
- current solution: tracked in TeX, a conservative extension
barto a module type?fooredefines\foofrom generatingOMS(foo)toRecordMerge(?foo, MOD ?bar)instead. This is necessary, since there can be multiple conservative extensions distributed among multiple modules, so we can't guarantee that the current usage of\fooin a given document context corresponds to any specific nested module with precisely all the conservative extensions of?foo.
- current solution: tracked in TeX, a conservative extension
-
Notable: can fully or partially instantiate module types, either way represented as a
RecordMergeof the module type with an anonymous record, which gives us a (structural) subtype. An actual instance is identified with the (structural) subtype with all fields defined, i.e. a singleton type. -
More stuff related to statements:
- terms
tin asdefinitionmarked with\definiens{t}are attached to the corresponding constantcas definiens, iffcdoes not yet have a definiens andcis declared in the same module as the definition. Otherwise, it generates an equality rulet==c. - the
sassertionenvironment withname=and (optionally)\assume{t1}...\assume{tn}and\conclusion{t}generates a new constant of typeDED t1 -> ... -> DED tn -> tfor some->andDEDprovided via MMT rules (or roles, as above) => can also be used to provide types to declarations. - the
proof-environment behaves basically likesdefinition, but with intermediate steps; structural feature will/should build up the proof term from individual steps
- terms
-
More stuff related to HOAS et al:
- lots of metadata on all (sub)terms to keep track of e.g. the term before applying HOAS things (for subsequent presentation as MathML), the precise notation used etc.