You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the spirit of #100, but in the more modern notational viewpoint, we could declare a field kind on a state, which allowed us to declare that a given state was a member of a kind. This is basically the parenthetical notation in the old issue (let's generate less sugar.)
kind input { shape: invtrapezium; fillcolor: cyan; color: black; };
kind processor { };
kind storage { };
state WebForm { kind: input; };
state TextMessage { kind: input; };
state PhoneAgent { kind: input; };
state Email { kind: input; };
state HelpDesk { kind: processor; };
state Warehouse { kind: processor; };
state Archival { kind: storage; };
[ WebForm TextMessage PhoneAgent Email ] -> Helpdesk;
HelpDesk -> Support -> Warehouse -> Archival;
HelpDesk -> Support -> Archival;
HelpDesk -> Warehouse -> Archival;
HelpDesk -> Archival;
The text was updated successfully, but these errors were encountered:
so, suppose you want to send all of from a kind to a particular node
in the above code you see [ WebForm TextMessage PhoneAgent Email ] -> Helpdesk;, even though those four nodes are already defined as input. that's repetitive, noisy, and in maintenance, error prone
in the old notation, we had a sigil & for this
otoh we could just say that a kind and a state can't co-name, and then (ye gods) extend the syntax to potentially point to a kind rather than a node
thing is, this is going to come up again and again and again, for stripes, for sequences, etc
In the spirit of #100, but in the more modern notational viewpoint, we could declare a field
kind
on astate
, which allowed us to declare that a given state was a member of a kind. This is basically the parenthetical notation in the old issue (let's generate less sugar.)The text was updated successfully, but these errors were encountered: