It is slightly disheartening that this relatively simple use-case requires reaching so deeply into the typechecker.

If there really exusts no easier interface then perhaps we should consider adopting your elaborateExpr as part of the GHC API.

Cheers,

- Ben

On January 23, 2020 4:04:03 AM EST, Richard Eisenberg <rae@richarde.dev> wrote:
I don't know the exact semantics of the interactive context, etc., but that looks plausible. It won't give the *wrong* answer. :)

Thanks for sharing!
Richard

On Jan 23, 2020, at 4:52 AM, Yiyun Liu <liuyiyun@terpmail.umd.edu> wrote:

Thank you all for your help! It turns out that I was missing the constraint solving and zonking step by desugaring the result of tcInferSigma directly.

I have the implementation of the function here. Not sure if it's 100% correct but at least it works for all the examples I can come up with so far.

- Yiyun

On 1/22/20 7:09 AM, Andreas Klebinger wrote:
I tried this for fun a while ago and ran into the issue of needing to provide a type environment containing Prelude and so on.
I gave up on that when some of the calls failed because I must have missed to set up some implicit state properly.
I didn't have an actual use case (only curiosity) so I didn't look further into it. If you do find a way please let me know.

I would also support adding any missing functions to GHC-the-library to make this possible if any turn out to be required.

As an alternative you could also use the GHCi approach of using a fake Module. This would allow you to copy whatever GHCi is doing.
But I expect that to be slower if you expect to process many such strings,

Richard Eisenberg schrieb am 22.01.2020 um 10:36:
You'll need to run the expression through the whole pipeline.

1. Parsing
2. Renaming
3. Type-checking
  3a. Constraint generation
  3b. Constraint solving
  3c. Zonking
4. Desugaring



--
Sent from my Android device with K-9 Mail. Please excuse my brevity.