JEdit-1M: Logic-Independent IDE Infrastructure

• JEdit-1M is a conceptual designation referring to a large, jEdit-based formal corpus enabled by the jMMT architecture.
• The system integrates jEdit with MMT to provide logic-independent parsing, validation, and advanced semantic services.
• It offers IDE features like context-aware auto-completion, relational indexing, and fine-grained change management for formal documents.

Searching arXiv for the cited paper and closely related MMT/jEdit work to ground the article. “JEdit-1M” does not appear as a named dataset, benchmark, or corpus in “A Logic-Independent IDE” (Rabe, 2014). In the available source, the term is best understood as an inferred designation for a large jEdit-based corpus or interaction resource that could be built on top of the paper’s architecture. The paper’s actual contribution is $\mathsf{jMMT}$, a jEdit plugin that turns jEdit into a high-level, logic-independent IDE by connecting it to the MMT system. That architecture combines a logic-independent representation language, plugin-based logical kernels, a structured parsing and validation pipeline, search facilities, and fine-grained change management. Taken together, these components provide the kind of infrastructure from which a resource informally described as “JEdit-1M” could plausibly arise (Rabe, 2014).

1. Terminological status and scope

The source explicitly states that the paper never mentions a term like “JEdit-1M” or any named dataset. It also states that there is no explicit large-scale corpus, benchmark, or dataset described or branded in that way. What the paper does provide is a system design for a logic-independent IDE built from jEdit and MMT, together with mechanisms that naturally lead to a large corpus of MMT theory files, persisted ASTs in OMDoc/XML, relational indices, and term indices.

This distinction is central. “JEdit-1M” is not a formal object introduced in the paper; it is a plausible label for the class of resources enabled by the paper’s infrastructure. The available description further notes the potential for recording rich editing interactions: every buffer change triggers change management at term level, the project manager’s build tool caches ASTs and dependencies, and the web server and relational navigation index operations over the entire library. This suggests that “JEdit-1M,” if used as a shorthand, refers less to a single artifact than to a possible large jEdit-based corpus of MMT documents, typed ASTs, incremental edit histories, search queries, and completions (Rabe, 2014).

2. MMT as the formal substrate

MMT is presented as a logic-independent representation language and API designed to represent and manage many logical systems uniformly. Its structural layer abstracts over what logics share—theories, constants, contexts, and terms—rather than fixing a specific logic or type system. The grammar fragment given in the source is:

$\Sigma ::= \cdot \mid \Sigma,\; c\opt{:E}\opt{=E}\opt{\#N}$

$\Gamma ::= \cdot \mid \Gamma,\; x:E$

$E ::= c \mid x \mid \cons{c}{\Gamma}{\overline{E}}$

where $\cons{c}{\Gamma}{E_1,\ldots,E_n}$ is a general constructor covering binding and application.

The notation mechanism is likewise logic-independent. Every constant can carry a notation $N$ of the form

$N ::= \rep{(\vmk{n} \mid \amk{n} \mid \mathtt{string})},$

with $\vmk{n}$ denoting the $n$-th bound variable and $\amk{n}$ the $\Sigma ::= \cdot \mid \Sigma,\; c\opt{:E}\opt{=E}\opt{\#N}$0-th argument. This allows concrete syntax to be attached declaratively to constants instead of being hard-coded into the IDE.

MMT also fixes only the shapes of judgments that a logic plugin must implement. The source lists the following judgment forms:

$\Sigma ::= \cdot \mid \Sigma,\; c\opt{:E}\opt{=E}\opt{\#N}$1

for inhabitability,

$\Sigma ::= \cdot \mid \Sigma,\; c\opt{:E}\opt{=E}\opt{\#N}$2

for typing, and

$\Sigma ::= \cdot \mid \Sigma,\; c\opt{:E}\opt{=E}\opt{\#N}$3

for equality. For each object logic, a plugin implements these judgments. The implementation, in Scala, offers a project manager, parser and validator interfaces, and plugin points for logic and type systems, notations, term parsers, search, and related services. The paper further notes that MMT can encode LF as an MMT theory and can then encode specific logics inside LF (Rabe, 2014).

3. jMMT and the jEdit-based IDE architecture

The central system described in the paper is $\Sigma ::= \cdot \mid \Sigma,\; c\opt{:E}\opt{=E}\opt{\#N}$4, a jEdit plugin that uses MMT as its backend. jEdit supplies the editor and UI framework; MMT supplies the logic-independent structural layer and semantic services. The document model has two representations: a text representation in the jEdit buffer and an MMT representation consisting of the abstract syntax tree plus inferred information.

These two representations are connected through a four-component abstraction layer:

Level	Parsing	Validation
Structure	structure parser	structure validator
Terms	term parser	term validator

This decomposition is the mechanism by which the IDE remains logic-independent. The jMMT plugin owns text buffers, mappings from buffers to MMT ASTs, and UI functions such as completions, navigation, and search. Logic-specific kernels are plugins that implement the four operations above. The source therefore presents logic independence not as an absence of semantics, but as a strict separation between generic editor infrastructure and exchangeable logical kernels (Rabe, 2014).

The integration with jEdit is described as tight and in-process. jMMT is a standard jEdit plugin and uses SideKick for AST display, outline view, and auto-completion UI; ErrorList for collecting and displaying errors with source locations; Hyperlinks for navigation from uses to declarations; and dockable windows for AST trees, relational navigation, and search results. The jEdit process hosts both the UI and the MMT Scala library in the same JVM; there is no external server protocol in the paper.

The paper also emphasizes the role of jEdit buffers. Buffer regions are mapped to AST nodes by source references attached to MMT terms. The MMT project manager can persist ASTs via OMDoc/XML, allowing declarations in non-open files to remain navigable. jEdit’s actions and keybindings insert special separator characters, ASCII 28–31, which the structure parser uses to split declarations while allowing term parsers to remain agnostic about surface layout.

4. Semantic services: completion, typing, navigation, and search

The IDE functionality described in the source includes context-sensitive auto-completion, search, and change management. Auto-completion operates in multiple layers. At the basic level, jMMT computes the current theory $\Sigma ::= \cdot \mid \Sigma,\; c\opt{:E}\opt{=E}\opt{\#N}$5 at the cursor and the logical context $\Sigma ::= \cdot \mid \Sigma,\; c\opt{:E}\opt{=E}\opt{\#N}$6, then suggests all identifiers in scope, including constants of $\Sigma ::= \cdot \mid \Sigma,\; c\opt{:E}\opt{=E}\opt{\#N}$7, imported theories, and variables in $\Sigma ::= \cdot \mid \Sigma,\; c\opt{:E}\opt{=E}\opt{\#N}$8.

A more semantic layer is based on goals. The source introduces a special MMT constant so that terms of the form

$\Sigma ::= \cdot \mid \Sigma,\; c\opt{:E}\opt{=E}\opt{\#N}$9

represent a missing term expected to have type $\Gamma ::= \cdot \mid \Gamma,\; x:E$0. The kernel infers

$\Gamma ::= \cdot \mid \Gamma,\; x:E$1

For LF, the paper gives a completion rule: for a goal $\Gamma ::= \cdot \mid \Gamma,\; x:E$2, completion searches for constants or variables $\Gamma ::= \cdot \mid \Gamma,\; x:E$3 whose type has the form

$\Gamma ::= \cdot \mid \Gamma,\; x:E$4

such that $\Gamma ::= \cdot \mid \Gamma,\; x:E$5 unifies with the goal type $\Gamma ::= \cdot \mid \Gamma,\; x:E$6 via a substitution $\Gamma ::= \cdot \mid \Gamma,\; x:E$7. If selected, jMMT inserts

$\Gamma ::= \cdot \mid \Gamma,\; x:E$8

The paper explicitly characterizes this as a tactic API: any tactic or proof search procedure can be packaged as a completion rule that analyzes $\Gamma ::= \cdot \mid \Gamma,\; x:E$9 and proposes candidate terms (Rabe, 2014).

Interactive type inference is also described. For a selected subterm, jMMT queries the term validator on a validation unit $E ::= c \mid x \mid \cons{c}{\Gamma}{\overline{E}}$0 and displays the inferred type as a tooltip. This relies on source references at subterm granularity, notation-driven parsing, and a generic term validator using an algorithm similar to Twelf’s to reconstruct missing parts represented by $E ::= c \mid x \mid \cons{c}{\Gamma}{\overline{E}}$1-meta-variables.

Search is divided into two layers. The first is relational navigation, based on a relational index mapping documents to a lightweight ontology that includes import relations between theories and “occurs-in” relations between declarations and referenced entities. A query language supports operations such as transitive closure and restriction to theorems, and the UI exposes this as navigational buttons for related declarations. The second is term search, where the MMT build tool creates a term index consumed by MathWebSearch, which uses substitution tree indexing for fast unification-based search. The query form is

$E ::= c \mid x \mid \cons{c}{\Gamma}{\overline{E}}$2

returning all indexed terms unifiable with $E ::= c \mid x \mid \cons{c}{\Gamma}{\overline{E}}$3. Search results are shown in a panel, and selecting a result opens the corresponding file and exact subterm. The source stresses that the index includes inferred parts such as implicit arguments and reconstructed types, so the search can match material not explicitly written in the source.

5. Incremental validation and dependency management

A technically central contribution of the system is its change-management design. The source describes a two-dimensional dependency graph over terms, where “term” refers to the type or definiens of a constant. The first dimension is vertical and corresponds to phases of processing. For each term $E ::= c \mid x \mid \cons{c}{\Gamma}{\overline{E}}$4, MMT maintains its string form, its parsed representation, and its validated representation. Changes propagate downward through this pipeline: if the string changes, the system reparses; if the parsed form changes, the system revalidates; otherwise it skips costly validation.

The second dimension is horizontal and captures fine-grained logical dependencies between terms. If the type or definiens of constant $E ::= c \mid x \mid \cons{c}{\Gamma}{\overline{E}}$5 is used while checking constant $E ::= c \mid x \mid \cons{c}{\Gamma}{\overline{E}}$6, MMT records that the relevant term of $E ::= c \mid x \mid \cons{c}{\Gamma}{\overline{E}}$7 depends on that of $E ::= c \mid x \mid \cons{c}{\Gamma}{\overline{E}}$8. The paper’s example uses two theorems,

$E ::= c \mid x \mid \cons{c}{\Gamma}{\overline{E}}$9

where the proof $\cons{c}{\Gamma}{E_1,\ldots,E_n}$0 uses theorem $\cons{c}{\Gamma}{E_1,\ldots,E_n}$1. During type checking, $\cons{c}{\Gamma}{E_1,\ldots,E_n}$2 depends on the type $\cons{c}{\Gamma}{E_1,\ldots,E_n}$3 of $\cons{c}{\Gamma}{E_1,\ldots,E_n}$4, not on the proof $\cons{c}{\Gamma}{E_1,\ldots,E_n}$5. Consequently, editing $\cons{c}{\Gamma}{E_1,\ldots,E_n}$6 requires re-validating $\cons{c}{\Gamma}{E_1,\ldots,E_n}$7 but not re-checking $\cons{c}{\Gamma}{E_1,\ldots,E_n}$8, because $\cons{c}{\Gamma}{E_1,\ldots,E_n}$9’s dependencies remain unchanged (Rabe, 2014).

This behavior is enabled by per-term validation units created during structure validation. For each constant $N$0, the system produces two units:

• $N$1: validate $N$2
• $N$3: validate $N$4

The source emphasizes that this separation is essential for precise change management even though $N$5 implies $N$6 in many systems. In the inferred “JEdit-1M” perspective, this design is the principal reason a very large jEdit-based formal corpus could remain responsive under edits to shared foundational theories. A plausible implication is that the resulting dependency graph would also be valuable for studying proof repair, incremental reasoning, or edit prediction, but that use is not itself formalized in the paper.

6. Logic independence, implemented instance, and significance for a putative “JEdit-1M”

In the paper, “logic-independent” means that the IDE does not hard-code any particular logic or type theory. It depends only on generic notions of theories, constants, terms, and judgments, together with the fixed judgment schemas $N$7, $N$8, and $N$9. Specific logics are supplied as plugins. The paper gives LF as the main implemented instance, representing LF itself as an MMT theory with primitive constants such as

$N ::= \rep{(\vmk{n} \mid \amk{n} \mid \mathtt{string})},$0

and then representing an object logic inside LF with constants such as

$N ::= \rep{(\vmk{n} \mid \amk{n} \mid \mathtt{string})},$1

The generic infrastructure covers structure parsing, structure validation, notation-driven term parsing, AST display, source references, outline view, error highlighting, tooltips, hyperlink navigation, auto-completion infrastructure, project management, OMDoc export, relational indexing, term indexing, MathWebSearch integration, and the change-management engine. Logic-specific plugins provide term validator rules, equality rules such as $N ::= \rep{(\vmk{n} \mid \amk{n} \mid \mathtt{string})},$2-reduction and rewriting, solution rules for meta-variables, and optional tactic libraries or specialized parsing rules. From the UI perspective, this logic-specific complexity is hidden behind abstract operations (Rabe, 2014).

The paper’s evaluation is qualitative. It implements a full LF kernel, including LF as an MMT theory, a simple logic inside LF, LF-specific term validator rules, and the resulting LF IDE with AST and type displays, syntax and type error reporting, context-sensitive auto-completion and proof hints, and search and navigation over LF theories. No quantitative evaluation such as timings or library sizes is given. The source does, however, report a lines-of-code comparison of approximately

$N ::= \rep{(\vmk{n} \mid \amk{n} \mid \mathtt{string})},$3

as evidence for the relatively small effort required per logic.

For the topic “JEdit-1M,” the significance is architectural rather than nominal. The paper describes exactly the kind of jEdit-based infrastructure that could support a large-scale corpus of formal documents edited in jEdit: documents parsed into MMT ASTs with precise source references, a build tool that caches ASTs and exports OMDoc, relational and term indices that expose semantic graph and search data, and change-management graphs that encode fine-grained dependencies. Accordingly, “JEdit-1M” is most accurately characterized as a hypothetical large jEdit-based formal corpus or interaction resource for which “A Logic-Independent IDE” provides the underlying blueprint, rather than as an entity introduced by the paper itself (Rabe, 2014).