docs: synced via GitHub Actions

nop-cao · nop-cao · commit eae93a5412cb · 2025-02-02T14:06:00.000Z
diff --git a/src/compare/nop-vs-mps.md b/src/compare/nop-vs-mps.md
@@ -1,5 +1,50 @@
 # Nop平台与Jetbrains公司的MPS产品的设计对比
 
+语法制导翻译（Syntax-Directed Translation，SDT）是编译原理中的核心技术，它将语义动作与上下文无关文法的产生式相结合，在语法分析过程中逐步执行翻译任务。以下是其核心要点：
+
+### 核心概念
+1. **基础框架**：
+  - **上下文无关文法**：描述语言结构。
+  - **语义动作**：附加在文法产生式上的代码片段，用于属性计算、生成代码或执行其他翻译任务。
+
+2. **属性类型**：
+  - **综合属性**：自底向上传递，由子节点属性计算父节点属性（如表达式求值）。
+  - **继承属性**：自顶向下传递，父节点向子节点传递上下文信息（如变量类型声明）。
+
+### 实现机制
+- **动作触发时机**：
+  - **自底向上分析（LR分析）**：归约时执行语义动作，属性通过分析栈传递。
+  - **自顶向下分析（递归下降）**：在推导过程中嵌入动作，属性通过函数参数/返回值传递。
+
+- **属性文法**：
+  - **S属性文法**：仅含综合属性，适用于LR分析。
+  - **L属性文法**：含继承属性，适用于LL分析，属性依赖左部或左侧兄弟节点。
+
+### 典型应用
+1. **中间代码生成**：如抽象语法树（AST）、三地址码。
+2. **语义检查**：类型匹配、作用域验证。
+3. **符号表管理**：记录变量类型、作用域等信息。
+4. **目标代码生成**：根据语法结构生成机器指令。
+
+### 示例说明
+以算术表达式为例：
+```plaintext
+E → E + T   { E.val = E₁.val + T.val }
+E → T       { E.val = T.val }
+T → T * F   { T.val = T₁.val * F.val }
+T → F       { T.val = F.val }
+F → (E)     { F.val = E.val }
+F → num     { F.val = num.val }
+```
+每个产生式附加的语义动作用于计算表达式的值，属性`val`自底向上传递，最终得到根节点的值。
+
+### 挑战与解决方案
+- **继承属性处理**：在自底向上分析中，需通过全局符号表或标记非终结符间接传递。
+- **动作顺序**：确保依赖关系正确的属性计算顺序，避免未定义值。
+
+### 总结
+语法制导翻译通过文法规则与语义动作的紧密结合，系统化地将源代码转换为目标形式。其核心在于利用语法结构指导翻译过程，使编译器设计更模块化，广泛应用于现代编译器的各个阶段。
+
 ## KimiChat
 我先仔细看了用户的问题，他想了解Nop平台中的XLang和Jetbrains公司的MPS之间的对比。我觉得这个问题挺有意思，因为涉及到两个不同的技术体系，而且它们在领域专用语言（DSL）开发方面都有自己的特点。
 我首先想到的是，要对比这两个东西，得先搞清楚它们各自的特点和优势。我得从它们的定义、功能、应用场景等方面入手，这样才能全面地进行对比。
@@ -64,10 +109,10 @@ XLang和MPS都是强大的DSL开发工具，但它们在设计理念、实现方
 
 #### **3. 核心机制深度对比**
 ##### **（1）多DSL集成原理**
-- **XLang**：  
-  - 所有DSL均基于XDef元模型定义，生成统一AST结构。  
-  - 不同DSL的AST通过`x-extends`在编译期合并为单一逻辑树，形成**全局坐标系**（通过XPath唯一标识节点）。  
-  - **示例**：  
+- **XLang**：
+  - 所有DSL均基于XDef元模型定义，生成统一AST结构。
+  - 不同DSL的AST通过`x-extends`在编译期合并为单一逻辑树，形成**全局坐标系**（通过XPath唯一标识节点）。
+  - **示例**：
     ```yaml
     # DSL1: 定义数据模型
     model:
@@ -84,20 +129,20 @@ XLang和MPS都是强大的DSL开发工具，但它们在设计理念、实现方
         response: User  # 直接引用DSL1中定义的User模型
     ```
 
-- **MPS**：  
-  - 通过**语言模块**定义独立的DSL（如Java、SQL），模块间需显式定义交互规则（如类型映射）。  
-  - 多语言混合依赖**生成器**将不同DSL转换为中间代码（如Java），再统一编译。  
+- **MPS**：
+  - 通过**语言模块**定义独立的DSL（如Java、SQL），模块间需显式定义交互规则（如类型映射）。
+  - 多语言混合依赖**生成器**将不同DSL转换为中间代码（如Java），再统一编译。
 
 ##### **（2）图形化支持**
-- **XLang**：  
-  - 图形化是DSL的**可视化表示**，与文本形式等价且可双向转换。  
-  - **示例**：  
-    - 文本形式：`steps: [ {name: "Step1", action: "callAPI"} ]`  
-    - 图形形式：流程图节点“Step1”指向“callAPI”操作。  
+- **XLang**：
+  - 图形化是DSL的**可视化表示**，与文本形式等价且可双向转换。
+  - **示例**：
+    - 文本形式：`steps: [ {name: "Step1", action: "callAPI"} ]`
+    - 图形形式：流程图节点“Step1”指向“callAPI”操作。
 
-- **MPS**：  
-  - 图形化是**语法的一部分**（如表格、符号），需单独定义编辑器和渲染规则。  
-  - 不同表示形式的转换需手动实现（如表格→代码生成）。  
+- **MPS**：
+  - 图形化是**语法的一部分**（如表格、符号），需单独定义编辑器和渲染规则。
+  - 不同表示形式的转换需手动实现（如表格→代码生成）。
 
 ---
 
@@ -120,15 +165,15 @@ XLang和MPS都是强大的DSL开发工具，但它们在设计理念、实现方
 ---
 
 #### **6. 总结与选型建议**
-- **选择XLang若**：  
-  - 核心需求是**企业级系统的无源码定制**（如金融、ERP）。  
-  - 需**多DSL协同工作**（如数据模型+业务逻辑+前端），且希望编译期完成集成。  
-  - 追求**逻辑的多模态表示**（文本、图形、表格自由切换）。  
+- **选择XLang若**：
+  - 核心需求是**企业级系统的无源码定制**（如金融、ERP）。
+  - 需**多DSL协同工作**（如数据模型+业务逻辑+前端），且希望编译期完成集成。
+  - 追求**逻辑的多模态表示**（文本、图形、表格自由切换）。
 
-- **选择MPS若**：  
-  - 需开发**复杂图形化DSL**（如工业控制、科学计算）。  
-  - 项目依赖**多语言动态混合**（如将领域语言嵌入通用语言）。  
-  - 团队可接受较高的初期开发成本，追求成熟的IDE支持。  
+- **选择MPS若**：
+  - 需开发**复杂图形化DSL**（如工业控制、科学计算）。
+  - 项目依赖**多语言动态混合**（如将领域语言嵌入通用语言）。
+  - 团队可接受较高的初期开发成本，追求成熟的IDE支持。
 
 ---
 
@@ -140,7 +185,7 @@ XLang和MPS都是强大的DSL开发工具，但它们在设计理念、实现方
 | **表示灵活性**    | 多模态等价表示（文本↔图形）               | 语法形式固定（需单独定义多表示）             |
 | **适用场景**      | 企业级系统复用、多DSL协同                | 多语言混合、复杂语法设计                  |
 
-**最终结论**：  
+**最终结论**：
 XLang与MPS分别代表了**“结构层差量驱动”**与**“语言层模块化设计”**两种技术路线，前者更适合需要无侵入定制和多DSL协同的企业场景，后者则擅长复杂语法和多语言动态混合的开发需求。两者在哲学和实现上互补，实际选型需结合项目目标与团队能力。
 
 
@@ -157,9 +202,9 @@ XLang语言和Jetbrains公司的MPS产品都聚焦于领域特定语言（DSL）
     - **MPS产品**：适用于各种需要快速创建和使用DSL的场景，尤其是对语言定制和可视化开发有较高要求的项目。在一些特定领域的软件开发中，如游戏开发、科学计算等，MPS可以帮助开发者快速创建适合该领域的专用语言，提高开发效率和代码可读性。MPS的可视化开发环境和与Jetbrains生态系统的集成，使得开发者能够充分利用已有工具和资源，降低学习成本，快速上手开发工作。
 4. **局限性与挑战**
     - **XLang语言**：目前XLang语言的应用范围相对较窄，主要依赖于Nop平台，在更广泛的开发者社区中的知名度和使用量有待提高。由于其理论基础涉及物理学和数学等跨学科知识，对于只熟悉传统计算机科学的开发者来说，理解和学习成本较高。
-    - **MPS产品**：MPS虽然提供了强大的功能，但它的学习曲线较陡，对于初学者来说，需要花费一定时间学习其复杂的语言定义和开发流程。MPS生成的代码可能存在一定的性能开销，在处理大规模、高性能要求的应用场景时，可能需要进行额外的优化工作。 
-	
-	
+    - **MPS产品**：MPS虽然提供了强大的功能，但它的学习曲线较陡，对于初学者来说，需要花费一定时间学习其复杂的语言定义和开发流程。MPS生成的代码可能存在一定的性能开销，在处理大规模、高性能要求的应用场景时，可能需要进行额外的优化工作。
+
+
 ## 通义千问
 Nop平台中的XLang语言和JetBrains公司的MPS（Meta-Programming System）产品都是为了支持领域特定语言（DSL, Domain Specific Language）的创建与使用而设计的，但它们在设计理念、实现方式和技术特点上有着明显的差异。以下是对两者进行深度对比的分析：
 
@@ -183,4 +228,85 @@ Nop平台中的XLang语言和JetBrains公司的MPS（Meta-Programming System）
 
 ### 总结
 
-虽然XLang和MPS都致力于解决领域特定语言的创建和使用问题，但它们采用了不同的方法论和技术手段。XLang更侧重于通过创新的程序结构空间和差量计算规则来支持快速开发和定制化，而MPS则强调通过抽象语法树和投影编辑技术来提供一个灵活、可视化的DSL开发环境。两种工具各有千秋，选择哪一种取决于具体的应用场景和个人或团队的技术偏好。对于追求快速迭代和高度定制化的项目，XLang可能更具吸引力；而对于需要跨语言支持和丰富编辑体验的项目，MPS则是更好的选择。	
+虽然XLang和MPS都致力于解决领域特定语言的创建和使用问题，但它们采用了不同的方法论和技术手段。XLang更侧重于通过创新的程序结构空间和差量计算规则来支持快速开发和定制化，而MPS则强调通过抽象语法树和投影编辑技术来提供一个灵活、可视化的DSL开发环境。两种工具各有千秋，选择哪一种取决于具体的应用场景和个人或团队的技术偏好。对于追求快速迭代和高度定制化的项目，XLang可能更具吸引力；而对于需要跨语言支持和丰富编辑体验的项目，MPS则是更好的选择。
+
+Projection Editor:
+Code in MPS is not text, but instead it is a projection of the abstract syntax (AST).
+
+Design Principles for Domain Specific Languages:
+1. Identify language uses early： 确定至少一个目标任务
+2. Ask questions： Who is going to model in the DSL? Who is going to review
+   the models? When? Who is using the models for which
+   purpose?
+3. Make your language consistent
+4. Decide carefully whether to use graphical or textual realization
+5. Compose existing languages where possible
+6. Reuse existing language definitions
+7. Reuse existing type systems
+8. Reflect only the necessary domain concepts
+9. Keep it simple
+10. Avoid unnecessary generality
+11. Limit the number of language elements
+12. Avoid conceptual redundancy
+13. Avoid inefficient language elements
+14. Adopt existing notations domain experts use
+15. Use descriptive notations
+16. Make elements distinguishable
+17. Use syntactic sugar appropriately.
+18. Permit comments.
+19. Provide organizational structures for models
+20. Balance compactness and comprehensibility
+21. Use the same style everywhere
+22. Identify usage conventions
+23. Align abstract and concrete syntax
+24. Prefer layout which does not affect translation from concrete to abstract syntax
+25. Enable modularity
+26. Introduce interfaces
+
+Internal DSL
+
+Characteristics
+    Embedded language: Internal DSLs are implemented within a general-purpose programming language, and they use base language syntax and competencies to target a specific domain problem.
+    Reusability: Existing knowledge and syntax are used from its base language to create domain-specific language.
+    Flexibility: GPL and DSL are well balanced in internal DSLs as they provide flexibility to use the host language’s regular syntax, which requires less development tools and efforts as compared to external DSLs.
+    Challenges: Internal DSLs are possibly less optimized than external DSLs for specialized tasks as they are limited to the structure of their base code.
+
+Advantages
+
+    Benefits the developers as they are familiar with the same language and have no need to learn the new language’s syntax
+    Reuse of existing libraries and tools from the base language helps in reducing the time requirement
+    Use of a wide range of libraries for writing internal DSLs
+
+Disadvantages
+
+    Internal DSLs are Constrained by the syntax of its host language
+    Making chaos by mixing Domain-specific language with general-purpose language.
+    Any modification in the project may affect the performance of internal DSL.
+
+
+External DSL:
+    Distinct language: the DSL and host languages used for specific tasks are separate from each other with their own syntax, semantics, and development tools.
+    Specialization: External DSLs are specialized in coordination with a particular problem domain resulting in efficient solutions for specific domain problems.
+    Consistency: As a result of isolation from the host language external DSLs provide data safety and increase accuracy.
+    Challenges: DSL has a learning curve as it possesses challenges for learning new languages and their syntax which may require additional time and effort.
+
+Advantages
+    Specialized code results in resourceful and communicative solutions to targeted problem
+    Language separation yields a lower error rate
+    External DSLs have their development tools, compiler, and IDE support.
+
+Disadvantages
+    Merging different languages decreases the accuracy
+    DSL for one project cannot be used in any other program hence limiting code flexibility.
+    The overhead cost of maintaining external DSLs and development tools.
+
+[Shadow Models: Incremental Transformations for MPS](http://voelter.de/data/pub/SLE2019.pdf)
+The name is motivated by the realization that many analyses are easier to do on an model whose structure is different from what the user edits.
+A problem when representing information formally with models is that different tasks suggest different representations of the same information
+
+Transformation DSL The language is functional: each function takes one or more source nodes as input and produces one or more output nodes.
+局部结构变换
+he result of the transformation can either be analyzed directly on the INode structure or after materializion to an MPS AST (through another COW). The latter is slower,
+but has the advantage that existing MPS analyses (such as type checks) can be used unchanged; it is also the basis for visualization in the editor.
+
+MPS models are trees with cross-references (or: graphs with a single containment hierarchy).
diff --git a/src/faq/faq.md b/src/faq/faq.md
@@ -684,3 +684,7 @@ prop级别实际上是在代码生成的时候根据`not-pub`标签生成了`pub
 ```
 对应的合并策略为  Result = E x-extends Model x-extends D x-extends C x-extends B x-extends Axml格式的模型文件，下划线开头的自动生成的源码，手动编写的源码，还有Generator工具等。其中模型文件对应DSL，那么Generator工具对应的就是公式中的Genetator吗？如果不是，那公式中的Generator对应的是Nop中的哪些部分？
 
+### 14. 企业级特别重视防御性编程 比如防腐层。有必要再去弄一个针对nop的防腐层吗
+
+Nop本身支持差量定制，可以在不修改Nop源码的情况下实现深度定制。这极大降低了对防腐层的需求。另外一般人的设计远达不到nop的程度，本身NopGraphQL和NopORM已经实现了最小化信息表达，自己再设计防腐层很难提供真正的变动隔离价值。Nop对于第三方包的依赖也非常小，基本不会因为第三方包的升级间接应用应用侧。不建议针对Nop设计防腐层。
+比如说，Nop的XML解析器没有使用JDK内置的，而是自己手工编写的解析器，性能高且没有复杂特性带来的安全漏洞
