Make the types of expressions accessible in the API.
Needs ReviewPublic

Authored by nboldi on Aug 3 2018, 8:49 AM.

Details

Reviewers
goldfire
bgamari
Trac Issues
#15320
Summary

Added type to case expressions

Added type to 'let' expressions

Added type to 'lambda' and 'lambdacase' expressions

Added type to function applications, 'section' and 'tuple' expressions. Created 'hsExprType' function

Added type to operator application and type application expressions

Types for constructor application and brackets

Types for proc expressions

use the inferred types for variables

removing unneeded type annotations from if and let expressions

Added tests for the expression type checking.

Merging from master

Fix lint errors

nboldi created this revision.Aug 3 2018, 8:49 AM

I'm rather confused; didn't the discussion on the ticket indicate that this approach would be too costly in the typical compilation case to be acceptable?

nboldi added a comment.Aug 7 2018, 4:00 AM

I'm rather confused; didn't the discussion on the ticket indicate that this approach would be too costly in the typical compilation case to be acceptable?

The approach is similar to how calculation of the type of the patterns are implemented in hsPatType, the types of subexpressions saved when necessary, others are calculated by hsExprType.

I'm rather confused; didn't the discussion on the ticket indicate that this approach would be too costly in the typical compilation case to be acceptable?

The approach is similar to how calculation of the type of the patterns are implemented in hsPatType, the types of subexpressions saved when necessary, others are calculated by hsExprType.

Fair enough but I am still rather concerned by what this will do to compiler performance. Can you fix the validation issues so we can see what the performance tests look like?

nboldi updated this revision to Diff 17603.Aug 7 2018, 9:03 AM
  • Fixing validation errors
nboldi added a comment.Aug 8 2018, 8:49 AM

I think this version should be ok, but I don't really understand the build errors.

I think this version should be ok, but I don't really understand the build errors.

Are you sure you have the right haddock commit?

nboldi updated this revision to Diff 17856.Aug 29 2018, 6:22 AM
  • Fixing utils/haddock version
nboldi updated this revision to Diff 17857.Aug 29 2018, 6:49 AM
  • Fixing library submodules
bgamari requested changes to this revision.Jan 20 2019, 6:19 PM

@nboldi, do you intend on continuing work on this? If so do you suppose you could move it to GitLab?

This revision now requires changes to proceed.Jan 20 2019, 6:19 PM

Yes, I would like to integrate this. I need some pointers on what changes are requested to finish.

Yes, I would like to integrate this. I need some pointers on what changes are requested to finish.

Ultimately there are a few things that this will require:

  • a rebase onto current master
  • a run of the testsuite and nofib to evaluate the effect on compiler performance (residency in particular)
  • a mention in the release notes
nboldi added a comment.Feb 5 2019, 1:47 AM

I rebased to master and ran the tests:

When I would like to arc diff, it wants to upload all 400 commits I got from master. Is there a way to select the relevant commits?

I rebased to master and ran the tests:

Hmm, this is rather what I was afraid of. It looks like this has caused nearly all compiler performance tests to regress. Can you paste the full testsuite output?

When I would like to arc diff, it wants to upload all 400 commits I got from master. Is there a way to select the relevant commits?

Yes, you can invoke arc with an explicit base commit. For instance, if you have squashed

$ arc diff --update D5041 HEAD^
nboldi updated this revision to Diff 19297.EditedFeb 6 2019, 12:42 AM
  • Fixing validation errors
  • Rebased to master

Here are the compared nofib results:

Last update only shows the latest changes. I think the problem is that my commits are interleaved with other commits in the git log. Is there a way to arc diff specific commits?