Section on named parameters #13
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR introduces comprehensive documentation for Fram's named parameters mechanism, covering parametric polymorphism, type schemes, and various parameter types. The documentation explains how named parameters enable advanced programming features like existential types, record types, and ML-like module systems.
Key changes:
- Introduces parametric polymorphism and type schemes with both anonymous and named type parameters
- Documents regular named parameters, optional parameters (prefixed with
?), and implicit parameters (prefixed with~) - Explains sections for grouping definitions with common parameters and Rank-N types for higher-order functions
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull Request Overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| Type parameters presented in previous section are *anonymous*, i.e., their | ||
| names are not visible outside the definition. Indeed, the programmer has no | ||
| means to specify the names of type parameters implicitly introduced by ML-style |
There was a problem hiding this comment.
Changed 'implicitly' to 'explicitly' - type parameters introduced by ML-style inference are implicit, not specified explicitly.
| that is the same as an existing type in the current scope. In order to avoid | ||
| name clashes, the name visible in the scheme might be different from the name | ||
| of the type parameter used within the function body. For example, assume that |
There was a problem hiding this comment.
[nitpick] The explanation of name shadowing could be clearer. Consider rephrasing to: 'to avoid name clashes, the name visible in the scheme can be different from the name of the type parameter used within the function body.'
| that is the same as an existing type in the current scope. In order to avoid | |
| name clashes, the name visible in the scheme might be different from the name | |
| of the type parameter used within the function body. For example, assume that | |
| that is the same as an existing type in the current scope. To avoid name clashes, the name visible in the scheme can be different from the name of the type parameter used within the function body. For example, assume that |
Description of a mechanism of named parameters in Fram.
The controversial decision is to include parametric polymorphism and Rank-N types in this chapter. Maybe we could move them to a separate chapter, but I don't have an idea how to do that: named parameters rely on type-schemes, but description of Rank-N without named parameters doesn't make much sense.
The other thing that is not clear to me is where to describe methods. Should it be in this chapter, or a separate one? I would rather prefer a separate chapter, but it will be quite short chapter.