Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 3 additions & 2 deletions code/drasil-example/template/app/Main.hs
Original file line number Diff line number Diff line change
@@ -1,12 +1,13 @@
module Main (main) where

import GHC.IO.Encoding
import Language.Drasil.Generate (gen, DocSpec(DocSpec), DocType(SRS),
Format(..), docChoices, dumpEverything)
import Language.Drasil.Generate (gen, DocSpec(DocSpec), DocType(SRS),
Format(..), docChoices, dumpEverything, typeCheckSI)
import Drasil.Template.Body (fullSI, srs, printSetting)

main :: IO()
main = do
setLocaleEncoding utf8
dumpEverything fullSI printSetting ".drasil/"
typeCheckSI fullSI
gen (DocSpec (docChoices SRS [HTML, TeX, Jupyter, MDBook]) "Template_SRS") srs printSetting
254 changes: 241 additions & 13 deletions code/drasil-example/template/lib/Drasil/Template/Body.hs
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,15 @@ module Drasil.Template.Body where

import Language.Drasil
import Drasil.SRSDocument
import Theory.Drasil (DataDefinition, GenDefn, InstanceModel, TheoryModel)
import Theory.Drasil
( DataDefinition,
GenDefn,
InstanceModel,
TheoryModel,
tmNoRefs,
equationalModel',
imNoDerivNoRefs,
ddENoRefs )
import qualified Language.Drasil.Sentence.Combinators as S
import Data.Drasil.Concepts.Documentation (doccon, doccon', srsDomains)
import Data.Drasil.Concepts.Computation (inValue, algorithm)
Expand All @@ -21,6 +29,7 @@ import Data.Drasil.TheoryConcepts
import Data.Drasil.Citations
import Drasil.DocumentLanguage.TraceabilityGraph
import Drasil.DocLang (tunitNone)
import Language.Drasil.ShortHands (cP, lP, cS, cD, lL, lM, lB, cA)

srs :: Document
srs = mkDoc mkSRS (S.forGen titleize phrase) si
Expand All @@ -31,6 +40,9 @@ fullSI = fillcdbSRS mkSRS si
printSetting :: PrintingInformation
printSetting = piSys fullSI Equational defaultConfiguration

stdFields :: Fields
stdFields = [DefiningEquation, Description Verbose IncludeUnits, Notes, Source, RefBy]

mkSRS :: SRSDecl
mkSRS = [TableOfContents,
RefSec $ --This creates the Reference section of the SRS
Expand Down Expand Up @@ -63,10 +75,10 @@ mkSRS = [TableOfContents,
] -- This adds a goals section and goals input is defined for the preample of the goal.
, SSDSolChSpec $ SCSProg
[ Assumptions
, TMs [] []
, TMs [] (Label : stdFields)
, GDs [] [] HideDerivation
, DDs [] [] HideDerivation
, IMs [] [] HideDerivation
, DDs [] (Label : stdFields) HideDerivation
, IMs [] ([Label, Input, Output, InConstraints, OutConstraints] ++ stdFields) HideDerivation
Comment on lines -66 to +81
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Input, Output, (In/Out)Constraints are rows that are only permitted for IMs. I'm not quite sure why. Are "inputs" not the input variables of a hypothetical function being defined?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's because 'definitions' don't have input/output, and many theories are relational, so again input/output makes no sense for them.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not quite sure I'm following. What is the difference between a data definition (which defines QDefinitions) and an EquationalModel-based (i.e., QDefinition-defining) instance model?

Is "input/output" in regard to the "system's" inputs, outputs, and intermediate variables? If so, I think that should still be relevant to data definitions, which can be used to interpret input variables to intermediate variables (e.g., for unit conversion, etc.), no?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do remember that "F = ma" is usually used to get 'a' as output, given F and m as input!

I think we ought to use different vocabulary for input and output of a system, and equations where some variables can be substituted for.

It is true that the intent of a data definition is that the new symbol is defined by the computation where we imagine substituting for the (implicitly occuring) variables in the RHS. A data-definition is implicitly a function.

, Constraints EmptyS ([] :: [UncertQ])
, CorrSolnPpties ([] :: [UncertQ]) []

Expand All @@ -93,9 +105,9 @@ si = SI {
_purpose = [],
_motivation = [],
_scope = [],
_quants = [] :: [QuantityDict],
_instModels = [] :: [InstanceModel],
_datadefs = [] :: [DataDefinition],
_quants = quantities, -- Odd: The Table of Symbols is mostly filled without this list!!!! Also, even though the table of symbols is being filled in, there is text "There are no symbols." placed above the table!
_instModels = instanceModels, -- Surprisingly, putting this here is not what triggers it to get rendered.
_datadefs = dataDefinitions, -- ^
Comment on lines -96 to +110
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is something that needs to be spun off into 2 new tickets.

  1. The SRS is rendered using the instance models and data definitions taken from the ChunkDB rather than here. We should probably change that.
  2. The Table of Symbols is partially rendered without filling in the _quants field, but completely filled in when passing this list to it. This should be investigated a little bit more.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The deeper questions are:

  1. where should the information come from? We used to do things "by hand" because there was no other choice. But, of course, Drasil should automate things as much as possible. So it is a good thing that some information comes from the theories rather than hand-built!
  2. what is the difference between the "background information" necessary, and the meta-data needed to build a particular system? And should that information be gathered? Divided up?

_configFiles = [],
_inputs = [] :: [QuantityDict],
_outputs = [] :: [QuantityDict],
Expand All @@ -105,13 +117,41 @@ si = SI {
_usedinfodb = usedDB
}

quantities :: [QuantityDict]
quantities = [
equilibriumQ, priceQ, supplyQ, demandQ, -- abstract variables
applePriceQ, linearSupplyQ, linearDemandQ, -- concrete variables
mSQ, mDQ, bSQ, bDQ, equilibriumApplePriceLinearSDQ
]

dataDefinitions :: [DataDefinition]
dataDefinitions = [linearSupplyDD, linearDemandDD]

instanceModels :: [InstanceModel]
instanceModels = [equilibriumPriceLinearSDQIM]

theoryModels :: [TheoryModel]
theoryModels = [equilibriumTM]

-- our theories are only rendered because they are added to this chunkDB, which is a problem.
symbMap :: ChunkDB
symbMap = cdb ([] :: [QuantityDict]) (nw progName : nw inValue : [nw errMsg,
nw program] ++ map nw doccon ++ map nw doccon' ++ [nw algorithm] ++
map nw prodtcon ++ map nw mathcon) srsDomains
([] :: [UnitDefn]) ([] :: [DataDefinition]) ([] :: [InstanceModel])
([] :: [GenDefn]) ([] :: [TheoryModel]) ([] :: [ConceptInstance])
([] :: [LabelledContent]) ([] :: [Reference]) citations
symbMap = cdb
quantities
ideaDicts
srsDomains
([] :: [UnitDefn])
dataDefinitions
instanceModels
([] :: [GenDefn])
theoryModels
([] :: [ConceptInstance])
([] :: [LabelledContent])
([] :: [Reference])
citations
where
originalIdeaDicts = nw progName : nw inValue : [nw errMsg, nw program] ++ map nw doccon ++ map nw doccon' ++ [nw algorithm] ++ map nw prodtcon ++ map nw mathcon
addedIdeaDicts = map nw quantities
ideaDicts = originalIdeaDicts ++ addedIdeaDicts

usedDB :: ChunkDB
usedDB = cdb ([] :: [QuantityDict]) ([] :: [IdeaDict]) ([] :: [ConceptChunk])
Expand Down Expand Up @@ -141,3 +181,191 @@ progName = commonIdeaWithDict "progName" (pn "ProgName") "ProgName" []
-- MOVE TO DATA.PEOPLE
authorName :: Person
authorName = person "Author" "Name"

{-------------------------------------------------------------------------------
- Equilibrium
-------------------------------------------------------------------------------}

equilibrium :: IdeaDict
equilibrium = nc "equilibrium" $ nounPhrase "equilibrium" "equilibria"
Comment on lines +189 to +190
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once defined, never used! Should we be using it? If so, how?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Never used because you're not "doing it right". For example, it should have been used on line 295, and indeed on line 202 as well.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, none of the constructors for QuantityDicts let us give them a plain IdeaDict. All of the constructors are keen on extracting an IdeaDict from something else or creating one that is immediately associated with the Q-D-.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand. On line 295, you could have gotten the nounPhrase by using the lens defined for that. What do you think the code should instead look like?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would have expected to be able to pass in the entire IdeaDict (seeing as QuantityDicts currently nest an IdeaDict), and for the QuantityDict to only carry a UID reference to said IdeaDict.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have the power to change Drasil: do it! Introduce new functions that let you do that. That's the fun part, of seeing things that should be better, and just improving them.


-- There is a generic copy between economics and physics, but we won't bother
-- with that.

{-------------------------------------------------------------------------------
- Equilibrium (Economics)
-------------------------------------------------------------------------------}

equilibriumQ :: QuantityDict
equilibriumQ = mkQuant' -- A somewhat odd variant of `mkQuant` that re-orders argument and adds staging to the `Symbol`
"inEquilibrium"
(nounPhrase "in equilibrium" "all equilibria") -- duplicates the IdeaDict
Nothing -- UnitDefn
Boolean
(autoStage $ label "inEquilibrium")
Nothing -- "abbreviation String"
Comment on lines +199 to +206
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

QuantityDict's mkQuant' and related smart constructors are interesting because they create their own IdeaDicts that they associate with themselves. QDefinition's mkQuantDef and related smart constructors are similar, except they also create a DefinedQuantityDict, which also creates a ConceptChunk. In the future, it might be that our smart constructors are stateful too (in reference to #2873 (comment)).

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is indeed a sign that we're trying to be too clever. We need to rethink this.


price :: IdeaDict -- I guess making this is completely unnecessary because the QuantityDict will make its own.
price = nc "price" $ cn "price"

priceQ :: QuantityDict
priceQ = mkQuant'
"priceQuant" -- duplicates the IdeaDict
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is technically a duplication -- but it shouldn't be, because the 'concept' of a price, and a variable that holds a 'price' value are completely different. And the bug is that you shouldn't do (cn "price") below but refer to price ^. term instead.

(cn "price")
Nothing -- UnitDefn // FIXME: Uh oh! There's seemingly no way we can define a new unit: $CAD.s
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was expecting that I wouldn't be able to create numbers of the form $ X CAD, but that I would be able to create CAD units at least. I don't see a clear way to doing that without it being 'derived' from the SI unit system.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure that currencies are 'units', per se. They are a classification system, and we ought to support more of them than just SI.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I hadn't realized that UnitDefn and our unit system in general was only meant for physical quantities following the SI.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right - it's a side-effect of Drasil being focused on scientific software, so that was the most important classification system. Types were second. Now we might need more classification systems to be added (and most likely, our code refactored to reflect this fact.)

Real -- Not quite a "Real," more of a "dollar amount with two decimal places, or a tuple containing two integers, with the second capped at 100"
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we add financial numbers to Space? I'm a bit against adding it to Space because it seems odd if I'm purely working on SCS and want to write a code generator to, say, Rust, because I would need to define how financial numbers compile to Rust as well.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would be quite happy to augment our concepts of "places where values live" to include financial numbers.

And yes, adding new things has a non-trivial implementation cost. Such is life.

(autoStage cP)
Nothing -- Abbreviation

supply :: IdeaDict
supply = nc "supply" $ cnIES "supply"
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regrettably, unused.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again: isn't it 'your' fault that you are not? Shouldn't you have used it on line 229?


supplyDemandFuncSpace :: Space
supplyDemandFuncSpace = mkFunction [Real] Integer -- Real should be Dollar, output should be strictly non-negative integers (Z^+)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Strictly non-negative integers (as well as natural numbers) would be great additions to our Space system!


supplyQ :: QuantityDict
supplyQ = mkQuant'
"supplyQuant"
(cnIES "supply")
Nothing -- UnitDefn -- Should units be a part of expressions? Supply is a function, so it doesn't have a unit. However, the output of the function should have a unit. The input of the function should have units as well.
supplyDemandFuncSpace
Comment on lines +223 to +231
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

supplyQ is a function (price -> units supplied). The a single unit is not quite applicable. I think units want to be closer to types (?). IIRC, there was a paper that @JacquesCarette or @smiths found. I know Dr. Anand's lab is working on this because I saw a poster about it (but Miriam hasn't gotten back to me about any writings about it, so I don't know where to get information related to this now).

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a lot of SCS software, things are implicitly functions of time but the units are written as those of the output (only). So this is indeed a confusing point.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lists are another place where our concept of units is abused. For our position vector we write the units for an element of the vector, not the units for the vector. I believe we say that somewhere in the SRS, but it it still potentially confusing.

(autoStage cS)
Nothing -- Abbreviation

demand :: IdeaDict
demand = nc "demand" $ cnIES "demand"

demandQ :: QuantityDict
demandQ = mkQuant'
"demandQuant"
(cnIES "demand")
Nothing -- UnitDefn
supplyDemandFuncSpace
(autoStage cD)
Nothing -- Abbreviation

equilibriumQD :: QDefinition ModelExpr -- equilibrium = S(P) == D(P)
equilibriumQD = mkQuantDef equilibriumQ $ apply1 supplyQ priceQ $= apply1 demandQ priceQ
Comment on lines +247 to +248
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is rendered poorly in the SRS (along the lines of equilibrium = S(P) = D(P)). It might be good for us to use := on the LHS.


equilibriumTM :: TheoryModel
equilibriumTM = tmNoRefs
(equationalModel' equilibriumQD)
[qw demandQ, qw supplyQ, qw priceQ]
([] :: [ConceptChunk]) -- This looks like just a wart? IIRC, no tmNoRefs/tm constructor uses this parameter
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to be spun-off into a new ticket about gradually moving to 'theories.'

[equilibriumQD] -- defined quantities
[] -- defined invariants
[] -- defined functions
"equilibriumTM"
[S "Equilibrium occurs when the supply and demand curves intersect at current price."]

-- Note: In the above, the label for "equilibrium" (the QuantityDict) is only
-- assigned in the TheoryModel!

applePriceQ :: QuantityDict
applePriceQ = mkQuant'
"applePriceQ"
(cn "apple price")
Nothing -- UnitDefn
Real -- Space
(autoStage $ sub lP cA)
Nothing -- Abbreviation

linearSupplyQ :: QuantityDict
linearSupplyQ = mkQuant'
"linearSupplyQuant"
(pn "price-dependant apple supply")
Nothing -- UnitDefn
(mkFunction [Real] Integer)
(autoStage $ sub cS lL)
Nothing -- Abbreviation
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Abbreviations are pretty underused in my example. Where do we use it?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SCS has tons of abbreviations. Maybe it's just that finance has less so for fundamental quantities?

Copy link
Collaborator Author

@balacij balacij May 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I think of abbreviations for quantities in financial fields, I primarily think of math symbols that happen to acronyms rather than purely textual abbreviations. For example, price ($P$) or supply ($S(P)$) have symbols, but I'm not sure if I would call those abbreviations. I wouldn't expect to see $P$ or $S(P)$ used in texts. For contexts with multiple prices or supply curves, we might see $P_x$ and $S_y(P)$, but I'm still not sure if I would call those abbreviations. Symbols in finance sometimes don't use subscripts however, so these symbols might end up looking like acronyms rather than single symbols as well (e.g., $PA$ [price of apples] and $SA(PA)$ [apple supply by price of apples]). Regardless, I would still say those are symbols. There are also situations with obvious, genuine =abbreviations, such as for average price: "avg. price," which has a different symbol, $\bar{p}$. Otherwise, I would think of abbreviations as aliases to mathematical symbols that happen to be acronyms (e.g., EBITDA, EPS, NPV, EAR, ROI, OC, etc.). However, not all symbols would have an alias abbreviation (e.g., I would call $bid$ and $ask$ "symbols," but maybe not abbreviations -- actually, maybe it is (?) because there's an implicit " price" added to the end of the linear curves).

I don't think I've seen our QuantityDict definitions declaring symbols as their abbreviations as well.

Some questions:

  1. Taking EBITDA as an example. It is arguably an abbreviation and a symbol. Should it appear in a hypothetical Table of Symbols and hypothetical Table of Abbrevations in an SRS describing a financial-domain-related problem? Do we have any examples of that happening to us right now?
  2. What is the difference between an abbreviation and a symbol?
  3. If there's little difference, then, regarding IdeaDicts (which encode "term" + abbreviation), why don't we encode symbols alongside it as well? If symbols and abbreviations identical up to the language we use in them, why is "Implementation" symbols held next to "Equational" symbols?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't believe we have nailed down the distinction between abbreviations and symbols in the grey area where they overlap. An abbreviation is a shortened form of a word or phrase. This is unambiguous, but then we sometimes use abbreviations as symbols. In GlassBR, we use several abbreviations as symbols, such as GTF (Glass Type Factor) and LDF (Load Duration Factor). These items appear in both the list of symbols and the list of abbreviations. In the table of symbols, they have units, like NFL (Non-Factored Load), which has units of Pa.

Repeating information in the symbol and abbreviations doesn't seem like the Drasil way of doing things. Should we make things that are currently abbreviations and symbols, just symbols? A symbol is a representation of a variable. Symbols can appear in equations, and they can appear in text. They are used in more contexts than abbreviations, which don't appear in equations.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we make things that are currently abbreviations and symbols, just symbols?

It sounds like we're heading towards that, I think. We currently have 'Symbol's attached to QuantityDicts. They can be associated with the 'Equational' (SRS/math) and 'Implementation' (generated code) stages to refer to the same quantity. This is arguably evidence to support this? In math, we normally call them symbols and/or variables, but in software, I think we normally call those variable names. In text, we call them abbreviations? This certainly is a grey area.

Regarding implementation, assuming we want to associate abbreviations at the IdeaDict level and that abbreviations are close enough to symbols that we think we should merge them, then we would potentially move symbols into IdeaDict (the opposite is less likely, because we want to associate [textual] abbreviations to things that are not quantities).

However, we also previously discussed wanting to split off the "display knowledge" from our "fundamental knowledge" in the chunks (I'm not sure what to call this right now). If a symbol is considered display knowledge, and so is an abbreviation, then we might be moving towards a completely different design as well.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@balacij I don't think we call things abbreviations because they are in text. We use abbreviations in text, but that is not the definition of an abbreviation. I think abbreviations still have a role in Drasil. There are some things that are abbreviations and we won't use them in equations. Abbreviations make writing easier to read and a table of abbreviations helps the reader. NASA is an abbreviation. It isn't a variable in an equation.

For the original question, I think it is the grey area where things are used as BOTH symbols and abbreviations. In those cases, I think it makes sense to just have symbols. The things that are purely abbreviations should be fine.

That is a good point about separating display knowledge and fundamental knowledge. The fundamental knowledge is that we have a load duration factor. Whether we call this LDF, or d, or $\sigma$ should be a display decision.

Abbreviations are all about display. We could call it load duration factor every time we talk about it in text and it would be semantically fine. However, it would be a tedious document to read. 😄

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was writing something, and then realized that @smiths basically said everything already (just using different words than I would have).

We need to store knowledge indexed by what they mean even though some things may end up displaying the same.

That's the usefulness of UIDs: they are our index for 'meaning uniqueness'. We should then store references to display information in our 'basic information containers'.


linearDemandQ :: QuantityDict
linearDemandQ = mkQuant'
"linearDemandQuant"
(pn "price-dependant apple demand")
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here all the pns below: I think you're abusing pn here, a different constructor should be used.

Also, these 'noun phrases' should be built compositionally! The word 'apple' should never be repeated or even mentioned in all of thse (in the source). Similarly, demand, marginal, supply and price should all be abstracted.

Nothing -- UnitDefn
(mkFunction [Real] Integer)
(autoStage $ sub cD lL)
Nothing -- Abbreviation

mSQ, mDQ, bSQ, bDQ :: QuantityDict
mSQ = mkQuant'
"ms"
(pn "marginal apple supply by price") -- proper noun?
Nothing -- UnitDefn
Real -- Should be UNITS/DOLLAR
(autoStage $ sub lM cS)
Nothing -- Abbreviation
mDQ = mkQuant'
"md"
(pn "marginal apple demand by price") -- proper noun?
Nothing -- UnitDefn
Real -- Should be UNITS/DOLLAR
(autoStage $ sub lM cD)
Nothing -- Abbreviation
bSQ = mkQuant'
"bs"
(pn "minimum supply of apples") -- proper noun?
Nothing -- UnitDefn
Real -- Should be UNITS
(autoStage $ sub lB cS)
Nothing -- Abbreviation
bDQ = mkQuant'
"bd"
(pn "maximum demand of apples") -- proper noun?
Nothing -- UnitDefn
Real -- Should be UNITS
(autoStage $ sub lB cD)
Nothing -- Abbreviation

linearSupplyQD :: QDefinition Expr
-- TODO: Missing "Real -> Integer" truncation function for the below function
linearSupplyQD = mkFuncDefByQ linearSupplyQ [applePriceQ] $ sy mSQ $* sy applePriceQ $+ sy bSQ
Comment on lines +321 to +323
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be spun off into a new ticket to implement truncation (Real -> Integer conversion).

-- ^ I'm deliberately choosing to use applePrice here because I want to use this
-- in an instance model, which (I believe) should mean that there are only
-- 'concrete' variables (i.e., problem-related variables, not the abstract ones
-- imported from the hypothetical library that would contain equilibrium)
Comment on lines +324 to +327
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How can/should we differentiate between abstract and concrete variables?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should. Don't know if we currently can.


linearSupplyDD :: DataDefinition
linearSupplyDD = ddENoRefs
linearSupplyQD
Nothing -- Derivation
"linearSupplyDD" -- "ShortName"
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought short names were for human consumption!?

[] -- Notes

linearDemandQD :: QDefinition Expr
linearDemandQD = mkFuncDefByQ linearDemandQ [applePriceQ] $ sy mDQ $* sy applePriceQ $+ sy bDQ

linearDemandDD :: DataDefinition
linearDemandDD = ddENoRefs
linearSupplyQD
Nothing -- Derivation
"linearDemandDD" -- "ShortName"
[] -- Notes

equilibriumApplePriceLinearSDQ :: QuantityDict
equilibriumApplePriceLinearSDQ = mkQuant'
"equilibriumApplePriceQ"
(cn "equilibrium apple price")
Nothing -- UnitDefn
Real -- Space
(autoStage $ sub lP $ label "A,Eq") -- Hack because of lack of support for symbol "corners" in Drasil.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lack of adequate support*. Related to #1606.

Nothing -- Abbreviation

equilibriumApplePriceLinearSDQD :: QDefinition Expr
equilibriumApplePriceLinearSDQD = mkQuantDef equilibriumApplePriceLinearSDQ $
(sy bDQ $- sy bSQ) $/ (sy mSQ $- sy mDQ)

equilibriumPriceLinearSDQIM :: InstanceModel
equilibriumPriceLinearSDQIM = imNoDerivNoRefs
(equationalModel' equilibriumApplePriceLinearSDQD)
[] -- Inputs -- What are they? Why is this only here and not in the TM?
equilibriumApplePriceLinearSDQ -- Output -- not everything will have an output!
[UpFrom (Exc, int 0)] -- Output constraints: price > 0 -- why can't I put gtZerConstr
"equilibriumApplePriceIM"
[] -- Notes ([Sentence])
Comment on lines +359 to +366
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The important bit is really the QDefinition, which contains a DefinedQuantityDict (DQD) and a defining formula for the DQD. Now:

  1. What are the "inputs"? If the DQD is a function (i.e., a function-typed variable), is it the inputs to the function? In Projectile's IM:calOfLandingDist, $p_\text{land}$ is noted as having two inputs: $v_\text{launch}$ and $\theta$, but $p_\text{land}$ is not a function. If it should be (and I don't think it should be), then why is $g$ not a part of its inputs?
  2. Why isn't the list of input and output variables and their corresponding constraints in the QDefinition. Same with the notes. Why wouldn't they be part of the QDefinition?
  3. While we're here, why not the derivation and the references?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think input and output are / ought to be theory-level concepts and not chunk-level.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that input and output should be at the theory level.

For the specific example of $p_\text{land}$, $g$ is not an input because it is a constant. Having $g$ as a constant is a modelling choice (assumption). If we were at a different elevation, or on a different planet, $g$ would be different. Drasil shouldn't force us to have one model for any part of physics (or any other science). With different assumptions, we get different models. In the projectile SRS we have gravAccelValue (The acceleration due to gravity is assumed to have the value provided in the section for Values of Auxiliary Constants). If this assumption is removed, we would have $g$ as an input (runtime variability for $g$). We could also have a different binding time for $g$ if we supported program families. We could set the binding time for $g$ as the specification time. We almost have this now, but it would have to be changed manually, instead of the specification being explicitly parameterized by its variabilities.


{-------------------------------------------------------------------------------
- Equilibrium (Physics)
-------------------------------------------------------------------------------}

10 changes: 8 additions & 2 deletions code/drasil-lang/lib/Language/Drasil/Chunk/Eq.hs
Original file line number Diff line number Diff line change
Expand Up @@ -114,8 +114,14 @@ mkQDefSt u n s symb sp Nothing e = fromEqnSt' u n s symb sp e

-- | Used to help make 'QDefinition's when 'UID', term, and 'Symbol' come from the same source.
mkQuantDef :: (Quantity c, MayHaveUnit c) => c -> e -> QDefinition e
mkQuantDef c = mkQDefSt (c ^. uid) (c ^. term) EmptyS (symbol c) (c ^. typ) (getUnit c)

mkQuantDef c = mkQDefSt (c ^. uid) (c ^. term) EmptyS (symbol c) (c ^. typ) (getUnit c) -- FIXME: Always EmptyS description? Seems dubious?

{-
DefinedQuantityDict seems like a wart. It seems like it's only necessary when
we want to assert that a quantity has an English interpretation along with a
mathematical one (i.e., a variable).
-}
Comment on lines +119 to +123
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like D-Q-D really just wants to be smart constructor as I mentioned earlier. There's no reason why a QuantityDict couldn't also have a description.


-- FIXME: See #2788.
-- | Used to help make 'QDefinition's when 'UID' and 'Symbol' come from the same source, with the term separate.
mkQuantDef' :: (Quantity c, MayHaveUnit c) => c -> NP -> e -> QDefinition e
Expand Down
2 changes: 1 addition & 1 deletion code/drasil-printers/lib/Language/Drasil/HTML/Print.hs
Original file line number Diff line number Diff line change
Expand Up @@ -293,7 +293,7 @@ makeColumns = vcat . map (td . pSpec)

-- | Renders definition tables (Data, General, Theory, etc.).
makeDefn :: L.DType -> [(String,[LayoutObj])] -> Doc -> Doc
makeDefn _ [] _ = error "L.Empty definition"
makeDefn _ [] _ = error "Definition table has no designated rows to render!"
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably something that should just be ported over to main.

makeDefn dt ps l = refwrap l $ table [dtag dt]
(tr (th (text "Refname") $$ td (bold l)) $$ makeDRows ps)
where dtag L.General = "gdefn"
Expand Down
Loading
Loading