DeckoSystems+archived names
New Take on Namespace Logic
Still a bit preliminary, needs a lot of summary and editing, top level doc is Card Continuum in my deck. I will add here and related cards here as I make clarify concepts.
I think this Card is more up to date and to the point. The other 'references out' from the first link are earlier starts at the framework for this blueprint
I will attempt to summarize the motivation here. Most of the issues are addressed below, but I'm going to suggest some different basis for design going forward. I want to do away with any special syntax and be able to express everything in terms of joining of simple names, and binding content to names.
If we define virtual cards more generally, to say that for any card X, X+f represents a functional application of Card f (required to be a Simple Card). In this paradigm, no Simpler cards can be virtual. I propose that when you add two decks, or subsets of decks in this functional way. E.g.:
DeckA + subset(DeckB) => DeckA with the subset of B addef virtually.
Then we bind some constructed combination of a base deck (or decks) with virtually mounted subsets of other Decks. I won't treat all the cases here, but I suggest that this functional understanding of Decks as multiple namespaces that can be merged without additional syntax could be used to:
- Disambiguate. Say DeckA and DeckB each have CardConflict use, so in the combined (+ operator for adding namespaces) Deck/Namespace gives DeckA:Cardconflict for CardConflict, but CardConflict+DeckB would get DeckB:CardConflict. CardConflict+DeckA would be interpreted as a name alias for CardConflict (when we have that).
- Select specific langage for rendering/names. AnyCard+LanguageInstance would override context language selection. For example you could display the French translation in an English version of a card discussing correctness of translations.
Stacked Decks
- What are some good sample use cases? (probably won't build until we have some good ones)
- Could this be implemented as an option in SmartName?
- card key takes some standard form (eg, alphabetical order)
- card name free to take any form that can be reconciled to key (like all cards)
- name references do not store seq