Remove multiple occurrences of definition of DD as Data Definition

[elwazana]

@JacquesCarette @szymczdm Hello Dr. Carette ad Dan, I saw this in the notes directory:

Drasil/notes/DrasilPotentialTasks.txt

Line 88 in 1e11a50

- Remove multiple occurrences of definition of DD as Data Definition

I was wondering if I could get clarification of this potential task?

[JacquesCarette]

This is somewhat non-trivial. Surface-wise, it seems straightforward: the String "DD" (alone or as a prefix) occurs multiple times in Drasil (whether in Language, Data or Example). It should occur in there at most once.

Fixing that properly may well intersect with the work on ContentChunk and ContentInstance that @Mornix is doing. Though the first thing to do would be to find all occurrences of "DD" and figure out why they exist the way they do.

[niazim3]

"DD" is used in getDefName:

Drasil/code/Language/Drasil/Document.hs

Lines 178 to 185 in 8627a38

	-- | Automatically create the label for a definition
	getDefName :: DType -> String
	getDefName (Data c) = "DD:" ++ concatMap repUnd (c ^. uid) -- FIXME: To be removed
	getDefName (Theory c) = "T:" ++ concatMap repUnd (c ^. uid) -- FIXME: To be removed
	getDefName TM = "T:"
	getDefName DD = "DD:"
	getDefName Instance = "IM:"
	getDefName General = "GD:"

---

It can be seen in makePairs:

Drasil/code/Language/Drasil/HTML/Import.hs

Lines 142 to 147 in 8627a38

	-- | Translates definitions
	-- (Data defs, General defs, Theoretical models, etc.)
	makePairs :: HasSymbolTable s => DType -> s -> [(String,[H.LayoutObj])]
	makePairs (Data c) m = [
	("Number", [H.Paragraph $ spec (missingAcro (S "DD") $ fmap S $ getA c) m]),
	("Label", [H.Paragraph $ spec (titleize $ c ^. term) m]),

---

And here:

Drasil/code/Language/Drasil/Reference.hs

Lines 227 to 231 in 8627a38

	instance Referable QDefinition where -- FIXME: This could lead to trouble; need
	-- to ensure sanity checking when building
	-- Refs. Double-check QDef is a DD before allowing
	refAdd d = "DD:" ++ concatMap repUnd (d ^. uid)
	rType _ = Def

---

It is also the acronym for the dataDefn CI:

Drasil/code/Data/Drasil/Concepts/Documentation.hs

Line 18 in 8627a38

dataDefn = commonIdea "dataDefn" (cn' "data definition") "DD"

---

And is hardcoded in refDD:

Drasil/code/Example/Drasil/DocumentLanguage/RefHelpers.hs

Lines 42 to 44 in 8627a38

	-- | Automatically reference DDs by number.
	refDD :: RefMap QDefinition -> QDefinition -> Sentence
	refDD db c = customRef c (shortname' $ "DD" ++ (show $ snd $ modelLookup c db))

[niazim3]

Report on the uses of the above-mentioned functions:

---

getDefName

• used to help define Contents as an instance of HasShortName
• used to help define Contents as an instance of Referable

I believe Contents will no longer be instances of the HasShortName and Referable classes once LabelledContent is implemented completely. Although, since LabelledContent will replace the use of Contents for referencing purposes, not sure if this function can be removed or not yet...

---

makePairs

• HTML
  • used in lay

    Drasil/code/Language/Drasil/HTML/Import.hs

    Lines 76 to 78 in 8627a38

    	-- | Translates from Contents to the HTML Representation of LayoutObj.
    	-- Called internally by layout.
    	lay :: HasSymbolTable s => Contents -> s -> H.LayoutObj

  • which is used in layout
    

    Drasil/code/Language/Drasil/HTML/Import.hs

    Lines 60 to 61 in 8627a38

    	-- | Translates from LayoutObj to the HTML representation of LayoutObj
    	layout :: HasSymbolTable s => Int -> SecCons -> s -> H.LayoutObj

  • which is not used anywhere at the moment! so it can be removed...
• TEX
  • no hardcoded "DD", although used by layout, which is used by sec, which is used in createLayout, which is used by makeDocument, which is not used anywhere! so it can be removed...
  • Tex uses the makeDocument discussed next
• Printing
  • no hardcoded "DD", although used by layout --> sec --> createLayout --> makeDocument, which is used by genTeX and genHTML to produe the docs

---

refDD

• defined in RefHelpers.hs
• used in modelTraceTable

  Drasil/code/Example/Drasil/DocumentLanguage/TraceabilityMatrix.hs

  Lines 7 to 12 in 8627a38

  	modelTraceTable :: ModelDB -> Contents
  	modelTraceTable mdb = Table
  	[ EmptyS : crossListItems ]
  	where crossListItems = getRefs refTM tmDB ++ getRefs refGD gdDB ++
  	getRefs refDD ddDB ++ getRefs refIM imDB
  	getRefs f db = map (f db) (modelsFromDB db)

  which is not used anywhere (yet?) so add a fixme here to remind that refDD should probably not be used
• SSP/DataDefs.hs uses it in its derivation sentences

  Drasil/code/Example/Drasil/SSP/DataDefs.hs

  Lines 35 to 37 in 8627a38

  	ddRef :: QDefinition -> Sentence
  	ddRef = refDD (ddRefDB sspRefMDB)

• SWHS/DataDefs.hs is used to define ddRef, used once in IMods for this example

---

dataDefn CI

• actually not related to this issue
• used for lists of acronyms for the examples
• used to define the SRS' data defn section
• used in intros for assumptions and general definitions, etc.

---

Proposal

For now, can I remove the code that is not used in the Tex and HTML "Import" files, linking the work to issue #714? @szymczdm
Additionally, can the other bolded text above, also be worked on? @JacquesCarette

[szymczdm]

@niazim3 Are you sure layout isn't used in HTML import.hs? I did a grep and it shows up on line 73 (of the current master):

https://github.com/JacquesCarette/Drasil/blob/master/code/Language/Drasil/HTML/Import.hs#L73

[szymczdm]

I just realized, if it's the same as the TeX one where it's used in a bunch of places and ultimately not called, then yeah, it can be removed.

[niazim3]

Since the merge of #754, the only main hardcoded "DD" instance that this issue should continue to track are from getDefName and refDD.

[JacquesCarette]

Ok, good.

[JacquesCarette]

I just want to double-check that the comment above (regarding the status post-merge of #754) is still accurate? It seems like things have changed quite a bit around this area.

[JacquesCarette]

So I've checked that this is almost fixed. There is still some duplication around this, but all the hard parts have been done. Seems that there are some silly things that have arisen in the meantime that need to be dealt with.

[JacquesCarette]

This remains "almost fixed", but things have gotten a touch worse. There are now 3 occurrences of DD, where 2 seem to be duplicates, and the third (in sectionci) seems just plain wrong:

MacBook-Air-2:code carette$ egrep -e "\"DD\"" */*/*.hs */*/*/*.hs */*/*/*/*.hs */*/*/*/*/*.hs */*/*/*/*/*/*.hs
drasil-lang/Data/Drasil/IdeaDicts.hs:dataDefn    = commonIdeaWithDict "dataDefn"    (cn' "data definition")    "DD"   [softEng]
drasil-lang/Language/Drasil/Document.hs:sectionci    = commonIdeaWithDict "sectionci"    (cn' "section")                   "DD"        [documentc]
drasil-data/Data/Drasil/Concepts/Documentation.hs:dataDefn    = commonIdeaWithDict "dataDefn"    (cn' "data definition")                             "DD"        [softEng]

@samm82 can you track down the uses of all 3 of the above symbols?
Also, we should do the same with TM, GD and IM too.

[samm82]

@JacquesCarette sectionci is never used and can be removed without consequences (yay!)

The dataDefn in drasil-lang is for use in drasil-theory, since it can't use the one in drasil-data because -data is dependent on -theory. The simplest fix would be use remove the one in -data and replace all instances of it from the one in -lang (although it seems weird to me to have a Data directory in the -lang package.)

Should I go ahead with this?

[JacquesCarette]

Go ahead and delete sectionci.

The reason to have Data. in the drasil-lang package is that part of the Drasil Language is defined as "data" instead of as "code". It's as simple as that. So yes, delete the duplicate information from drasil-data.

[samm82]

Not a huge deal, but do you prefer thModel and inModel or theoryMod and instanceMod? @JacquesCarette

EDIT: Unless you feel strongly I'm going to go with thModel and inModel.

[samm82]

Also, the duplicate (that I removed) used "theoretical model" as the definition, while the other used "theory model". For now I'm going to keep it as "theoretical model" to reduce the changes to stable, but I can change it if desired.

[JacquesCarette]

I was going to say the opposite BUT I don't feel strongly about it!