StoneCypher / fsl

Finite State Language specification
9 stars 1 forks source link

State field `kind` #1257

Open StoneCypher opened 8 months ago

StoneCypher commented 8 months ago

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;
StoneCypher commented 6 months ago

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