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

Fix for #flat_map #504

Merged
merged 2 commits into from
Mar 8, 2022
Merged

Fix for #flat_map #504

merged 2 commits into from
Mar 8, 2022

Conversation

soutaro
Copy link
Owner

@soutaro soutaro commented Mar 8, 2022

Enumerable#flat_map haven't type checked as expected in Steep.

# def flat_map: [A] () { (Element) -> (A | Array[A]) } -> Array[A]

[1,2,3].flat_map {|x| [x.to_s] }          # Steep infers Array[Array[String]] while we need Array[String] here

This is because the subtyping relationship Array[String] <: (A | Array[A]) resolves to a substitution of A == Array[String]. If it resolves to a substitution of A == String, the type checking will work.

So, we'd like to introduce a function #hole_path. It takes two arguments, type and type variables, and returns the shortest path to unknown variable. Giving higher precedence to types with longer path will result more specific (smaller) type variable assignment.

This depends on two intuitions (without any proof):

  1. Specific type is better (A == String is better than A == Array[String])
  2. Longer #hole_path implies more specific type

Fingers crossed that this gives a better result.

@soutaro soutaro marked this pull request as ready for review March 8, 2022 12:38
@soutaro soutaro merged commit cdcf29c into master Mar 8, 2022
@soutaro soutaro deleted the flat-map branch March 8, 2022 12:38
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.

1 participant