Packages

  • package root
    Definition Classes
    root
  • package info
    Definition Classes
    root
  • package kwarc
    Definition Classes
    info
  • package mmt
    Definition Classes
    kwarc
  • package api

    This is the main package of the MMT API.

    This is the main package of the MMT API.

    It holds subpackages for all data structures, data containers, and the central algorithms and services.

    Classes directly defined in the package

    Some minor classes that are used throughout MMT are defined in this package, in particular:

    • MMT URIs in the class Path and Namespace
    • processing and content errors in the class Error

    The package also contains root classes for certain types that are subclassed throughout the package. Most importantly:

    • StructuralElement: structure-level (= named) parts in the data structures for the MMT language: documents, theories, constants, ...
    • MMTTask: tasks for a single object: parsing, checking, ...
    • Rule: object-level part of the MMT language that is written in Scala

    Subpackages

    Data structures for the MMT language

    The data structures for the MMT languages are defined in 4 packages corresponding to the 4 levels: - documents: Documents and all other NarrativeElements - modules: Modules (= the toplevel declarations), in particular Theorys and Views - symbols: all Declarations inside modules, in particular Constants - objects: all anonymous Objects (e.g., formulas, functions, etc.), in particular Contexts and Terms

    The former 3 levels are jointly called 'structural' levels. All elements subclass StructuralElement, have an MMT URI, and carry an MMT URI referring to their parent in the MMT abstract syntax tree.

    Structural elements are extensible (via DerivedModules and DerivedDeclarations), and the package patterns defines declaration patterns as a built-in extension.

    All structural elements are mutable and implement the ContainerElement interface for changing their children. Objects, by contrast, are represented as immutable inductive types.(except for carrying metadata.Metadata and objects.ClientProperties). The boundary between structural elements and objects is mediated by ComponentContainers: these are mutable, owned by structural elements, and maintain objects.

    A few auxiliary data structures shifted to separate packages: - opaque: external (i.e., informal, computation) content - informal: partially outdated informal data structures - metadata: metadata annotations to all structural elements or objects

    The MMT main class and its internal state

    The package frontend contains the class Controller, which owns all state relevant for running MMT. Typically, each application creates a single instance of this class. The package also defines several other essential classes, most importantly MMT's extension (=plug-in, add-on) interfaces via the Extension class.

    The package libraries maintains the instances of MMT language data structures, in particular the Library class. Controller owns a Library, which stores all structural elements that have been loaded into memory.

    User interfaces

    The package frontend also contains the main executable classes, in particular the Shell class.

    The package gui collects all classes for building graphical user interfaces. This includes auxiliary classes for use in IDE plugins.

    The package web collects all classes for the HTTP interface of MMT.

    Physical storage of the MMT language files

    The package archives defines MMT Archives (= projects) as well as classes for building and working with archives. The latter include in particular the BuildManager and BuildTarget. Build targets include Importers and [Exporter]]s that translate between MMT and other formats.

    The package backend defines classes for maintaining archives and translating between the MMT URIs of structural elements and their physical storage locations.

    The central algorithms for processing MMT content

    The processing model of MMT consists of several major algorithms. - parser: read strings into MMT data structures - checking: check and refine MMT data structures - uom: pure computation on MMT data structures - proving: theorem proving on MMT data structures (in very early state)) - execution: imperative computation (in very, very early state) - presentation: rendering MMT data structures in user-facing formats (including HTML+presentation MathML)

    All algorithms are defined in Extensions coupled with default implementations. Moreover, all algorithms are split into two separate levels, one for structural elements and objects. See LeveledExtension.

    The package notations maintains the common code for parsing and presentation.

    The package valuebases maintains mathematical databases as a part of MMT.

    Other algorithms on the MMT data structures

    The package ontology contains a relational, semantic web-style ontology and query engine for it.

    The package moc contains change management.

    The package refactoring contains refactoring principles.

    General purpose utility functions

    The package utils defines general purpose APIs for files, URIs, HTML building, etc.

    Definition Classes
    mmt
  • package symbols

    MMT Declarations are the elements of Modules.

    MMT Declarations are the elements of Modules. The kinds of declarations are documented at Declaration.

    ObjContainer are owned by structural elements, in particular by declarations, to store objects.

    Definition Classes
    api
  • ApplyMorphism
  • ApplyMorphismLazy
  • ApplySubs
  • BoundTheoryParameters
  • Constant
  • ConstantAssignment
  • ContextContainer
  • Declaration
  • DefLinkAssignment
  • DerivedContentElement
  • DerivedDeclaration
  • DerivedModule
  • Elaboration
  • FinalConstant
  • GeneralStructuralFeature
  • GenerativePushout
  • HasDefiniens
  • HasNotation
  • HasType
  • IdentityInclude
  • IdentityTranslator
  • Include
  • IncludeData
  • IncludeLike
  • LazyConstant
  • LinkInclude
  • ModuleLevelFeature
  • NestedModule
  • OMLReplacer
  • OMSReplacer
  • ObjContainer
  • ObjDimension
  • ParametricTheoryLike
  • PlainInclude
  • Renamer
  • RuleConstant
  • RuleConstantInterpreter
  • RuleConstantParser
  • SimpleDeclaredStructure
  • SimpleLazyConstant
  • SimpleStructure
  • StructuralFeature
  • StructuralFeatureRule
  • StructuralFeatureUtil
  • Structure
  • TermContainer
  • TheoryLike
  • Translator
  • TraversingTranslator
  • TypedConstantLike
  • TypedParametricTheoryLike
  • UniformTranslator
  • UnnamedUntyped
  • Untyped
  • Visibility
c

info.kwarc.mmt.api.symbols

IncludeData

case class IncludeData(home: Term, from: MPath, args: List[Term], df: Option[Term], total: Boolean) extends Product with Serializable

Auxiliary class that collects information about a structure that acts like an include.

home

The module in which this include is declared (e.g. a theory T, view V, etc.)

from

The domain D of the included theory (into T, or into domain of V)

args

Instantiations of the parameters of from (if any, e.g. for parametric theories)

df

Definiens (of type D(args) -> T, or D(args) -> codomain of V)

total

A total include is one that must be implemented by the containing theory this becomes available as a morphism only at the end of the containing theory (even if there is a definiens, which can happen, e.g., if the definiens refers to other total includes) invariants: if df contains mor then args.isEmpty && from is domain of df else OMPMOD(from,args) is included theory Note that concrete syntax may allow "include df" because D because can be infered; in a theory, "include D" is the standard for includes without definiens; in a view, we may also allow "include D" for the case where df is the identity of D. See the examples below!

Source
Structure.scala
Examples:
  1. A Theory T includes a theory S in the usual way: theory S : ?someMetaTheory = ... ❚ theory T : ?someMetaTheory = include ?S ❙ ❚ Both theories are non-parametric, i.e. as usual. Then T.getAllIncludes will contain an IncludeData(T.path, S.path, Nil, None, false).

  2. ,
  3. Assume S, T as above, as well as a View v: T -> R including another view w: S -> R: view w : S -> R = ... ❚ view v : T -> R = include ?S ❘ = ?w ❙ ❚ Then v.getAllIncludes will contain an IncludeData(v.path, S.path, Nil, w.path, false).

  4. ,
  5. Let R, S, T be as below: theory R : ?someMetaTheory = ... ❚ theory S : ?someMetaTheory = include ?R❙ ... ❚ theory T : ?someMetaTheory = include ?R ❙ ... ❚ Pictorially, this is an inclusion triangle (with one missing edge): R / \ T S Now suppose we want a View v: T -> S which is the identity on R, i.e. v_R = id_R. In surface syntax we can do this as follows: view v: T -> S = include ?R❙ ❚ With this v.getAllIncludes will contain an IncludeData(v.path, R.path, Nil, Some(OMIDENT(R.path)), false).

  6. ,
  7. If you have a View v: T -> S between two theories with the same meta theory mt, then v.getAllIncludes will automatically include IncludeData(v.path, mt.path, Nil, Some(OMIDENT(mt.path)), false) similar to the previous example where the view is the identity on the included theory.

See also

https://uniformal.github.io//doc/language/implicit.html

Linear Supertypes
Ordering
  1. Alphabetic
  2. By Inheritance
Inherited
  1. IncludeData
  2. Serializable
  3. Serializable
  4. Product
  5. Equals
  6. AnyRef
  7. Any
  1. Hide All
  2. Show All
Visibility
  1. Public
  2. All

Instance Constructors

  1. new IncludeData(home: Term, from: MPath, args: List[Term], df: Option[Term], total: Boolean)

    home

    The module in which this include is declared (e.g. a theory T, view V, etc.)

    from

    The domain D of the included theory (into T, or into domain of V)

    args

    Instantiations of the parameters of from (if any, e.g. for parametric theories)

    df

    Definiens (of type D(args) -> T, or D(args) -> codomain of V)

    total

    A total include is one that must be implemented by the containing theory this becomes available as a morphism only at the end of the containing theory (even if there is a definiens, which can happen, e.g., if the definiens refers to other total includes) invariants: if df contains mor then args.isEmpty && from is domain of df else OMPMOD(from,args) is included theory Note that concrete syntax may allow "include df" because D because can be infered; in a theory, "include D" is the standard for includes without definiens; in a view, we may also allow "include D" for the case where df is the identity of D. See the examples below!

Value Members

  1. final def !=(arg0: Any): Boolean
    Definition Classes
    AnyRef → Any
  2. final def ##(): Int
    Definition Classes
    AnyRef → Any
  3. final def ==(arg0: Any): Boolean
    Definition Classes
    AnyRef → Any
  4. val args: List[Term]
  5. final def asInstanceOf[T0]: T0
    Definition Classes
    Any
  6. def asMorphism: Term

    OMIDENT(from) or OMINST(from, args) or OMCOMP(the-former, df); OMStructuralInclude for realizations

  7. def clone(): AnyRef
    Attributes
    protected[lang]
    Definition Classes
    AnyRef
    Annotations
    @throws( ... ) @native()
  8. val df: Option[Term]
  9. final def eq(arg0: AnyRef): Boolean
    Definition Classes
    AnyRef
  10. def finalize(): Unit
    Attributes
    protected[lang]
    Definition Classes
    AnyRef
    Annotations
    @throws( classOf[java.lang.Throwable] )
  11. val from: MPath
  12. final def getClass(): Class[_]
    Definition Classes
    AnyRef → Any
    Annotations
    @native()
  13. val home: Term
  14. def isDefined: Option[(MPath, Term)]
  15. final def isInstanceOf[T0]: Boolean
    Definition Classes
    Any
  16. def isPlain: Option[(MPath, MPath)]
  17. def isRealization: Boolean

    true if this represents a realization

  18. final def ne(arg0: AnyRef): Boolean
    Definition Classes
    AnyRef
  19. final def notify(): Unit
    Definition Classes
    AnyRef
    Annotations
    @native()
  20. final def notifyAll(): Unit
    Definition Classes
    AnyRef
    Annotations
    @native()
  21. final def synchronized[T0](arg0: ⇒ T0): T0
    Definition Classes
    AnyRef
  22. def toStructure: Structure
  23. val total: Boolean
  24. final def wait(): Unit
    Definition Classes
    AnyRef
    Annotations
    @throws( ... )
  25. final def wait(arg0: Long, arg1: Int): Unit
    Definition Classes
    AnyRef
    Annotations
    @throws( ... )
  26. final def wait(arg0: Long): Unit
    Definition Classes
    AnyRef
    Annotations
    @throws( ... ) @native()

Inherited from Serializable

Inherited from Serializable

Inherited from Product

Inherited from Equals

Inherited from AnyRef

Inherited from Any

Ungrouped