... | ... | @@ -118,7 +118,7 @@ These notes are based on the proposed implementation at [ https://phabricator.ha |
|
|
>
|
|
|
> Both datatypes are currently kept abstract so only GHC can create new values. I think this is the "right" thing to do as it makes the types more trustworthy, but perhaps there's a good argument for allowing users to update `SrcLoc`s and `CallStack`s.
|
|
|
|
|
|
- GHC completely ignores the name of an implicit CallStack parameter, e.g.
|
|
|
- GHC ignores the name of an implicit CallStack parameter, e.g.
|
|
|
|
|
|
```wiki
|
|
|
f = show (?loc :: CallStack)
|
... | ... | @@ -130,14 +130,14 @@ These notes are based on the proposed implementation at [ https://phabricator.ha |
|
|
g = show (?location :: CallStack)
|
|
|
```
|
|
|
|
|
|
are both valid. But furthermore, in
|
|
|
are both valid. However, we will only push a new call-site onto an existing stack **if** the names match, e.g. in
|
|
|
|
|
|
```wiki
|
|
|
f :: (?loc :: CallStack) => IO ()
|
|
|
f = print (?location :: CallStack)
|
|
|
```
|
|
|
|
|
|
the printed call-stack will **also include**`f`s call-site. This last example might be unsettling to some. I think the behavior will ease creation of cross-package call-stacks, but could be convinced that it veers too far from what users would expect of ImplicitParams.
|
|
|
the printed call-stack will **not include**`f`s call-site.
|
|
|
|
|
|
- Responding to the open question above, GHC will **never** infer an implicit CallStack constraint.
|
|
|
|
... | ... | |