feat: Allow calling a tensor of functions

[croyzor]

Allow calling functions as if using tensor product of operators, with tuple syntax: (f, g)(a, b, c). This should work whenever all of the tuple elements are themselves callable, and otherwise raise an error.

• Calls of tuples compile down to a TensorCall which packs up the LocalCalls and GlobalCalls to the functions in the tensor product
• Some parts of typechecking have been generalised to allow more arguments than the function can process and return the leftovers. I did this instead of being concrete about arg numbers in order to facilitate use of the * operator for chaining calls like (f, g)(*h(a, b)) but there might be an easier way.

Resolves #141

Update: This no longer adds any new nodes or types -- it just uses tuples and adds a couple of helper functions to deal with them

[mark-koch]

I'll do a more detailed review later, but here are some first thoughts:

I'm not sure if constructing a FunctionTensor during CFG construction is the best move since this will only work if you call the tuple directly. For example, I belive the following doesn't work, right?

@guppy
def foo() -> int:
    return 42

@guppy
def bar() -> bool:
    return True

@guppy
def baz() -> tuple[int, bool]:
    f = foo, bar
    return f()

In order to call "dynamic" function tuples, you'd have to wait until type checking a call f(args), infer the type of f, and check if the type is callable, i.e. if

• it is function type, or
• it is a type that implements __call__, or
• it is tuple of callable types

If you made it such that callable types check against function types, then you wouldn't even need the tensor type since you could use Callable everywhere:

@guppy
def tensor_foo_bar() -> Callable[[], tuple[int, bool]]:
    return foo, bar

[mark-koch]

I think this is looking quite good overall 👍 My main concern is that the call checking code is becoming a bit hard to read, covering so many cases. Also, I'm not sure if nested tuples are always handled correctly?

One suggestion to consider is that we could get rid of the special logic that is used to check tuple literals and instead always rely on the general version using function_tensor_signature() and check_call() / synthesize_call()? This would simplify the logic substantially and give us nesting for free

[mark-koch]

I'm not sure if we want allow_free_vars=True.

Conceptionally, it would be nice since we could use the type we're checking against to infer some unsolved type variables in the tuple. Unfortunately, we have no easy way to report what we have learned back to the tuple element. I have some ideas for rewriting the type inference logic to allow stuff like this but we can't do it at the moment :(

The only thing that would work right now is first synthesising the element to figure out the number of inputs/outputs it expects and then re-checking the element against the expected function type acting only on these inputs/outputs. But I think doing this is probably not worth it...

[croyzor]

My thinking was that the vars would be resolved when we try to unify with the expected type below?

[mark-koch]

Yes we can resolve them but we would need to go back to the place where variables were created and fill in the solution. There is currently no good way to do this

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 94.20290% with 4 lines in your changes are missing coverage. Please review.

Project coverage is 90.70%. Comparing base (4f24a07) to head (0373dc6).

Files	Patch %	Lines
guppylang/checker/expr_checker.py	88.23%	2 Missing ⚠️
guppylang/compiler/expr_compiler.py	96.29%	1 Missing ⚠️
guppylang/tys/ty.py	94.73%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #196      +/-   ##
==========================================
+ Coverage   90.64%   90.70%   +0.06%     
==========================================
  Files          46       46              
  Lines        4724     4789      +65     
==========================================
+ Hits         4282     4344      +62     
- Misses        442      445       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mark-koch]

One thing to note: An empty function_elements lists also evaluate to False which means we can't call empty tuples. But I think that's fine, the expression ()() isn't that useful :D

[mark-koch]

Yes we can resolve them but we would need to go back to the place where variables were created and fill in the solution. There is currently no good way to do this

[mark-koch]

Nice, this looks a lot cleaner!

[mark-koch]

Just some final nits. The tests are looking good 👍

Feel free to merge afterwards

[mark-koch]

I think if you do this instead you can get rid of the unification below

Suggested change

	processed_args, subst, inst = check_call(
	tensor_ty, node.args, tensor_ty.output, node.func, self.ctx
	)
	processed_args, subst, inst = check_call(
	tensor_ty, node.args, ty, node, self.ctx
	)
	assert len(inst) == 0
	return return with_loc(node, TensorCall(...)), subst

[mark-koch]

Also notice the updated location node.func to node. I think this should improve the error location in some of the golden tests

[mark-koch]

Why is this len == 1 special case needed?

[croyzor]

It should be redundant, duplicating the logic of pack_returns. I'll remove it