`act` no longer works on raw `CBlock`.

[nrfulton]

To reproduce:

from mellea.core import CBlock
from mellea.backends.ollama import OllamaModelBackend

from mellea.stdlib.context import SimpleContext
import mellea.stdlib.functional as mfuncs
from mellea.stdlib.components import SimpleComponent

backend = OllamaModelBackend(model_id="granite4:latest")
ctx = SimpleContext()

answer_1, ctx_1 = mfuncs.act(CBlock("What is 1+1?"), context=ctx, backend=backend)
answer_2, ctx_2 = mfuncs.act(CBlock("What is 2+2?"), context=ctx, backend=backend) # nb: operates on ORIGINAL context, not ctx_1.

sum_of_sums, _ = mfuncs.act(SimpleComponent(instruction="What is [x]+[y]?", x=answer_1, y=answer_2))

print(f"(1+1) + (2+2) is {sum_of_sums}"

gives error:

  File "/Users/nathan/dev/mellea/mellea/stdlib/sampling/base.py", line 177, in sample
    result.parsed_repr = action.parse(result)
                         ^^^^^^^^^^^^
AttributeError: 'CBlock' object has no attribute 'parse'

I'm also unclear why we are doing any sampling here.

[nrfulton]

How things work now:

1. The mfuncs.act function operates over Components only. You cannot pass a CBlock into these interfaces.
2. The default sampling strategy is rejection sampling with a budget of 2.

If we kept this behavior: nothing changes. Passing the CBlock into act was a type error on the client. But I want to make some proposals for changes.

Possible counter-proposals to (1):

1. The mfuncs.act function operates over CBlock | Component like backend.generate does now.
2. The mfuncs.act function operates over all spans: CBlock | Component | ModelOutputThunk. This also require small changes to backend.generate. There's nothing truly new here, though; mots can be pieces of components do you can already generate "from" a mot by doing something like SimpleComponent(x=mot). Recall that we do this in requirement checking, for example.

Counter-proposal to (2):

1. The default sampling strategy is None, at least for act.

Should mfuncs.* functions take CBlocks and/or ModelOutputThunks in addition to Components?

In my original formulation, Span ::= CBlock | Component | ModelOutputThunk. Of course, mfuncs is part of stdlib not part of core. So it might make sense for the mfuncs interface to insist on Components. I'm at least open to to considering. The major disadvantage is that this greatly complicates the protocol/lifecycle of spans. (It might also place some of that protocol in stdlib instead of in core?)

We also need to consider whether backend.generate should be allowed to generate from CBlocks (like below, which does work now):

result, _ = await backend.generate_from_context(action=CBlock("What is 1+1?"), ctx=ctx)

Default Sampling Strategy

I still think the principle of least surprise dictates that the default value of sampling_strategy should be None. If you don't ask for multiple smpling calls then you shouldn't get multiple sampling calls. Especially for something as primitive as act.

attn: @jakelorocco , @HendrikStrobelt

[jakelorocco]

@nrfulton, do you still want this to be the case that we can pass in CBlocks. There was some prior discussion motivating our actions that a CBlock wasn't technically an action that did this?

[AngeloDanducci]

@nrfulton @jakelorocco is there further discussion to be had on this one? Least surprise seems to make sense but I will wait to hear back.

[jakelorocco]

Discussed:

1. act should work on CBlock | Component | ModelOutputThunk
2. default sampling strategy for act should be None