... | ... | @@ -96,6 +96,51 @@ And `type` gets an extra production: |
|
|
data a `Bar` b = a `BAR` b
|
|
|
```
|
|
|
|
|
|
## Issues
|
|
|
|
|
|
|
|
|
|
|
|
The second proposal—-to treat all infix operators as type constructors—-leads to an ambiguity in import/export declarations:
|
|
|
|
|
|
|
|
|
```wiki
|
|
|
module Test ( (+) ) where
|
|
|
```
|
|
|
|
|
|
|
|
|
This export declaration is ambiguous because it is not clear if we mean to export the value operator (+), the type constructor (+), or both.
|
|
|
A similar issue arises with imports.
|
|
|
|
|
|
|
|
|
|
|
|
One possible solution is to state that, when written on their own, infix operators in import/export specifications refer to the value level.
|
|
|
So in the above example we would be exporting the value operator (+).
|
|
|
|
|
|
|
|
|
|
|
|
To import/export the type constructor one would have to use an explicit (possibly empty) sub-ordinate list:
|
|
|
|
|
|
|
|
|
```wiki
|
|
|
module Test ( (+)() ) where
|
|
|
```
|
|
|
|
|
|
|
|
|
Unfortunately, such specifications look rather odd.
|
|
|
|
|
|
|
|
|
|
|
|
Another solution would be to introduce a new piece of syntax which would translate to the same thing. Perhaps:
|
|
|
|
|
|
|
|
|
```wiki
|
|
|
module Test ( type (+) ) where
|
|
|
```
|
|
|
|
|
|
|
|
|
The intention here is that `type` specifies the namespace of the following name, and not that it is a type synonym.
|
|
|
|
|
|
|
|
|
## References
|
|
|
|
|
|
|
... | ... | |