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

Generalize function applications #4030

Merged
merged 5 commits into from
Jul 21, 2024
Merged

Conversation

toots
Copy link
Member

@toots toots commented Jul 15, 2024

This PR improves function application type generalization. This fixes #3303.

In #3303, we discussed several cases where type generalization should and should not be done over a function application.

Here are a couple of examples:

Source type

s = single()
s : source('A)

Here, we cannot generalize the universal type of the source because it can be used with operators requiring different type of content, for instance:

enc = %ffmpeg(
  format="aac",
  %audio(codec="aac"),
)

# Here, type is source(audio=pcm)
output.file(fallible=true, enc, "/tmp/bla.mkv", s)

# Here type is source(audio=ffmpeg.copy('a))
ignore(ffmpeg.decode.audio(s))

Ref return

def f(x=null()) =
  ref(x)
end
f : (?'a?) -> (() -> 'a?).{set : ('a?) -> unit}

If we generalize the returned value of this function, we end up with a reference cell to which we can assign values of any type:

r = f()
r : (() -> 'a?).{set : ('a?) -> unit} = <fun>.{set=<fun>}
r.set(1)
r.set("aabb")

Pure function return

def f() =
  fun (x) -> x
end
f : () -> ('a) -> 'a

This one is safe to generalize:

fn = f()
fn : ('a) -> 'a

The idea

The idea here is that, if a universal type is present in the type of the returned value of the function, we should not generalize.

However, if this type is actually itself inside a function for which there is a non-optional argument containing it, then it should be safe to generalize.

The reason being that, if we generalize this type, it will be unified with any future application of the function it belongs to therefore making the type generalization safe.

Other examples:

# Type generalization with a method:
def f() =
  fun (x) -> { foo = x }
end
fn = f()
fn : ('a) -> {foo : 'a}

def f() =
  fun (x) -> {foo = x.gni }
end
fn : ('b.{gni : 'a}) -> {foo : 'a}

# With a tuple:
def f() =
   def g(x) =
    let (y, _) = x
    y
  end
  g
end
fn : (('a * 'b)) -> 'a

Etc.

@toots
Copy link
Member Author

toots commented Jul 21, 2024

Gonna merge this. I think it's safe and we can revisit if it causes trouble, it's pretty isolated.

@toots toots added this pull request to the merge queue Jul 21, 2024
Merged via the queue into main with commit de87419 Jul 21, 2024
26 checks passed
@toots toots deleted the generalize-function-applications branch July 21, 2024 15:02
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.

Different http handlers may cause typing errors
1 participant