I agree with that, which is also my point of confusion. So to make sure we see this statement the same way: from my perspective, to capture the desired diversity of intents, we would have to eventually switch to code from data. In resources, logic is the code field, while all other fields, including value, are data fields. I can see how for simple intents storing them in data is indeed nicer (or, alternatively, we can reuse the abstraction mechanics from the shielded kudos design).
Of course we can store data in code and vice versa, but the motivation is still not clear.
I’m specifically concerned about the more sophisticated intents. I think it isn’t good enough that it is possible to express such intents in principle. If it is too difficult to implement in practice, it is likely to be equivalent to not having them at all.
That sounds nice, but I don’t see how. I think an explicit description would help here.
The difference between balancing and what you describe is the quantity. I don’t see how “I need to create X” is much simpler than “I need to create X with quantity Q”. I think we can actually go further and abstract this away fully in many cases where balancing is ephemeral or trivial since these are pretty standard mechanics. The difference is that locking mechanics in the language prescribes the desired behaviour vs libraries offering a possible behaviour.
I think I imagine it not only being a primitive, but have a higher level meaning too. We don’t need to put “cross-action ephemeral resource” primitive in there, it just becomes an “intent” primitive.
I feel like somewhere here we forget about the fact that we should prioritise the shielded case, for which, I think, many of these assumptions don’t hold. Specifically, how the search works for such intents, since they are not floating around in the intent pool or are encrypted. Shielded intents cannot be communicated in the form of unbalanced transactions only, and they are communicated privately. Even if we consider the context of a single solver’s intents pool, an intent must contain more data (otherwise the solver won’t be able to create proofs)
This is another case of prioritising “simple” over “desired”. We keep postponing solving the problems for the shielded case and develop a bunch of optimisations for the transparent case only emphasizing the convenience gap while we should try to reduce it by thinking about the shielded case first.
Okay, this is much clearer to me.