Open Language Design Areas and Checklist

NoteDesign backlog, not a feature checklist

This early checklist preserves open questions that shaped RiX. Many individual items now have implemented answers in the evaluator and current guides; an unchecked box does not mean the feature is absent. Use it to identify areas that may deserve a fresh design record, and use the implementation status for current capability claims.

This checklist identifies further topics for the mathematical language specification.

---

1. Error Handling and Exceptions

• How are errors surfaced (e.g., division by zero, type errors, undefined variables)?
• Null vs. Error: When does each apply? (Soft fail vs. hard stop)
• Are there custom error objects or stacks?
• Can users catch/handle errors? (e.g., Try { ... } Catch { ... })
• How are warnings delivered?

2. Type System and Coercion Rules

• When and how does implicit vs. explicit type conversion occur?
• What are the rules for type mixing (e.g., integer + rational, rational + interval, array + set)?
• What counts as equality? (e.g., 3 == 3.0, [1,2] == {1,2})
• Can variables have type annotations? Or is everything inferred?

3. Variable Scope and Lifetimes

• How are variables scoped? (Block, local, global, module?)
• Can inner blocks shadow outer variables?
• Are there rules for garbage collection or when values are released?

4. Modules, Imports, and Namespaces

• How is code organized and reused? (E.g., via Load("foo"))
• Are there namespaces or module objects?
• How are naming conflicts resolved between user/system/module variables?

5. Standard Library and Environment

• What functions and types are always available?
• How is the help system invoked or extended?
• Can system/module functions be extended or overridden?

6. Input/Output and Interactivity

• How is user input read? (Prompt, file, stream)
• How is output controlled? (Print, return, logging)
• Are side effects allowed? Or is everything pure by default?

7. Concurrency and Asynchronous Code

• Can code be executed asynchronously or in parallel?
• Are there language primitives for “tasks,” “promises,” etc.?
• Is this left to the host language/environment?

8. Numeric Precision and Limits

• Are there upper/lower bounds on rationals, intervals, decimals?
• Can overflow/underflow occur? How is it handled?
• How is numeric precision for real/irrational numbers specified, controlled, or displayed?

9. User-Defined Syntax and Macros

• Can users define custom operators, infix notation, or macros?
• Can users extend system syntax (e.g., add block types, infix operators)?

10. Comments and Documentation

• Are there conventions for doc-comments or inline documentation?
• How can documentation be associated with code, functions, modules?

11. Testing and Debugging

• How can code be tested interactively or in batch mode?
• Are there built-in assert, test, or debugging features?
• How is error reporting managed (location, format)?

12. Versioning and Compatibility

• How are language or standard library versions tracked?
• Can modules declare a required or expected version?

---

Meta-Language and Grammar

• Is there a canonical grammar specification? (Pratt, EBNF, etc.)
• Is whitespace significant outside strings/comments?
• How are ambiguities or parsing conflicts resolved?

---

Use this document as a living reference to guide ongoing language design, implementation, and documentation.