Skip to content

Represent class dictionaries as data types#3567

Closed
garyb wants to merge 1 commit intopurescript:masterfrom
garyb:class-representation
Closed

Represent class dictionaries as data types#3567
garyb wants to merge 1 commit intopurescript:masterfrom
garyb:class-representation

Conversation

@garyb
Copy link
Copy Markdown
Member

@garyb garyb commented Mar 18, 2019

Resolves #781

The typechecking aspect of this works perfectly now, since #3128 (... that was Oct 2017? 😱 I thought it was fairly recent)

There are two failing tests that shouldn't be too hard to fix:

  • Error message for cyclic type class #3381 will fix one of them (there's a case that should fail due to a cycle in classes, but since there are no synonyms associated with classes anymore it's uncaught now)
  • Something needs updating in the IDE code so it doesn't import the data types for classes as data types

And there are two TODOs

  • Avoid duplicate case desugaring by not using sugar in desugarTypeClasses
  • Don't assume that superclasses can be taken from a dictionary by using an Accessor, as that assumes the implementation of types is record-like in the codegen target

@hdgarrood
Copy link
Copy Markdown
Contributor

Do you think we should try to get #3381 merged before or after this?

@garyb
Copy link
Copy Markdown
Member Author

garyb commented Mar 18, 2019

I'm fine with it either way - there should be no conflicts if that goes in first though, whereas if I do something in here there probably will be something to resolve.

This PR will probably be on hold for a couple of days anyway, I was talking to Christoph about some stuff to do with externs, so I'm probably going to make a PR changing some things there before coming back to this (it's also relevant to this PR - should help fix the IDE failure case).

@garyb
Copy link
Copy Markdown
Member Author

garyb commented Jun 9, 2019

I'll try and bash this back into shape. I got sucked down a wormhole when I started tinkering with the externs and lost sight of the primary goal, then life happened, etc.

Making the externs carry just what is necessary (rather than including additional compiler generated stuff that could instead be regenerated on load) will be a fairly decent chunk of work on its own I think.

@JordanMartinez
Copy link
Copy Markdown
Contributor

Should this be closed in favor of #4125?

@garyb garyb closed this Jul 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Represent typeclasses as data constructors in functional core

3 participants