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.

Sign up for GitHub

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

Jump to bottom

Analyze the impact of of using polymorphic labels in the standard library #4740

Closed
Marwes opened this issue May 11, 2022 · 0 comments
Closed

Analyze the impact of of using polymorphic labels in the standard library #4740

Marwes opened this issue May 11, 2022 · 0 comments
Assignees
@Marwes

Comments

@Marwes
Copy link
Contributor

Marwes commented May 11, 2022

Polymorphic labels were added in #4388 with a couple of example function signatures that utilize the feature. To be able to change the stable builtins to use polymorphic labels we need to evaluate how large the fallout would be.

DOD:

  • Provide alternate type signatures which use polymorphic labels for all builtins where it is useful (see Document what kind of type system features are lacking for builtin functions #4410 for an incomplete list)
  • When the label polymorphism feature is enabled do the typechecking with these signatures that use labels
  • Evaluate the impact by compiling a representative set of real-world queries to determine the regressions
@Marwes Marwes mentioned this issue May 11, 2022
Closed
@Marwes Marwes self-assigned this May 17, 2022
This was referenced May 19, 2022
Merged
Merged
Closed
Merged
Marwes pushed a commit that referenced this issue May 25, 2022
fix: Correct several issues found during #4740 (#4786)
6acd449 
* feat: Add a wrapper around flux's error which uses the prettier string representation

* chore: Print prettier errors when failing to compile the standard library

* feat: Allow an AnalyzerConfig to be passed when compiling the standard library

* refactor: Allow matching on MonoType::STRING etc

* feat: Allow labels to be parsed in types

* fix: Allow label types to be in the exported API of a package

* fix: Don't display bound and unbound variables the same in record's tail position

* chore: make generate

* chore: Fix benchmark
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Marwes Marwes

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Marwes @nathanielc