Lean 4: Inaccessible Private Names After `import All`

Nov 19, 2025 by Alex Johnson 54 views

Lean 4: Understanding Inaccessible Private Names After `import all`

Have you ever encountered a situation in Lean 4 where you've used import all only to find that certain names from the imported module appear inaccessible? This can be a perplexing issue, especially when you expect all names to be available. Let's delve into the specifics of this behavior, understand why it occurs, and explore how to address it effectively. This comprehensive guide aims to clarify the nuances of module imports and name visibility in Lean 4, ensuring a smoother and more intuitive coding experience. By the end of this article, you will have a solid grasp of how Lean 4 handles private names in imported modules and how to work around potential issues. Understanding these concepts is crucial for writing clean, maintainable, and efficient Lean 4 code. Let's explore the intricacies of name visibility and module imports in Lean 4, equipping you with the knowledge to tackle this issue head-on and write more robust and elegant code. With this understanding, you'll be better positioned to structure your projects effectively and avoid common pitfalls related to module imports and name resolution.

The Issue: Private Names and `import all`

When working with Lean 4, the import all command is a powerful tool for bringing all declarations from one module into another. However, it's crucial to understand that this command respects the privacy modifiers of the original module. This means that if a declaration is marked as private (using the private keyword or by being defined within a namespace), it will not be directly accessible in the importing module, even with import all. This design choice is intentional, aimed at promoting modularity and preventing unintended name clashes.

To illustrate this, consider the following scenario, similar to the one described in the original issue. Imagine you have a module A that defines a private name a:

-- A.lean
module A

private def a : Nat := 5

def public_function : Nat := a + 1 -- This is allowed within module A

Now, in another module B, you attempt to import everything from A using import all and try to access a:

-- B.lean
import A

-- This will result in an error because `a` is private
-- def try_to_access : Nat := a

This behavior is by design. Private names are intended to be internal implementation details of a module and should not be relied upon by external code. This helps to maintain encapsulation and allows a module's internal implementation to change without affecting other parts of the codebase.

Expected vs. Actual Behavior

The core of the issue lies in the discrepancy between what a user might expect and what Lean 4 actually does. When a user sees import all, they might assume that everything from the imported module is now available. However, Lean 4 maintains the distinction between public and private declarations. This means that while all public declarations are indeed imported, private declarations remain hidden. This behavior is consistent with the principles of good software design, where encapsulation and information hiding are paramount.

In the specific example provided in the original issue, the user expected the goal in the theorem a_eq to be displayed as a = 5. However, because a was accessed within the namespace A after importing A with import all, Lean 4 displayed the goal as A.a✝ = 5, indicating that it was referencing the private name A.a. This can be confusing because the user might not realize that they are dealing with a private name, leading to unexpected behavior and difficulties in proving the theorem. The crux of this issue is the unexpected visibility of private names in the goal view, which deviates from the typical understanding of import all.

Why Does This Happen? Understanding Name Visibility

To fully grasp why this happens, we need to understand how Lean 4 handles name visibility and namespaces. In Lean 4, declarations are organized within modules and namespaces. Namespaces provide a way to group related declarations under a common prefix, preventing name collisions and improving code organization. When you import a module, you bring its public declarations into the current scope, but private declarations remain hidden. This is a fundamental aspect of Lean 4's module system, ensuring that internal implementation details are not exposed.

Namespaces and Privacy

Namespaces play a crucial role in managing name visibility. When you define a declaration within a namespace, its fully qualified name includes the namespace prefix. For example, if you define def a : Nat inside the namespace A, its fully qualified name is A.a. This allows you to have declarations with the same name in different namespaces without conflict.

Private declarations, on the other hand, are only accessible within the module or namespace where they are defined. This means that if you declare private def a : Nat inside module A, it can only be accessed by other declarations within A. Even if you import module A into another module B, you cannot directly access A.a from B. This is a key mechanism for encapsulation, ensuring that internal details of a module remain hidden from external code.

The Role of `import all`

The import all command brings all public declarations from a module into the current scope. It's important to emphasize the word "public" here. Private declarations are explicitly excluded from this process. This behavior is consistent with the principles of modularity and information hiding. By preventing access to private declarations, Lean 4 ensures that modules can evolve their internal implementation without breaking external code that depends on them. This makes it easier to maintain and refactor large Lean 4 projects.

In the context of the original issue, the confusion arises because the user expects import all to make everything accessible. However, Lean 4 intentionally limits the scope of import all to public declarations only. This is a deliberate design choice that promotes better code organization and maintainability. While it might seem counterintuitive at first, this behavior is essential for building robust and scalable Lean 4 projects. By understanding the distinction between public and private declarations, you can avoid common pitfalls and write more modular and maintainable code.

Addressing the Issue: Solutions and Workarounds

Now that we understand why private names are not directly accessible after using import all, let's explore some solutions and workarounds. There are several strategies you can employ to address this issue, depending on your specific needs and the structure of your project. Each approach has its own trade-offs, so it's important to choose the one that best fits your situation.

1. Accessing Private Names within the Module

The most straightforward solution is to access the private name within the module where it is defined. If you need to use a private declaration in a function or theorem, define that function or theorem within the same module or namespace as the private declaration. This ensures that you have direct access to the private name without violating the encapsulation principles.

For example, if you have a private declaration private def a : Nat in module A and you need to use it in a function, define that function within module A as well:

-- A.lean
module A

private def a : Nat := 5

def use_a : Nat := a + 1 -- This is allowed

end A

This approach is the most consistent with the principles of encapsulation and modularity. It ensures that private declarations remain internal to the module and are not exposed to external code. However, it might require you to reorganize your code to keep related functionality within the same module.

2. Creating Public Accessors

If you need to access a value that is derived from a private declaration but don't want to expose the private declaration itself, you can create a public accessor function. This function acts as a controlled interface to the private data, allowing you to access it in a safe and predictable way.

For example, if you have a private declaration private def a : Nat and you want to expose its value, you can define a public function that returns the value of a:

-- A.lean
module A

private def a : Nat := 5

def get_a : Nat := a -- Public accessor

end A

Now, from another module, you can import A and access the value of a using A.get_a:

-- B.lean
import A

def use_a : Nat := A.get_a + 1

This approach provides a good balance between encapsulation and accessibility. You can control how the private data is accessed and ensure that external code does not depend on the internal implementation details of your module. This makes it easier to refactor your code in the future without breaking external dependencies.

3. Re-declaring with a Public Name

In some cases, you might want to make a declaration public after it has been defined as private. You can achieve this by re-declaring the declaration with a public name. This essentially creates a public alias for the private declaration.

For example, if you have a private declaration private def a : Nat and you want to make it public, you can re-declare it as follows:

-- A.lean
module A

private def a : Nat := 5

def a := a -- Re-declare as public

end A

Now, from another module, you can import A and access the value of a directly:

-- B.lean
import A

def use_a : Nat := A.a + 1

This approach is simple and straightforward, but it should be used with caution. It essentially bypasses the encapsulation provided by the private keyword, so it's important to ensure that exposing the declaration does not violate the design principles of your module. This approach is best suited for cases where you initially defined a declaration as private but later realized that it should be public.

4. Using `reveal` (Experimental)

Lean 4 provides an experimental command called reveal that allows you to temporarily expose private declarations within a specific scope. This can be useful for debugging or for writing proofs that require access to private details.

For example, you can use reveal to access the private declaration a in the original issue:

-- B.lean
import A

namespace A

#guard_msgs in
theorem a_eq : a = 5 := by
  reveal A.a
  trace_state
  sorry

end A

The reveal command makes A.a accessible within the scope of the theorem declaration. This allows you to inspect its value and use it in your proof. However, it's important to note that reveal is an experimental feature and might not be available in future versions of Lean 4. It should be used primarily for debugging and not as a general-purpose solution for accessing private declarations.

Choosing the Right Approach

The best approach for addressing the issue of inaccessible private names depends on your specific needs and the context of your project. Here’s a summary of the trade-offs:

Accessing Private Names within the Module: This is the most principled approach and is consistent with good software design. It ensures encapsulation and prevents external code from depending on internal implementation details. However, it might require you to reorganize your code.
Creating Public Accessors: This provides a good balance between encapsulation and accessibility. You can control how the private data is accessed and ensure that external code does not depend on the internal implementation details. This is a good option when you need to expose a value derived from a private declaration.
Re-declaring with a Public Name: This is a simple approach but should be used with caution. It bypasses the encapsulation provided by the private keyword and should only be used when you are sure that exposing the declaration does not violate the design principles of your module.
Using reveal (Experimental): This is a powerful tool for debugging but should not be used as a general-purpose solution. It is an experimental feature and might not be available in future versions of Lean 4.

By carefully considering these trade-offs, you can choose the approach that best fits your needs and ensures the maintainability and robustness of your Lean 4 code.

Best Practices for Module Imports and Name Visibility

To avoid confusion and ensure your Lean 4 code is clean and maintainable, it’s essential to follow some best practices regarding module imports and name visibility. These practices can help you write more robust and understandable code, reducing the likelihood of encountering issues related to private names and module dependencies. By adhering to these guidelines, you'll be able to structure your projects more effectively and collaborate more smoothly with others.

1. Be Explicit with Imports

While import all might seem convenient, it can lead to namespace pollution and make it harder to track where declarations are coming from. Instead, consider using selective imports to bring in only the declarations you need. This makes your code more explicit and easier to understand.

For example, instead of:

import all A

Use:

import A (a, b, c)

This makes it clear which declarations you are using from module A and avoids bringing in unnecessary names. Selective imports also help to prevent name clashes and make it easier to reason about your code. When you explicitly specify the declarations you need, you reduce the risk of accidentally shadowing existing names or introducing unexpected dependencies.

2. Use Namespaces Effectively

Namespaces are a powerful tool for organizing your code and preventing name collisions. Use them to group related declarations under a common prefix. This makes your code more modular and easier to navigate. Namespaces also play a crucial role in controlling name visibility, as they define the scope within which declarations are accessible.

For example, if you are working on a library for number theory, you might create a namespace called NumberTheory and define all related declarations within that namespace:

namespace NumberTheory

def prime : Nat → Bool := ...

def gcd : Nat → Nat → Nat := ...

end NumberTheory

This clearly separates your number theory code from other parts of your project and prevents name collisions with declarations in other modules. By using namespaces effectively, you can create a well-organized and maintainable codebase.

3. Minimize the Use of Private Declarations

While private declarations are essential for encapsulation, overusing them can make your code harder to work with. Consider whether a declaration truly needs to be private or if it could be made public without compromising the design of your module. If a declaration is used in multiple places within your module, it might be a good candidate for being public.

However, it's important to strike a balance between accessibility and encapsulation. Private declarations are crucial for hiding implementation details and preventing external code from depending on them. This allows you to change the internal workings of your module without breaking other parts of your project. Therefore, carefully consider the scope of each declaration and choose the appropriate visibility modifier based on its intended use.

4. Document Your Code

Clear and concise documentation is essential for making your code understandable and maintainable. Use docstrings to explain the purpose of each declaration, its arguments, and its return value. This helps other developers (and your future self) understand how to use your code and reduces the likelihood of misunderstandings related to name visibility and module imports.

For example:

namespace NumberTheory

/--
  `prime n` returns `true` if `n` is a prime number, and `false` otherwise.
-/ 
  def prime : Nat → Bool := ...

end NumberTheory

Good documentation is especially important for public declarations, as these are the entry points to your module. Explain the purpose of each public function, its expected inputs, and its potential side effects. This helps other developers use your code correctly and avoids common pitfalls. Additionally, consider documenting any assumptions or preconditions that your functions rely on. This makes your code more robust and easier to debug.

5. Test Your Code Thoroughly

Testing is crucial for ensuring that your code works as expected and that module imports and name visibility are handled correctly. Write unit tests to verify the behavior of individual functions and modules, and integration tests to ensure that different parts of your system work together seamlessly. This helps you catch errors early and prevents them from propagating to other parts of your codebase. Testing is also an invaluable tool for verifying encapsulation, ensuring that private members are not inadvertently accessed from outside the module.

By following these best practices, you can write cleaner, more maintainable Lean 4 code and avoid common issues related to module imports and name visibility. These guidelines are based on principles of good software design and are applicable to a wide range of projects. By incorporating these practices into your workflow, you'll be able to build more robust and scalable Lean 4 applications.

Conclusion

Understanding how Lean 4 handles private names and module imports is crucial for writing robust and maintainable code. The import all command, while convenient, does not expose private declarations, which is a deliberate design choice to promote encapsulation and modularity. By understanding this behavior and employing the solutions and best practices discussed in this article, you can effectively manage name visibility in your Lean 4 projects.

Remember that each solution has its trade-offs, and the best approach depends on your specific needs. Whether you choose to access private names within the module, create public accessors, re-declare with a public name, or use the experimental reveal command, the key is to be mindful of the implications for encapsulation and maintainability.

By following the best practices outlined in this article, such as being explicit with imports, using namespaces effectively, minimizing the use of private declarations, documenting your code, and testing thoroughly, you can ensure that your Lean 4 projects are well-structured, easy to understand, and resistant to errors. These practices will not only help you avoid issues related to private names but also contribute to the overall quality and scalability of your codebase. Keep exploring the power of Lean 4, and happy coding! For further reading on Lean 4's module system and more, check out the official Lean 4 documentation.