expand_less
Wanting to finally fully connect Cards and Signs. Since everything is indeed a sign, and via category theory and applied math we can make this formal as in [[https://www.academia.edu/s/a78224fcc1|this paper]] most of it is laid out. I've already formalized a bit more as it relates to symbol categories and representing signs minimally as relating things in 2x2 relations of invertable pairs of asymetric categories like AND and OR (Boolean logic), plus and times. for case on we have the full adder, for the second, the barrel multiplyer which can produce multiply and divide in 8 full adder cycles to propagate carry/borrow to the right/left. The barrel step counter counts the the carry/borrow as eq/noteq (xor) propagate, so you can send the carry/borrows to the left and right to the next level of the hierarchy and you can continue to propagate carries to the next level and the next, as large as the numbers get. The left and right side of a whole chip can link to the next chip over in the array or a network of memories and more processors.
All this is to say that it just works if you nest these concepts. So, just as in object oriented and functional, all the latest theory that is also base on categories if you look at it right. The guts of it is to present a sign to a service and have it perform many recursive levels of systems nesting via signs, it all this same cycle. If you have a first sign part, the signal that represents the presence of or discussion of a given objects or subject, there are ten kinds of sign that it could be (or not be if it is decided to not be a sign, not about anything or distinct enough to be complete). If the third part of a sign is singular like an iconic of some Primary subject, then the first and second are, the first type. If the object is distinct, then the first part could be singular or Dual and these 3 are doubled to six with the third part being Dual or Triadic giving seven with the first. Now the Sign being Dual, being actually of something and not detatched from its object can have a Dual or Triadic thirds. Finally the one category with a Triadic Sign for all three parts of the sign. 1 and 2x3 and 2x2 and 1 gives 10. Simularly we should have all these categories for an object or type system.
The first part can be of three kinds. Monadic, (functions generated from a Monadic Category or Type), Diadic having two parts, that is either a Monadic Function or an invertable Diadic function. This automatically creates another Monad of an invertable function and the categorical method to create another monadic functrion from a function and it's inverse. In this way we get the natural log and its base transcendental constant e.
Let's see if we can do similar with Cards and Objects. In both we have names and contexts for interpretation. Cards are both Ruby and Ruby on Rails Objects, so here we have a number of monadic categories and some diads and implicitely triads as well. Via the MVC paradigm there is an existing framework that relates some design categories involved in these objects. The Cards gem implements the Controller to Model and View in a somewhat different way than many Rails applications, but there are direct ways to map different functional contexts to make this all hang together very deeply and I hope these ideas will help us all understand it better.
The essense of the OO paradigm is that Objects are bundles of functionality not strictly categories, but some of these categories and relations do have this cross and invert relations that help glue all the layers together. Cards by themselves can only be used with the Ruby language and does not provide a full application. It does provide access to the Rails console so that you can load Cards, but you still have to route them to make a web server. For this we need Decko. Decko makes Decks into Objects, although currently nobody uses many decks in one application, this is the key to why we want to look at things this way. Through Rails routes, Engines and Applicaton Controller code, the Card Model is made available as a web server.
So, what is this Triad MVC? it is a Sign of Sign Triads being present. In Decko, the controller uses the Model to View Cards and Update Cards, that is it maps Web requests through Ruby Rack request protocol to Rails Dispatch from where it connects to the two Card Diads to view and change card decks and thereby the Card ORM model in Rails. What if I want to use different routing (Decko Controller to MV or MC mapping) and different variations on Rails Models for Cards. An Active Resource Card could be serviced by any MV and MC configuration that supports the Card Model, local, persistant caches, remote or git/ipfs content addressed protocols.
A Request has a web path that will select a Deck and Card by 1) Monadic, default deck and cardname to the card that can be acted upon, or the Diad of Deck and a Cardname/id. Either way we have a deck, and by that we have the Card. The Card might be the Sign you wanted (Fetch it, no view or action), or the web path also had parameters for a request to CRUD the Deck producing either the view or updated deck as the Third part or meaning of the sign. Cards updates are reversable
All this is to say that it just works if you nest these concepts. So, just as in object oriented and functional, all the latest theory that is also base on categories if you look at it right. The guts of it is to present a sign to a service and have it perform many recursive levels of systems nesting via signs, it all this same cycle. If you have a first sign part, the signal that represents the presence of or discussion of a given objects or subject, there are ten kinds of sign that it could be (or not be if it is decided to not be a sign, not about anything or distinct enough to be complete). If the third part of a sign is singular like an iconic of some Primary subject, then the first and second are, the first type. If the object is distinct, then the first part could be singular or Dual and these 3 are doubled to six with the third part being Dual or Triadic giving seven with the first. Now the Sign being Dual, being actually of something and not detatched from its object can have a Dual or Triadic thirds. Finally the one category with a Triadic Sign for all three parts of the sign. 1 and 2x3 and 2x2 and 1 gives 10. Simularly we should have all these categories for an object or type system.
The first part can be of three kinds. Monadic, (functions generated from a Monadic Category or Type), Diadic having two parts, that is either a Monadic Function or an invertable Diadic function. This automatically creates another Monad of an invertable function and the categorical method to create another monadic functrion from a function and it's inverse. In this way we get the natural log and its base transcendental constant e.
Let's see if we can do similar with Cards and Objects. In both we have names and contexts for interpretation. Cards are both Ruby and Ruby on Rails Objects, so here we have a number of monadic categories and some diads and implicitely triads as well. Via the MVC paradigm there is an existing framework that relates some design categories involved in these objects. The Cards gem implements the Controller to Model and View in a somewhat different way than many Rails applications, but there are direct ways to map different functional contexts to make this all hang together very deeply and I hope these ideas will help us all understand it better.
The essense of the OO paradigm is that Objects are bundles of functionality not strictly categories, but some of these categories and relations do have this cross and invert relations that help glue all the layers together. Cards by themselves can only be used with the Ruby language and does not provide a full application. It does provide access to the Rails console so that you can load Cards, but you still have to route them to make a web server. For this we need Decko. Decko makes Decks into Objects, although currently nobody uses many decks in one application, this is the key to why we want to look at things this way. Through Rails routes, Engines and Applicaton Controller code, the Card Model is made available as a web server.
So, what is this Triad MVC? it is a Sign of Sign Triads being present. In Decko, the controller uses the Model to View Cards and Update Cards, that is it maps Web requests through Ruby Rack request protocol to Rails Dispatch from where it connects to the two Card Diads to view and change card decks and thereby the Card ORM model in Rails. What if I want to use different routing (Decko Controller to MV or MC mapping) and different variations on Rails Models for Cards. An Active Resource Card could be serviced by any MV and MC configuration that supports the Card Model, local, persistant caches, remote or git/ipfs content addressed protocols.
A Request has a web path that will select a Deck and Card by 1) Monadic, default deck and cardname to the card that can be acted upon, or the Diad of Deck and a Cardname/id. Either way we have a deck, and by that we have the Card. The Card might be the Sign you wanted (Fetch it, no view or action), or the web path also had parameters for a request to CRUD the Deck producing either the view or updated deck as the Third part or meaning of the sign. Cards updates are reversable