Chunk Investigation

This page will outline the progress of #3086 to document how we currently use chunks to see if we are doing it "correctly."

Investigating DefinedQuantityDict

So I decided to take first pass with DefinedQuantityDict, since that's where this issue started, and I noticed the following.

Summary of DefinedQuantityDict

A DefinedQuantityDict is created by taking a ConceptChunk and adding the parts necessary to also make it a Quantity, which includes a symbol (that might depend on the stage), a space, and maybe a unit.

"Issues" with DQD currently:

ConceptChunks made only to be used in a DQD

Sometimes, as in Projectile (see below), we create a ConceptChunk that is only used in a DQD. What is the rationale for this? Couldn't we just define the ConceptChunk locally in the constructor for the DQD, or is there some reason (e.g., to support future changes that might need just the ConceptChunk for something else) that we define the ConceptChunk separately? I was able to migrate this specific example to just using a local ConceptChunk and it worked without a problem, although the code got a bit harder to read (which might be a valid enough reason for this method of building DQDs). (The concept is defined here and the DefinedQuantityDict is defined here).

-- Concepts.hs
launAngle :: ConceptChunk
launAngle = cc' launchAngleNC
  (foldlSent_ [phraseNP (the angle), S "between the", phrase launcher `S.and_` S "a straight line"
             `S.fromThe` phraseNP (launcher `toThe` target)])

-- Unitals.hs
import qualified Drasil.Projectile.Concepts as C (launAngle)

launAngle :: ConstrConcept
launAngle = constrained' (dqd' C.launAngle (autoStage lTheta) Real (Just radian)) [physc $ Bounded (Exc, exactDbl 0) (Exc, half $ sy pi_)] (sy pi_ $/ exactDbl 4)

"Projections" to DQDs

There is a constructor dqdWr, that takes a chunk with all the required information for a DQD and creates a corresponding DQD.

Examples

It is called on the following chunks in the examples:

• In GamePhysics: unitSymbs, inputConstraints, and outputConstraints
• In NoPCM: concepts, constrained, tempW, watE, and surface
• In SSP: coords, inputs, xMaxExtSlip, xMaxEtrSlip, xMinExtSlip, xMinEtrSlip, yMaxSlip, yMinSlip, outputs, units, unitless, inputsWUncrtn, inputsNoUncrtn, constrained, and surface

Occurences from SSP.Unitals (with only relevant code included):

symbols :: [DefinedQuantityDict]
symbols = map dqdWr inputs -- :: [DefinedQuantityDict]
  ++ map dqdWr outputs -- :: [ConstrConcept]
  ++ map dqdWr units -- :: [UnitalChunk]
  ++ map dqdWr unitless -- :: [DefinedQuantityDict]

inputs :: [DefinedQuantityDict]
inputs = map dqdWr inputsWUncrtn -- :: [UncertQ]
  ++ map dqdWr inputsNoUncrtn -- :: [DefinedQuantityDict]

Issue: Some of these values are already DefinedQuantityDicts; I don't think we should be calling dqdWr again if we don't need to.

Issue: The dqdWr function (and likely other related functions) creates a new DefinedQuantityDict where it could be simply accessing the existing one within the passed object, if applicable. Is this undesired behaviour, or a more efficient way of doing this?

In every one of these cases, its use is to combine quantities of different types into one list of DefinedQuantityDicts.

drasil-lang

It is also used in drasil-lang in the following functions:

• In Chunk.Constrained: constrained', constrainedNRV', and cnstrw'
• In Chunk.UncertainQuantity: uq

Occurences in Chunk.Constrained:

-- | Creates a 'ConstrConcept' with a quantitative concept, a list of 'Constraint's and an 'Expr'.
constrained' :: (Concept c, MayHaveUnit c, Quantity c) =>
  c -> [ConstraintE] -> Expr -> ConstrConcept
constrained' q cs rv = ConstrConcept (dqdWr q) cs (Just rv)

-- | Similar to 'constrained'', but defaults 'Maybe' 'Expr' to 'Nothing'.
constrainedNRV' :: (Concept c, MayHaveUnit c, Quantity c) =>
  c -> [ConstraintE] -> ConstrConcept
constrainedNRV' q cs = ConstrConcept (dqdWr q) cs Nothing

All related functions involve creating a DefinedQuantityDict behind the scenes at some point, so this approach seems reasonable to me.