Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Defer monomorphization for data constructors #4376

Merged
merged 3 commits into from Apr 22, 2023

Conversation

purefunctor
Copy link
Member

@purefunctor purefunctor commented Aug 1, 2022

Description of the change

Related to #4235. This defers the monomorphization of data constructors introduced by #835. As such, constructors now infer to their "true" type, instead of having to go through generalization.

> :t Nothing
forall (a :: Type). Maybe a

Checklist:

  • Added a file to CHANGELOG.d for this PR (see CHANGELOG.d/README.md)
  • Added myself to CONTRIBUTORS.md (if this is my first contribution)
  • Linked any existing issues or proposals that this pull request should close
  • Updated or added relevant documentation
  • Added a test for the contribution (if applicable)

@purefunctor

This comment was marked as resolved.

@purefunctor purefunctor changed the title Infer polymorphic types for type constructors Defer monomorphization for data constructors Aug 1, 2022
@purefunctor purefunctor force-pushed the poly-ctor branch 2 times, most recently from e23ccb4 to bb976a0 Compare August 2, 2022 02:19
@rhendric
Copy link
Member

This PR hasn't gotten much conversation yet, so I guess I'll stop waiting for someone else to ask smart questions and instead start asking stupid questions.

Why do we want this? Is it just to make the implementation of #4235 easier or simpler, or does it fix an independent issue?

What exactly is happening here? The changelog indicates that the inferred type of Nothing goes from forall a1. Maybe a1 to forall a. Maybe a, which from a naive reading sure looks like an alpha conversion. I suppose at the level of types in the compiler instead of types in the source language, I'm meant to know that a1 is a skolem and a is a type variable. Even so, how are those types handled differently?

Are there downsides or is there an argument that this is unambiguously what we should have been doing all along?

@MonoidMusician
Copy link
Contributor

The issue in the VTA context was briefly mentioned here:
#4235 (comment)

The issue is that the re-generalization would discard the VTA information, even though the constructors supported VTA by definition.

@rhendric
Copy link
Member

Sure, but would we still want this change in the (probably counterfactual) world where we decide not to implement VTA? If so, why; if not, what consequences does this have for things that are not related to VTA?

@purefunctor
Copy link
Member Author

Outside of #4235, this effectively just removes some historic baggage introduced by #835 and reworks a part of #2625 to accommodate for constructors. I don't think it ever came up in discussion back then but it's also just nice having constructors infer w/o the numeric suffixes 😄

@purefunctor purefunctor mentioned this pull request Feb 16, 2023
5 tasks
@purefunctor purefunctor merged commit 284cefc into purescript:master Apr 22, 2023
7 checks passed
@purefunctor purefunctor deleted the poly-ctor branch April 22, 2023 04:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants