-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lacking Clarity (and Consistency): Table of Symbols Constructors #1658
Labels
needs-action-items
A clear 'path to resolution' is needed to close any ticket.
needs-clarification
Needs a clear 'state', 'goal', 'analysis', and 'explanation' to reduce solution ambiguities.
Comments
Merged
I would be very surprised if this was intentional. [Well spotted BTW]. This likely evolved organically, and some of the divergence happened "to make things work". This Quantity vs Quantity+Concept thing has happened multiple times already. I wonder how many Quantities that aren't Concept we actually have. |
samm82
added a commit
that referenced
this issue
Jul 11, 2019
Mornix
referenced
this issue
Jul 12, 2019
Just a note that the |
This was referenced Oct 12, 2022
balacij
added
needs-action-items
A clear 'path to resolution' is needed to close any ticket.
needs-clarification
Needs a clear 'state', 'goal', 'analysis', and 'explanation' to reduce solution ambiguities.
labels
Apr 26, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
needs-action-items
A clear 'path to resolution' is needed to close any ticket.
needs-clarification
Needs a clear 'state', 'goal', 'analysis', and 'explanation' to reduce solution ambiguities.
Table of Symbols Constructors are in an odd place.
Drasil/code/drasil-docLang/Drasil/DocumentLanguage.hs
Lines 78 to 83 in f43b3c1
Drasil/code/drasil-docLang/Drasil/DocumentLanguage.hs
Lines 119 to 124 in f43b3c1
The Constructors seem fairly logical. A simple constructor, and a more customizable one. While this is something that could benefit from a smart constructor, it isn't something of super high priority.
If we look at what the constructors do to create the table of symbols, the lack of clarity (should) become[s] clear.
Drasil/code/drasil-docLang/Drasil/DocumentLanguage.hs
Lines 267 to 274 in f43b3c1
Drasil/code/drasil-docLang/Drasil/DocumentLanguage.hs
Lines 279 to 293 in f43b3c1
Drasil/code/drasil-database/Database/Drasil/SystemInformation.hs
Lines 23 to 31 in f43b3c1
A
TSymb
constructor takes all members of the_quant
field to print. This can be something such as a[QuantityDict]
or[DefinedQuantityDict]
. Nothing too wrong with this constructor, although it could be a great candidate for automation.Looking that the other constructor,
TSymb'
(and related function --mkTSymb
), we can see that an additional constraint is required:Concept
. As a result of this, the_quants
field is not pulled as it doesn't contain theConcept
constraint, instead the_concepts
field ofSystemInformation
is used. With this being the case, we cannot enumerate symbols which are missing aConcept
. This alienatesQuantityDict
,UnitaryChunk
(which GlassBR makes heavy use of), among others. The upside is, with theTSymb'
constructor, symbols are pulled automatically from the document.This restriction seems a (little) arbitrary and hacky, especially if
LFunc
isTerm
. We are left with some symbols (possibly) being excluded. Moreover, it seems odd that if we want to describe theterm
of a symbol we can get "all" symbols, whereas when we describedefn
we may only display a subset.TL;DR: Is it intentional that
TSymb'
takes a subset of all symbols and thus a Table of Symbols would be "incomplete"?The text was updated successfully, but these errors were encountered: