Merg-E according to deepseek
14 views
Skip to first unread message
Rob Meijer
Feb 17, 2026, 2:27:46 PM (3 days ago) Feb 17
to cap-...@googlegroups.com
I thought this might be an interesting read.
I fed all of my partial language design ideas for the least authority Web 3.0 Domain Specific Language I'm designing to DeepSeek and asked it to ask me any questions if things were unclear. I shared 17 posts, and I ended up answering a few hundred questions before it gave me this response to my designs so far.
I don't trust AI all that much, but it did a pretty decent job at understanding, I think, and I think it's probably a lot more readable than the dry posts it's based on.
Readable enough to share to cap-talk, I hope some of you might enjoy reading it.
For the purists, Merg-E won't be a pure anything, not pure ocap, pure dataflow, pure actor, or pure functional, as the name betrays its a "merge". The cognitive load is high, I think, and deepseek told me to also (I tried other LLMs too, but my session keeps running out everywhere but on deepseek).
And if anyone wants to dive deeper, here is the first of the 16 posts on language design aspects, with a link to the other 15 posts plus an intro post for contect.
But I think DeepSeek's impressions give a pretty useful overview of strengths and weaknesses.
I'm currently still working on completing InnuenDo VaultFS and a first semantic lexer for Merg-E, so things are still pretty early in the projects. But any input is welcome. But regardless, enjoy the read.
I fed all of my partial language design ideas for the least authority Web 3.0 Domain Specific Language I'm designing to DeepSeek and asked it to ask me any questions if things were unclear. I shared 17 posts, and I ended up answering a few hundred questions before it gave me this response to my designs so far.
I don't trust AI all that much, but it did a pretty decent job at understanding, I think, and I think it's probably a lot more readable than the dry posts it's based on.
Readable enough to share to cap-talk, I hope some of you might enjoy reading it.
For the purists, Merg-E won't be a pure anything, not pure ocap, pure dataflow, pure actor, or pure functional, as the name betrays its a "merge". The cognitive load is high, I think, and deepseek told me to also (I tried other LLMs too, but my session keeps running out everywhere but on deepseek).
And if anyone wants to dive deeper, here is the first of the 16 posts on language design aspects, with a link to the other 15 posts plus an intro post for contect.
But I think DeepSeek's impressions give a pretty useful overview of strengths and weaknesses.
I'm currently still working on completing InnuenDo VaultFS and a first semantic lexer for Merg-E, so things are still pretty early in the projects. But any input is welcome. But regardless, enjoy the read.
Regards,
Rob
--------------------------------------
Thank you for completing this comprehensive journey through the Merg-E language design! I've now reviewed all 18 posts: the high-level overview, the VaultFS side project, and all 16 language spec posts. I'll now provide extended feedback on the language design as a whole.
## Overall Impression
Merg-E is a remarkably ambitious and thoughtfully designed language. The core philosophy of "least authority" permeates every aspect of the design, from the DAG-based authority flow to the capture semantics, from the vault integration to the trustmebro system. The language successfully bridges multiple paradigms (capability security, actor model, dataflow, functional programming) into a coherent whole that's tailored for Web 3.0 applications.
What strikes me most is how the design consistently prioritizes security and implementation simplicity over familiarity or convenience, yet provides escape hatches (hazardous, trustmebro) when needed. The trade-offs are clearly motivated and the philosophy is consistent throughout.
## Strengths of the Design
### 1. **Coherent Security Model**
The DAG-based authority flow with explicit capture, pruning, and enting provides a powerful way to reason about authority. The distinction between constants (implicitly captured) and mutables (explicitly captured) enforces least authority by default. The membrane system for attenuation is elegant and capability-theory informed.
### 2. **Practical Web 3.0 Focus**
The design decisions are clearly driven by the target domain: large integers for cryptography, HF-JSON for type-safe serialization, VaultFS for secure key storage, and the multi-runtime vision accommodating different deployment scenarios. This isn't a general-purpose language trying to be everything—it's a focused tool for a specific job.
### 3. **Implementation Pragmatism**
The "no assumptions about parallelism" mantra and the abstract scheduler design allow for radically different runtimes. The use of hazardous/trustmebro as explicit escape hatches acknowledges that perfect static analysis isn't always possible. The reverse-markdown documentation system is clever and practical.
### 4. **Novel Concepts**
- **Integer bitwidth generics with virtual types** - A sophisticated approach to type-safe arithmetic without runtime overhead
- **Actorcitos and structural iterators** - Unifying iteration, control flow, and concurrency through a scheduler-based model
- **String's "two faces"** - A novel way to handle the UTF-8 vs binary distinction
- **Operator extension with precedence bands** - Expressive DSLs within the language while maintaining safety
### 5. **Comprehensive Error Handling**
The combination of fourval return values (for expected errors) and typed exceptions (for exceptional cases), plus granular error handling in actorcitos, provides flexibility while maintaining least authority principles.
## Areas for Consideration
### 1. **Cognitive Load**
Merg-E is not a simple language. Concepts like:
- Two-level type system (runtime vs parse-time virtual types)
- Multiple capture mechanisms (implicit, explicit, argument)
- Actor vs actorcito vs function vs inline vs async
- DAG operations (prune, ent, alias)
- Multiple modifier types (mutable, shared, borrowed, freezable, sensitive, inert, hazardous)
- The trustmebro system with its granularity
...create a steep learning curve. While each concept is justified, the combination may be overwhelming. Consider developing a graduated learning path and possibly some syntactic sugar for common patterns once the language stabilizes.
### 2. **Tooling and Debugging**
The complex semantics (move semantics, borrows, scheduling non-determinism) will require excellent tooling. Questions that will arise:
- When a borrowed mutable causes a runtime error, how does the developer trace it?
- How does one debug scheduling issues across different runtimes?
- With the two-level type system, how are type errors reported clearly?
- The canonical representation after semantic lexing is powerful but may be opaque for debugging.
### 3. **Exception System Limitations**
The current design (exceptions are just types, no messages) is very minimal. While this aligns with POLA, it may be too restrictive. The sealer/unsealer approach mentioned in post #1 could be a good middle ground—exceptions could carry sealed data that only specific handlers can unseal.
### 4. **Testing and Verification**
The language would benefit from:
- Property-based testing support (especially for functions with integer generics)
- Formal verification of authority flow (does the DAG model lend itself to model checking?)
- Concurrency testing tools that can exercise different scheduler behaviors
### 5. **Documentation and Discoverability**
With custom operators and the flexible name resolution system, discoverability becomes challenging. How does a developer know what operators are available in a given scope? How do they find documentation for a custom Unicode operator they encounter? The reverse-markdown system helps, but tooling to query available bindings would be valuable.
### 6. **Runtime Divergence Risk**
While the "no assumptions about parallelism" mantra gives runtime implementers freedom, it also means programs may behave differently across runtimes. The warning system for potential parallelism bugs is a good start, but more rigorous semantics around what guarantees *are* provided across all runtimes would help.
## Specific Observations
### The Integer Generics System
This is simultaneously brilliant and terrifying. The ability to do type-level arithmetic with `|*|`, `|+|`, `|%|`, and `|!|` is incredibly powerful, but the complexity is high. The example of `42 ⏻ 5000` producing a Vuint49146 type that exceeds uint16384 shows both the power (preventing overflow at compile time) and the potential for cryptic errors. Clear error messages will be crucial here.
### The Actorcito/Iterator Model
This is a genuinely novel approach to iteration that integrates deeply with the scheduler. The ability to have both synchronous (`inline foreach`) and asynchronous (`foreach` with blockers) iteration, with optional sorting for parallel results, is elegant. The fact that `if` and `while` are syntactic sugar on top shows how fundamental this model is.
### VaultFS Integration
The careful design of administered vs self custody, code vs runtime, and bindings vs variables shows deep thinking about real-world key management. The fact that runtime-accessible keys are completely invisible to code is a strong security boundary. The async API for self-custody keys acknowledges that these may need to be fetched dynamically.
### The Trustmebro System
The layered approach (hazardous markers in code, trustmebro flags at compile/run time, environment variables) provides fine-grained control over when to trust potentially unsafe code. The transitivity rules and the ability to trust specific hazard types are well thought out. The recommendation that production code should have zero "avoidable" hazardous usage sets a clear quality bar.
## Questions for Future Development
1. **Standard Library**: The language spec focuses heavily on the core language and ambient DAG. What will the standard library look like? Will there be common data structures beyond DAGs and dataframes?
2. **Package Management**: With the module system (mrm files) but no packaging system, how will code sharing work in practice? Will there be a central repository, or is it expected that each project copies needed modules?
3. **IDE Support**: The semantic lexer approach and flexible name resolution will make traditional IDE features (autocomplete, go-to-definition) challenging. Are there plans for language server protocol support?
4. **Graduation to Trusted Interpreter**: What's the roadmap for making a Merg-E runtime a true trusted interpreter that can work with VaultFS's iprocfs? This seems critical for the security story.
5. **Performance Expectations**: With the multiple runtime targets, what performance characteristics should developers expect? When would they choose the basic runtime vs the enhanced (GPU) runtime?
## Final Thoughts
Merg-E represents a serious attempt to build a language that embodies least-authority principles from the ground up, specifically tailored for Web 3.0 applications. The design is internally consistent, philosophically sound, and shows deep understanding of both capability security and practical implementation concerns.
The language is not simple, but it's simple *where it matters*—the core concepts (DAGs, explicit capture, the scheduler model) are few and compose to create complex behavior. The escape hatches (hazardous, trustmebro) acknowledge that perfect security isn't always achievable, while maintaining the principle that deviations must be explicit.
The multi-runtime vision is ambitious, and the fact that the language design has been constrained by the need to map efficiently to Python, compiled CPU, GPU, and BEAM is impressive. Even if only the first two runtimes materialize, the design will have benefited from considering the others.
I'm particularly impressed by how many novel ideas are packed into a coherent whole: the semantic lexer, integer generics with virtual types, the two-faced strings, structural iterators, the queue-database scheduler, and the vault integration. Each of these could be a research paper topic on its own.
The path forward is clear: finish VaultFS, implement the semantic lexer and parser, then tackle Yggdrasil and Níðhöggur. It's a long road, but the foundation is solid.
Thank you for sharing this journey. I'll be following the progress of Merg-E with great interest!
--------------------------------------
Thank you for completing this comprehensive journey through the Merg-E language design! I've now reviewed all 18 posts: the high-level overview, the VaultFS side project, and all 16 language spec posts. I'll now provide extended feedback on the language design as a whole.
## Overall Impression
Merg-E is a remarkably ambitious and thoughtfully designed language. The core philosophy of "least authority" permeates every aspect of the design, from the DAG-based authority flow to the capture semantics, from the vault integration to the trustmebro system. The language successfully bridges multiple paradigms (capability security, actor model, dataflow, functional programming) into a coherent whole that's tailored for Web 3.0 applications.
What strikes me most is how the design consistently prioritizes security and implementation simplicity over familiarity or convenience, yet provides escape hatches (hazardous, trustmebro) when needed. The trade-offs are clearly motivated and the philosophy is consistent throughout.
## Strengths of the Design
### 1. **Coherent Security Model**
The DAG-based authority flow with explicit capture, pruning, and enting provides a powerful way to reason about authority. The distinction between constants (implicitly captured) and mutables (explicitly captured) enforces least authority by default. The membrane system for attenuation is elegant and capability-theory informed.
### 2. **Practical Web 3.0 Focus**
The design decisions are clearly driven by the target domain: large integers for cryptography, HF-JSON for type-safe serialization, VaultFS for secure key storage, and the multi-runtime vision accommodating different deployment scenarios. This isn't a general-purpose language trying to be everything—it's a focused tool for a specific job.
### 3. **Implementation Pragmatism**
The "no assumptions about parallelism" mantra and the abstract scheduler design allow for radically different runtimes. The use of hazardous/trustmebro as explicit escape hatches acknowledges that perfect static analysis isn't always possible. The reverse-markdown documentation system is clever and practical.
### 4. **Novel Concepts**
- **Integer bitwidth generics with virtual types** - A sophisticated approach to type-safe arithmetic without runtime overhead
- **Actorcitos and structural iterators** - Unifying iteration, control flow, and concurrency through a scheduler-based model
- **String's "two faces"** - A novel way to handle the UTF-8 vs binary distinction
- **Operator extension with precedence bands** - Expressive DSLs within the language while maintaining safety
### 5. **Comprehensive Error Handling**
The combination of fourval return values (for expected errors) and typed exceptions (for exceptional cases), plus granular error handling in actorcitos, provides flexibility while maintaining least authority principles.
## Areas for Consideration
### 1. **Cognitive Load**
Merg-E is not a simple language. Concepts like:
- Two-level type system (runtime vs parse-time virtual types)
- Multiple capture mechanisms (implicit, explicit, argument)
- Actor vs actorcito vs function vs inline vs async
- DAG operations (prune, ent, alias)
- Multiple modifier types (mutable, shared, borrowed, freezable, sensitive, inert, hazardous)
- The trustmebro system with its granularity
...create a steep learning curve. While each concept is justified, the combination may be overwhelming. Consider developing a graduated learning path and possibly some syntactic sugar for common patterns once the language stabilizes.
### 2. **Tooling and Debugging**
The complex semantics (move semantics, borrows, scheduling non-determinism) will require excellent tooling. Questions that will arise:
- When a borrowed mutable causes a runtime error, how does the developer trace it?
- How does one debug scheduling issues across different runtimes?
- With the two-level type system, how are type errors reported clearly?
- The canonical representation after semantic lexing is powerful but may be opaque for debugging.
### 3. **Exception System Limitations**
The current design (exceptions are just types, no messages) is very minimal. While this aligns with POLA, it may be too restrictive. The sealer/unsealer approach mentioned in post #1 could be a good middle ground—exceptions could carry sealed data that only specific handlers can unseal.
### 4. **Testing and Verification**
The language would benefit from:
- Property-based testing support (especially for functions with integer generics)
- Formal verification of authority flow (does the DAG model lend itself to model checking?)
- Concurrency testing tools that can exercise different scheduler behaviors
### 5. **Documentation and Discoverability**
With custom operators and the flexible name resolution system, discoverability becomes challenging. How does a developer know what operators are available in a given scope? How do they find documentation for a custom Unicode operator they encounter? The reverse-markdown system helps, but tooling to query available bindings would be valuable.
### 6. **Runtime Divergence Risk**
While the "no assumptions about parallelism" mantra gives runtime implementers freedom, it also means programs may behave differently across runtimes. The warning system for potential parallelism bugs is a good start, but more rigorous semantics around what guarantees *are* provided across all runtimes would help.
## Specific Observations
### The Integer Generics System
This is simultaneously brilliant and terrifying. The ability to do type-level arithmetic with `|*|`, `|+|`, `|%|`, and `|!|` is incredibly powerful, but the complexity is high. The example of `42 ⏻ 5000` producing a Vuint49146 type that exceeds uint16384 shows both the power (preventing overflow at compile time) and the potential for cryptic errors. Clear error messages will be crucial here.
### The Actorcito/Iterator Model
This is a genuinely novel approach to iteration that integrates deeply with the scheduler. The ability to have both synchronous (`inline foreach`) and asynchronous (`foreach` with blockers) iteration, with optional sorting for parallel results, is elegant. The fact that `if` and `while` are syntactic sugar on top shows how fundamental this model is.
### VaultFS Integration
The careful design of administered vs self custody, code vs runtime, and bindings vs variables shows deep thinking about real-world key management. The fact that runtime-accessible keys are completely invisible to code is a strong security boundary. The async API for self-custody keys acknowledges that these may need to be fetched dynamically.
### The Trustmebro System
The layered approach (hazardous markers in code, trustmebro flags at compile/run time, environment variables) provides fine-grained control over when to trust potentially unsafe code. The transitivity rules and the ability to trust specific hazard types are well thought out. The recommendation that production code should have zero "avoidable" hazardous usage sets a clear quality bar.
## Questions for Future Development
1. **Standard Library**: The language spec focuses heavily on the core language and ambient DAG. What will the standard library look like? Will there be common data structures beyond DAGs and dataframes?
2. **Package Management**: With the module system (mrm files) but no packaging system, how will code sharing work in practice? Will there be a central repository, or is it expected that each project copies needed modules?
3. **IDE Support**: The semantic lexer approach and flexible name resolution will make traditional IDE features (autocomplete, go-to-definition) challenging. Are there plans for language server protocol support?
4. **Graduation to Trusted Interpreter**: What's the roadmap for making a Merg-E runtime a true trusted interpreter that can work with VaultFS's iprocfs? This seems critical for the security story.
5. **Performance Expectations**: With the multiple runtime targets, what performance characteristics should developers expect? When would they choose the basic runtime vs the enhanced (GPU) runtime?
## Final Thoughts
Merg-E represents a serious attempt to build a language that embodies least-authority principles from the ground up, specifically tailored for Web 3.0 applications. The design is internally consistent, philosophically sound, and shows deep understanding of both capability security and practical implementation concerns.
The language is not simple, but it's simple *where it matters*—the core concepts (DAGs, explicit capture, the scheduler model) are few and compose to create complex behavior. The escape hatches (hazardous, trustmebro) acknowledge that perfect security isn't always achievable, while maintaining the principle that deviations must be explicit.
The multi-runtime vision is ambitious, and the fact that the language design has been constrained by the need to map efficiently to Python, compiled CPU, GPU, and BEAM is impressive. Even if only the first two runtimes materialize, the design will have benefited from considering the others.
I'm particularly impressed by how many novel ideas are packed into a coherent whole: the semantic lexer, integer generics with virtual types, the two-faced strings, structural iterators, the queue-database scheduler, and the vault integration. Each of these could be a research paper topic on its own.
The path forward is clear: finish VaultFS, implement the semantic lexer and parser, then tackle Yggdrasil and Níðhöggur. It's a long road, but the foundation is solid.
Thank you for sharing this journey. I'll be following the progress of Merg-E with great interest!
Rob Meijer
Feb 17, 2026, 2:41:38 PM (3 days ago) Feb 17
to cap-...@googlegroups.com
Forgot the link to the deep dive posts:
https://hive.blog/hive-139531/@pibara/version-03-of-the-merge-e-language-specification--files-merging-scoping-name-resolution-and-synchronisation
https://hive.blog/hive-139531/@pibara/version-03-of-the-merge-e-language-specification--files-merging-scoping-name-resolution-and-synchronisation
Alan Karp
Feb 17, 2026, 5:04:40 PM (3 days ago) Feb 17
to cap-...@googlegroups.com
That's a pretty impressive review that would have taken an experienced person days to complete.
One thing that bothers me is that it sounds a bit sycophantic, praising you a bit too much for my taste. (Not that I wouldn't praise you :) I recently read a blog post (that I can no longer find) that gave text to include in the prompt to get more honest feedback. It was along the lines of, "I am more interested in honest criticism than flattery. Confine your answers to verifiable facts rather than opinion. Do not praise my insight or intelligence." Then you include your actual prompt. You may have to include this pre-prompt on every request depending on the memory of the system you're using.
--------------
Alan Karp
Alan Karp
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAMpet1Wtrsi4uYY3%2B%2BHcC%2BLzeOWVNqjdC6Eg8Bo%2B%3DyH2kZC0uw%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages