siiky
2024/08/19
2024/08/19
en
#008: realized there was a problem with pnee's implementation
#010: came up with a concrete plan to implement that idea
As a short summary: the problem was how to group tokens of the same "case"; and the solution (for simple patterns) was to group tokens by a key, taken from a given index of a tuple. In this log I'll elaborate on different patterns where keying could be an acceptable solution (or not).
The simplest possible pattern is when all input places have keyed tokens, and the keys are on the same indices. As an example, assume a 2-step asynchronous call. The client asks the server to perform some task, and later asks for its result. Keys residing in different indices across places could be a possibility; but it seems easy to remediate on the net's implementation.
by_key(3, [request, reply]).
Another obviously common pattern, that would be extremely useful to support with this strategy, is when some input places, but not all, have keyed tokens. As an example, assume a vending machine that prints receipts. A user inserts a coin, and internally a coin_token is produced in its turn, together with a receipt (representing a printed receipt). To give the cookie out, a coin_token and its corresponding receipt are needed. Cookies don't have a pre-assigned user, however, so they're consumed undiscriminately.
by_key(3, [coin_token, receipt], [cookie]).
And another pattern, that I'm unsure yet whether it'd be useful to support by this strategy, is consuming from places of "different cases". For example, in a machine with products of varying prices that prints receipts: coin_token tokens could be tuples {RequestID, Price}, product tokens {Product, Price}, and receipt tokens {RequestID, Text}.
by_key([
{1, [coin_token, receipt]},
{2, [coin_token, product]}
]).
% Presumably equivalent to finding tokens that match this pattern:
% #{
% coin_token := [{RequestID, Price}],
% receipt := [{RequestID, Text}],
% product := [{Product, Price}]
% }
This is starting to look like a query language, which, to be honest, is not unthinkable. Maybe with Erlang's ets it wouldn't be so difficult to implement. For now, however, better leave this pattern for the over_all strategy.