... | ... | @@ -186,6 +186,11 @@ Parsing is a bit of a nightmare for this new language and will require some comp |
|
|
- What name to choose for `*`? `TYPE` would appear plenty in code, and it seems a little rude. Choosing a new symbol just kicks the can down the road. Choosing `Type` would conflict with lots of code (including GHC's) that uses a type `Type`. Choosing `T` would conflict with lots of (example) code that uses `T`. The best option I'm aware of is `U`, short for universe. Mitigating this problem somewhat is that Dependent Haskell would come with kind synonyms, and whatever name we choose would be a "normal" name exported from the `Prelude` and could be hidden if desired.
|
|
|
- What is our migration strategy? One proposal: introduce the new name now and keep `*` around. Then, when Dependent Haskell is ready for release, it will come with a new extension flag which will change the parsing of `*`. Only when that flag is enabled would `*` fail to work. It is unclear whether it is worth it to fully squash `*` out of the language.
|
|
|
|
|
|
> **UPDATE:** In a conversation with the denizen's of UPenn's Levine 513, I came up with a nice, clean way to have our cake and eat it too. It all hinges upon the fact that the parser can't currently figure out fixities of operators. While the actual implementation may differ in the details, the parser has to treat `foo bar !# baz %% bum bimini` as just a list of tokens. Only after we rename are the operators resolved to entities with known fixities.
|
|
|
|
|
|
>
|
|
|
> With this in mind, we can just introduce a new fixity: `prefix`. During the transformation of an expression such as that above into a proper AST with correct precedence, we just treat an operator with the `prefix` fixity just like an alphanumeric identifier. Then, the kind `*` just has `prefix` fixity, and we're done with it. For backward compatibility, this `*` would have to be exported from the `Prelude`. There would be a name clash with types named `*`, but Haskellers know how to deal with name clashes already. Backward compatibility might compel us to do something clever in the renamer in the `-XNoDependentTypes` case, but that's OK.
|
|
|
|
|
|
- The type language and the term languages are more different. There are two proposals on the table to deal with types embedded in terms:
|
|
|
|
|
|
- **Keep the parsers separate**: Since the parsers are separate and the parser certainly doesn't know anything about types, we need some indication in the code as a signal to the parser to switch to the type parser. Due to the construction of GHC's parser, this indicator would have to come *before* the phrase in question.
|
... | ... | |