docs: synced via GitHub Actions

Author: nop-cao

src/theory/paper/generalized-reversible-computation-paper-en.md

@@ -659,7 +659,7 @@ GRC is often misunderstood as adding unnecessary complexity. In reality, it does
 
 A core advantage of GRC is its seamless and orthogonal fusion of declarative and imperative programming. In the structure of its core formula `Y = Generator<DSL> ⊕ Δ`, the DSL, as the textual representation of the model, **does not need to be Turing-complete**, which keeps it simple and highly structured. When a declarative model is insufficient to express all logic, the delta `Δ` allows for the introduction of an imperative "escape hatch," such as a script or a Turing-complete template call. This endows the system with the ability to handle arbitrary complexity while strictly constraining the complexity of imperative code within local, explicit delta units.
 
-Furthermore, although GRC requires developers to embrace a new mental model, its engineering implementation (such as the XDef metamodel in the Nop Platform) greatly reduces the cost of this transition. Once an architect defines a new business DSL using XDef, the platform **immediately and automatically** endows this new language with the full suite of GRC capabilities, including a unified delta mechanism and toolchain support. This "instant ROI" is the best compensation for the learning curve.
+Furthermore, although GRC requires developers to embrace a new mental model, its engineering implementation (such as the XDef metamodel in the Nop Platform) greatly reduces the cost of this transition. Once an architect defines a new business DSL using XDef, the platform immediately and automatically endows this new language with the full suite of GRC capabilities, including a unified delta mechanism and toolchain support. This "instant ROI" is the best compensation for the learning curve.
 
 #### 9.2. Future Work
 

src/theory/paper/generalized-reversible-computation-paper.tex

@@ -257,7 +257,7 @@ \subsubsection{Language Workbenches: Language Composition vs. Unified Metamodel}
 \begin{table}[htbp]
 \centering
 \caption{Comparison of GRC and JetBrains MPS Paradigms}
-\begin{tabularx}{\textwidth}{@{} l X X @{}}
+\begin{tabularx}{\textwidth}{@{} X X X @{}}
 \toprule
 \textbf{Dimension} & \textbf{JetBrains MPS} & \textbf{Generalized Reversible Computation (GRC)} \\
 \midrule
@@ -406,7 +406,7 @@ \subsection{Analogy with the Dirac (Interaction) Picture}
 \begin{table}[htbp]
 \centering
 \caption{Methodological Comparison of Computational Paradigms and Physics Pictures}
-\begin{tabularx}{\textwidth}{@{} l X X X @{}}
+\begin{tabularx}{\textwidth}{@{} X X X X @{}}
 \toprule
 \textbf{Dimension} & \textbf{Turing Machine} & \textbf{Lambda Calculus} & \textbf{GRC Paradigm} \\
 \midrule
@@ -1079,18 +1079,22 @@ \section{An Argument for the Associativity of the Merge Operator $\oplus$}
 \subsection{The Domain Model Coordinate System}
 GRC treats any structured software artifact as a \textbf{domain model} and establishes a \textbf{domain coordinate system} for it. Every value in the model can be located by a unique \textbf{Path}. For example, for the XML:
 \begin{lstlisting}[language=XML, numbers=none]
-<entity name="MyEntity">
-  <columns><column name="status" length="10" /></columns>
+<entity name="MyEntity" table="MY_ENTITY">
+  <columns>
+     <column name="status" sqlType="VARCHAR" length="10" />
+  </columns>
 </entity>
 \end{lstlisting}
-We can "flatten" it into a `{path: value}` map:
+We can "flatten" it into a `{path: value}` map, where the path is the coordinate:
 \begin{verbatim}
 {
   "/@name": "MyEntity",
+  "/@table": "MY_ENTITY",
+  "/columns/column[@name='status']/@sqlType": "VARCHAR",
   "/columns/column[@name='status']/@length": 10
 }
 \end{verbatim}
-All GRC operations are essentially operations on the values at specific coordinate points.
+The path here (a simplified form of XPath) is the domain coordinate, as it is composed of domain concepts with business meaning like `entity`, `column`, and `name`. All GRC operations are essentially operations on the values at specific coordinate points in this system.
 
 \subsection{The Argument for Associativity}
 If we view a model as a high-dimensional vector where each dimension corresponds to a unique domain coordinate, then the merge of two models $M_1 \oplus M_2$ can be seen as a dimension-wise merge of two vectors. To \textbf{argue} that the merge of vectors satisfies associativity, we only need to \textbf{show} that the value merge operation at a single coordinate point satisfies associativity.
@@ -1168,6 +1172,12 @@ \subsection{Embedded Generator}
 \end{lstlisting}
 
 \subsection{Deterministic Construction Order}
-XDSL defines a deterministic, multi-stage delta merging pipeline. All these construction operations are completed during the model loading phase and are completely transparent to the runtime, implementing the core "phase separation" idea of GRC.
 
+XDSL defines a deterministic, multi-stage delta merging pipeline, with priority decreasing from left to right:
+
+\begin{center}
+$\Delta$ \textit{from post-extends} $\oplus$ $\Delta$ \textit{defined in current model} $\oplus$ $\Delta$ \textit{from gen-extends} $\oplus$ \textit{Base model from x:extends}
+\end{center}
+
+All these construction operations are completed during the model loading phase and are completely transparent to the runtime, implementing the core "phase separation" idea of GRC.
 \end{document}