Abstraction and Modularization
We need to take generalized scenario human concepts, for example "Sumomo, can you find great bathing software for us please?"
, and turn that into a series of concrete steps for the robowaifu that actually allow her to perceive, understand, plan, and execute on the request. This is a vastly more complex undertaking than an uninitiated newcomer might reckon on, since they commonly tend to personify many things around them. In particular, it's often hard for them to discern why something so obviously human-like as a robowaifu would have any difficulty performing this (highly complicated) task. After all, isn't it just 'common' sense? Get on the Internet and do a search right?
Tackling a problem like this requires us to 'divide-and-conquer' the different parts up if we hope to succeed at solving it. This 'Abstraction and Modularization' is the very heart of the human aspect of software & hardware engineering, regardless of the other tools used.
In the words of the authors of The Elements of Computing Systems
>"You may wonder how it is humanly possible to construct a complete computer system from the ground up, starting with nothing more than elementary logic gates. This must be a humongous enterprise! We deal with this complexity by breaking the system into modules. Each module is described separately, in a dedicated chapter, and built separately, in a standalone project. You might then wonder, how is it possible to describe and construct these modules in isolation? Surely they are interrelated! As we will demonstrate throughout the book, a good modular design implies just that: you can work on the individual modules independently, while completely ignoring the rest of the system. In fact, if the system is well designed, you can build these modules in any desired order, and even in parallel, if you work in a team.
>"The cognitive ability to “divide and conquer” a complex system into manageable modules is empowered by yet another cognitive gift: our ability to discern between the abstraction and the implementation of each module. In computer science, we take these words concretely: abstraction describes what the module does, and implementation describes how it does it. With this distinction in mind, here is the most important rule in system engineering: when using a module as a building block—any module—you are to focus exclusively on the module’s abstraction, ignoring completely its implementation details.
While their project's design intent is rather different than this one's, these fundamental concepts of abstraction
will be vital if we are to succeed at this grand venture.
Providing abstractions for concrete computing tasks within and without a robowaifu, and building those large tasks from the ground up piece-by-piece, using interoperable software and hardware modules & components, is the basic plan going forward. Breaking down conceptual ideas into the different RW Foundation libraries & classes, and then allowing each and every one of these to freely call on all the others is the intended approach we're taking here. This allows us to focus on and think about just a few small parts of the overall problem at a time, without having to keep the entire system in our minds at once.
The primary goal behind the Tip
tagging, is to provide a convenient mechanism to validate 'who-is-who' from one function to another across the entire system. However, in addition to the basic idea of tracking flows of the complex callgraphs, it also affords us a minimum degree of access-control, function-to-function. This should help provide another level of assistance to avoid unintentional misuse of function calls, and to help us write more predictable code.
Perfection is unachievable in this life of course. :^) But hopefully using this approach of embedding tags for passing/checking inside calls (and widely throughout the system) can assist us all in our goals for reliable, predictable robowaifu software (whatever it's intended usage). I plan to also keep a close eye on the compute costs involved for this basic access-control mechanism, with an eye to ensuring it runs smoothly on SBCs and microcontrollers. Since it's all C++/C code start-to-finish, it should
stay fairly efficient as long as we keep an eye on things, and do our jobs well.
Future plans for the Sumomo
effort are to begin implementing both the basic function-level access-control mechanisms described, and also a 'channel' mechanism to both maintain the state of (and reduce the pointer-chasing indirections of) to help reduce the resource costs involved with the setup/teardown common to system callgraphs. Hopefully I'll have progress along these lines by the end of this year.
To that end, I've taken an initial pass at implementing some of the basic architectural approaches outlined here. I've also created a simplistic (but working) test-harness project to prove out 3 of the fundamental aspects of the system's architectural design:
- Every object's t_tag is unique within the system
- Base-class indirection avoids an 'infinite member-objects' cycle
- Working callgraph chain, 4-deep
Just follow the standard protocols for extracting/building/running the project, common to all our software projects here. A 'readme.txt' is embedded in the archive file itself to help get you started.
I'll plan to release the more generalized version of Sumomo
that includes some basic class declarations/definitions to begin fleshing out the interrelationships more clearly. This should happen next weekend, to help celebrate the 5th birthday of /robowaifu/
>(pt 2 of 2)
>minor spelling edit
>add the single word 'great'
Edited last time by Chobitsu on 11/21/2021 (Sun) 19:25:12.