Up to this point we have talked about the idea of sets without saying much about how they work.  That's because all the ideas above are needed to explain it.  From the initial implementations of the Set feature, specific sets were represented by cards, and the way of representing a set with a card was determined.  We wanted to attach one or more Settings to a set of cards by creating rule cards.  A rule isn't actually a cardtype, and the standard patterns don't support it as a set, but Set and Setting are core cardtypes.

A simple example of the type pattern would be 'Set+*type' to refer to all cards whose type is the Set card.  The *syle card is a Setting that determines the CSS, so a rule would be Set+*type+*style.  The contents of rule cards configure and customize with data, but you can do even more with code.

These sets and patterns also have code bindings so they can be used in the definition of modules to customize and extend the common data abstractions provided by cards.  That is something built into the name system that we left out above.  Any card can have a codename, and the most important feature of a codename is that it never changes.  Good code will never use a cardname literal, and therefore re-naming a card cannot break code references to that card.  That will become important as we move to code features.