Fix dataclass @defops and added dataclass metaclass

[kiranandcode]

Fixes #435 and closes #436.

    @effectful.ops.syntax.register_dataclass
    @dataclasses.dataclass
    class Point:
        x: int
        y: int

    @defop
    def random_point() -> Point:
        raise NotHandled

    def client():
        p1 = random_point()
        p2 = random_point()
        return p1.x + p2.x

    t = client()
    assert isinstance(t, Term)
    with handler({random_point: lambda: Point(1, 2)}):
        res = client()
        assert res == 2
        res = evaluate(t)
        assert res == 2

[kiranandcode]

Let me rebase ontop of #438

actually #438 rebases onto staging-llm

[cooijmanstim]

LGTM, thanks a lot! We should also pass this by someone more familiar with the codebase such as @eb8680 or @jfeser.

[jfeser]

Looks generally good! A few nits noted.

[cooijmanstim]

At this point, does it still need to be a metaclass? It seems like it could be a regular DataclassTerm class that is instantiated with a reference to the dataclass type and overrides __getattr__ to expose the properties.

[jfeser]

Using a metaclass gives you isinstance(term, Dataclass).

[kiranandcode]

requesting additional eyes because this PR now touches a lot more of effectful's internals

[kiranandcode]

didn't want to touch the core definitions so tried for a minimal as change as possible, but it might have been nicer to stuff the resolved type into Operation maybe?

[jfeser]

It's not a property of the operation, but rather the operation applied to particular arguments. We shouldn't mutate the operation object to carry that data.

[kiranandcode]

right, but if the operation applied to specific arguments changes its type (specializes it) then theres a reasonable interpretation for updating the operation to reflect the updated type.

that being said, I'm not familiar enough with the internals and usage of effectful to tell what that would break or implications of that, so if this current approach makes sense, then I have no objections.

[jfeser]

So, we have a single operation object (e.g. identity) that can appear in many contexts in a term and have different return types. That object can't carry the type resulting from a single application.

[kiranandcode]

Oh, sorry, was coding late and merged the branch but I realised I hadn't got @eb8680 's reviews on the code. Should I revert this?

[eb8680]

No, it's fine, @jfeser reviewed it