JacquesCarette
Inventory all uses of indexing in the examples
Before doing a full design of indexable structures, we should have a list of what already exists in our examples.
Yes! Thanks Dr. Carette. I will list all existing indexing-related examples in https://jacquescarette.github.io/Drasil/ before our full design.
I realized that the concept of “indexing” exists in the concrete examples rather than the concrete implementation, should we consider indexing in the general and examples-related data structure?
I'm not sure what you mean by the above comment? Can you expand on that please?
I think my comment above misunderstood the intent of your issue, so I want to make sure that what is expected to be done is to find out the use the concept of indexing in the current generated examples like DblPend (including SRS, generated code, generated code doc), that is to describe "where we are" in the application of indexing to the example, right?
We need to implement data-types that can be indexed (like vectors, matrices, but also lists, arrays, sequences, etc) in a general way. That is the problem to solve. We have current requirements for it, buried in the Drasil code base.
This is your project. It is non-trivial, which is why it can be a Master's level project if done correctly and properly.
I see, thanks for the explanation @JacquesCarette. What we want is a generalized solution.
Summary
Before designing the indexable data structure, we should list all the indexable structure types used in the current examples. Below is the summary information of my research:
List
The most common data structure in Haskell, whose elements can be accessed by index. Here are all the List types used in each example:
-
dblpend:
-
assumpDouble :: [ConceptInstance] -
choices.lang :: [Lang]
-
-
gamephysics:
-
assumptions :: [ConceptInstance] -
assumptionsListA :: [[Sentence]] -
mkSRS :: SRSDecl
-
-
glassbr:
-
assumptions :: [ConceptInstance] -
sysCtxUsrResp :: [Sentence] -
abInputConstraints :: [(QuantityDict, Maybe (RealInterval Expr Expr))]
-
-
HGHC:
-
symbols :: [QuantityDict] -
dataDefs :: [DataDefinition]
-
-
pdcontroller:
-
stdFields :: Fields
-
-
projectile:
-
assumptions :: [ConceptInstance]
-
-
ssp:
-
assumptions :: [ConceptInstance] -
sysCtxList :: Contents (nested list)
-
-
swhs:
-
units :: [UnitDefn] -
propsDeriv :: [Contents]
-
-
swhsnopcm:
-
units :: [UnitDefn] -
symbols :: [DefinedQuantityDict] -
symbolsAll :: [QuantityDict]
-
-
sqlbend:
-
dataDefs :: [DataDefinition] -
genDefns :: [GenDefn] -
velocityIXDerivSents :: [Sentence] -
inputs :: [QuantityDict] -
outputs :: [QuantityDict] -
symbols :: [QuantityDict] -
inConstraints :: [UncertQ] -
outConstraints :: [UncertQ] -
units :: [UnitalChunk] -
unitalChunks :: [UnitalChunk]
-
Maps
The Map data structure in Haskell is used to store key-value pairs, and the keys allow for efficient indexed access. The use of Map in each example is as follows:
-
dblpend:
-
symbMap :: ChunkDB -
usedDB :: ChunkDB
-
-
gamephysics:
-
symbMap :: ChunkDB -
usedDB :: ChunkDB
-
-
glassbr:
-
usedDB :: ChunkDB
-
-
pdcontroller:
-
symbMap :: ChunkDB -
usedDB :: ChunkDB -
refDB :: ReferenceDB
-
-
projectile:
-
symbMap :: ChunkDB -
usedDB :: ChunkDB -
refDB :: ReferenceDB
-
-
ssp:
-
symbMap :: ChunkDB -
usedDB :: ChunkDB -
refDB :: ReferenceDB
-
-
swhsnopcm:
-
symbMap :: ChunkDB -
usedDB :: ChunkDB
-
-
sqlbend:
-
symbMap :: ChunkDB -
usedDB :: ChunkDB -
refDB :: ReferenceDB
-
NonEmpty Lists
NonEmpty lists are guaranteed to have at least one element, which avoids the empty list problem and provides safer operations.
-
sqlbend:
-
defns（Using NonEmpty Lists in Code Segments）
-
Tuples
A tuple is a data structure that contains a fixed number of elements, and specific elements can be accessed by index.
-
glassbr:
-
slope :: (CodeExpr, CodeExpr) -> (CodeExpr, CodeExpr) -> CodeExpr -
onLine :: (CodeExpr, CodeExpr) -> (CodeExpr, CodeExpr) -> CodeExpr -> CodeExpr
-
-
swhsnopcm:
-
qwC tempC $ UpFrom (Inc, sy tempInit)
-
-
ssp:
-
pages Indicates page numbers (as used in citations)
-
Records
The Records type contains multiple fields, each accessible by name.
-
dblpend:
-
choices :: Choices
-
-
gamephysics:
-
si :: SystemInformation
-
-
glassbr:
-
choices :: Choices -
tolPre :: InstanceModel
-
-
pdcontroller:
-
codeChoices :: Choices -
gdPowerPlant :: GenDefn
-
-
swhsnopcm:
-
si :: SystemInformation -
Choices is a record
-
Currently, there is no implementation of vectors, matrices and sequences in our example.
The data types that already exist in the example include List, Maps, NonEmpty Lists, Tuples, and Records.
You are confusing the data types that exist at the Haskell-level implementation of the examples, and the data types that ought to exist in the target code implementation of the examples. For your work, we only care about the latter - so a lot of your data collection is not useful.
Also, it is important to understand (from the intent recorded in the SRS) what the data structures ought to be as opposed to the current implementations which may well use hacks to get the job done.
In other words this task involves actually understanding the intent, and cannot be done as a surface query.
I understand that the existing implementation may be in the form of walkaround. So what I'm going to do is actually divided into two steps, one superficial and the other deep.
- find out what data types are currently being implemented
- research the best implementation of the data types used in each example according to SRS, and determine whether the current implementation is the best (if there is one), and if not, how to implement it.
The list above is the first step, and what I need to do next is the second step.
@JacquesCarette To confirm, our objectives are:
- To determine the best practice for data type design based on the existing examples, aiming for an ideal case scenario.
- To implement fundamental data types such as vectors and sequences, as demonstrated in the existing examples. This implementation should begin with a basic class (for instance, named 'IndexableStructure'). Classes like vector and sequence should then be derived from this IndexableStructure class. During the implementation process, it's crucial to consider and ensure compatibility with all edge cases present in the examples.
- The existing examples are not good. And several don’t produce code because they need better vector and matrix support. Plus you still seem to be confusing the parts(inside Drasil, inside GOOL and generated by Drasil)
- Yes – but again you’re being imprecise about the full information flow. So it’s hard to ‘confirm’ when what you give me is too shallow.