Guppy file format

[ss2165]

Guppy is very powerful for writing mixed python and guppy code in one fail and having them interact. But when you are primarily writing guppy (for example when defining guppy modules) there is a lot of boiler plate required.

This includes:
-@guppy decorators everywhere

• python imports as well as guppy.load calls for pulling in guppy modules
• python imports for guppy builtins like py, owned, result

For these cases it could be quite useful to have a guppy file type which assumes all of this boilerplate. This becomes much easier to pull off once we have an LSP: #714

So let's say you want to define a module in my_guppy_lib.py right now:

from typing import no_type_check

from guppylang.decorator import guppy
from guppylang.std import angles
from guppylang.std.angles import angle
from guppylang.std.builtins import array, owned
from guppylang.std.option import Option
from guppylang.std.quantum import qubit

guppy.load(angles) # not strictly necessary in implicit modules

@guppy.type()
class MyType:
    @guppy
    @no_type_check
    def method(self, x: qubit) -> qubit: ...


N = guppy.nat_var("N")


@guppy
@no_type_check
def foo(x: array[qubit, N] @ owned, angle: angle) -> Option[qubit]: ...

I propose instead the use can write a my_guppy_lib.gpy file like:

from std.angles import angle
from std.option import Option
from std.quantum import qubit

class MyType:
    def method(self, x: qubit) -> qubit: ...

def foo[N](x: array[qubit, N] @ owned, angle: angle) -> Option[qubit]: ...

A difficulty is how this interacts with normal Python files. Python will ignore non .py extensions, so maybe users have to call special imports:

guppy.import(my_guppy_lib)

but the same package discovery rules could apply.

The LSP would also need to understand these imports to go find definitions in other modules.

This would be a key part of the design to improve!