Add diagram for Concept* chunks + related typeclasses and ShortName with namespace refactoring #4031
Conversation
| -- | For projecting out to the 'ConceptChunk' data-type. | ||
| cw :: Concept c => c -> ConceptChunk | ||
| cw c = ConDict (nw c) (c ^. defn) (cdom c) |
There was a problem hiding this comment.
Should 'forgetting' other structural knowledge ever be necessary/desired?
There was a problem hiding this comment.
If not, I will track constructors too. Actually, I might just do that regardless.
There was a problem hiding this comment.
Forgetting knowledge was forced on us when creating lists because Haskell wanted a uniform type. If we use lenses (getters, really) uniformly all over, then I'm pretty sure we won't need these at all anymore.
| dcc :: String -> NP -> String -> ConceptChunk | ||
| -- | Smart constructor for creating concept chunks given a 'UID', 'NounPhrase' | ||
| -- ('NP') and definition (as a 'String'). | ||
| dcc i ter des = ConDict (mkIdea i ter Nothing) (S des) [] |
There was a problem hiding this comment.
Nesting a mkIdea looks odd to me. A chunk is being constructed purely within it. This PR is already making me think that:
- An
IdeaDictshouldn't be a chunk at all. There should be a term cache somewhere/somehow, but it should only be used to track which domains define which terms and how. - A
ConceptChunkperhaps shouldn't be a chunk either, but a kind of "Chunk Core" for all other chunks.
A ConceptChunk could act like a "fundamental chunk components" packet/core that all other chunks contain for the sake of having a UID, NP (a 'term', or a reference to the hypothetical alternative to an IdeaDict), Sentence (description). Ironically, all chunks would "inherit" these pieces of information from the packet/core.
There was a problem hiding this comment.
While you're not wrong, you're currently looking at this from too much of an implementation-oriented POV.
A Chunk is just a unique piece of knowledge. Some of our IdeaDict really are "all" of the knowledge we know about certain items.
Now, you are correct that this call to mkIdea inside ConDict is extremely suspicious. But I think this is an 'en'coding bug. We need to better understand what it is we're trying to 'encode' with dcc, and that will inform our design.
| -- | Defines a chunk. | ||
| class Definition c where | ||
| -- | Provides (a 'Lens' to) the definition for a chunk. | ||
| defn :: Lens' c Sentence |
There was a problem hiding this comment.
Let's be silly. An idea: Why not parameterize the Sentence? We would then be able to define meaning to different contexts:
class Definition chunk domain where
defn :: chunk -> domain -- or Lens' chunk domainThen, we could have something like:
instance Definition QuantityDict Sentence where defn = ...
instance Definition QuantityDict Equational where defn = ...
instance Definition QuantityDict Implementation where defn = ...Equational and Implementation names are obtained from Drasil's Stage data type that a QuantityDict's Symbol depends on. They're the constructors of the Stage type.
It looks familiar now, but the code is still gibberish. What is Equational and Implementation now? I'm not sure!
There was a problem hiding this comment.
This 'silly' suggestion is the germ of a good one. What constitutes a Definition is overloaded.
We also need to differentiate between "X has definition Y (in terms of Z)" and "X contains a definition". I think we need to analyze some examples to figure out what we need to be able to say in practice.
(Your exact suggestion seems to mix things, and probably Drasil does too, so all of that needs de-tangled).
I don't know when, but at some point we should have an in-person design discussion—recording thoughts in a talking points file sound like a good prep for the meeting. The other thing I hope for before the meeting is examples of the different types of information. I'm not as familiar with the code as you are, so I don't remember the difference between an idea and a concept, etc. 😄 |
|
That's a good idea. Optimally, the diagram + discussion should be enough to explain how information is organized (concretely) and used (at least abstractly) in Drasil. I suppose that documenting how/where chunks find use across the packages will be helpful then. I'll add that to this PR + the previous. |
balacij
force-pushed
the
chunkInvestLang2
branch
from
9f2a787 to
19e5eda
Compare
|
I think building on #4030 is a bad idea. There are conceptually separate things going on here, some of which are good idea, some of which are not. So right now, because of the bad ones, the whole PR ends up having to be rejected. Please stick to making small PRs! And try to keep them separate, conceptually. |
| sDom [d] = d | ||
| sDom d = error $ "Expected ConceptDomain to have a single domain, found " ++ | ||
| show (length d) ++ " instead." | ||
|
|
||
| -- TODO: conceptual typeclass? | ||
| -- TODO: I was thinking of splitting QDefinitions into Definitions with 2 type variables |
There was a problem hiding this comment.
QDefinition, while an awful name, was still better: a QDefinition grabbed the definition of a quantity. That quantities must have a definition makes sense. Definition on its own, not so much.
Contributes to #4032
Builds on #4030