Symbols used only in Assumptions do not appear in Table of Symbols

[bmaclach]

I added a new symbol to SSP and noticed it was not appearing in the Table of Symbols. I think the issue is that the symbol is only used in the text of an Assumption, and when we pass over the SRS to get all the sentences from which we extract symbols, we skip over the assumptions:

Drasil/code/drasil-docLang/Drasil/ExtractDocDesc.hs

Lines 320 to 327 in 00cd3d7

	getSCSSub :: SCSSub -> [Sentence]
	getSCSSub Assumptions = []
	getSCSSub (TMs _ x) = concatMap getTM x
	getSCSSub (GDs _ x _) = concatMap getGD x
	getSCSSub (DDs _ x _) = concatMap getDD x
	getSCSSub (IMs _ x _) = concatMap getIM x
	getSCSSub (Constraints s1 s2 s3 lb) = [s1, s2, s3] ++ concatMap (getCon . (^. accessContents)) lb
	getSCSSub (CorrSolnPpties c) = concatMap getCon' c

I have a couple of questions:

• Is this the desired behaviour? If a symbol is only used in the text of an assumption, do we want it to show up in the Table of Symbols?
• If we do want it to show up in the Table of Symbols, do we have a way to do that?

For context, the symbol I added was z, used in this assumption:

[Mornix]

Looks like it was something that may have been something missed when swapping AssumpChunk to ConceptInstance.

[JacquesCarette]

That is an excellent question!!! I don't know. Though I'm leaning towards "it should". And yes, it ought to be fixable, if we decide to include it.

[smiths]

I agree in general that if a symbol is introduced in the assumptions, it should be included in the table of symbols. This particular case is interesting because z was implicitly added when the decision was made to use x and y to represent the coordinates in the plane. In the future we might want to be more explicit about our coordinate system selection. The refinement from theory to instanced model usually involves selecting a coordinate system. If our bits of knowledge were more formally connected, this kind of information would likely emerge organically.

As we move forward, I could definitely see this particular example changing. The definition of plane strain could be made much more generic than it currently is. The definition given is specific to SSP, but the concept of plane strain comes up in many mechanics problems. In the more general version, we wouldn't mention z explicitly, because we wouldn't know the specific labelling of the coordinate system. When things really come together, I could imagine a generic definition that can automatically be customized for the specific problem of interest.

I don't think we need to make plane strain more generic now, but this is something to keep in mind for the future. With respect to searching the list of assumptions for symbols, I think we should do that, especially if it is easy. It certainly could come up in other cases.

[bmaclach]

Assigning this to @Mornix as it intersects with his work for #1164.

[Mornix]

This should be corrected with the merge of #1668. If not, then #1658 is the issue.