Drasil: Removing Sentence constructors
@szymczdm @JacquesCarette Hello Dr. Carette and Dan, @samm82 and I were looking through notes folder for stuff we could possibly work on and we were wondering what you meant by:
https://github.com/JacquesCarette/Drasil/blob/628b54d0e17d0b818be0c36480416e5bf37a2139/notes/DrasilPotentialTasks.txt#L87
Do you mean these?
https://github.com/JacquesCarette/Drasil/blob/628b54d0e17d0b818be0c36480416e5bf37a2139/code/Language/Drasil/Spec.hs#L39-L86
elwazana
All 36 comments
I meant both those (which are almost always used as hacks, especially sParenNum and sSqBr). I also think that some of the cases of Spec perhaps shouldn't be there. But that requires more analysis & thinking. I have already removed the ones that were easy to remove.
JacquesCarette
on 22 Jun 2018
sParenNum
Used here for a list:
https://github.com/JacquesCarette/Drasil/blob/628b54d0e17d0b818be0c36480416e5bf37a2139/code/Example/Drasil/GlassBR/Assumptions.hs#L44-L55
sSqBrNum
Used here for a reference:
https://github.com/JacquesCarette/Drasil/blob/628b54d0e17d0b818be0c36480416e5bf37a2139/code/Example/Drasil/GamePhysics/Body.hs#L192-L197
I'm not really sure how these usages are hacks.
samm82
on 22 Jun 2018
- There should be 'semantic' combinators for building lists. These could then have styles applied to them, that would control how they get rendered. Right now this is hard-coded in the example.
- All of these should be using references, via labels. The square brackets should be, again, styles applied to the display of references.
JacquesCarette
on 22 Jun 2018
- So should we define a new function for building a list and could we use
sParenNumto achieve that? - @elwazana says that the change for
sSqBrNumwill be made onceLabelis fully implemented. Is that what you are referring to?
samm82
on 22 Jun 2018
- Yes and yes. [
sParenNumused internally in printing is fine. But it should not be exported] - Yes.
JacquesCarette
on 22 Jun 2018
We have a design proposal for an sList function. It will take a list of [Sentence] and return a Sentence. Ie:
[a, b, c] -> (1) a; (2) b; and (3) c (if commas exist in any of a, b, or c) or
[a, b, c] -> (1) a, (2) b, and (3) c (if commas don't exist in any of a, b, or c).
It will make a list from 1 to the length of the list, map sParenNum onto it, intersperse it with the original list (ie. [(1), a, (2), b, (3), c] all sentences), then recursively concatenate pairs of them with spaces and use the foldlList function (that should probably be pulled out and use semicolons if commas are present in the inputs):
to concatenate them each pair (ie. "(1) a") and add the "and" before the last one.
samm82
on 22 Jun 2018
I would definitely not put such a combinator in L.D.HTML.Print. It's a hack if that is where foldlList is now.
Such a combinator makes sense, but it should be parametrized by a separator as well as a means of decorating it with "numbers" (which could be a), b), c) BTW).
This is exactly the kind of thing that the higher-level enumeration structures are built to handle. So this piece of text should be more structured, rather than hand-printed into a low-level Spec.
JacquesCarette
on 22 Jun 2018
- Where should
foldlListbe moved to? Probably the same place assList, right? - What do you mean by "separator"? The numbering system or the commas/semicolons?
- How many numbering systems should be supported? Numbers, lowercase, uppercase, Roman numerals / periods -> 1., parenthesis -> 1), parentheses -> (1)?
samm82
on 25 Jun 2018
As far as sSqBrNum, it just seems like the manifestation of smiths/caseStudies#31, which can easily be fixed. @smiths @JacquesCarette
samm82
on 27 Jun 2018
@samm82 I agree. There might be other cases where we want square brackets around a sentence, but when that sentence is citation information, the format of the citation should be automatic. We definitely should remove all hard-coded citation numbers in the Drasil code. These aren't maintainable.
smiths
on 27 Jun 2018
- There are already things named
fold?List[replace the ? with either nothing or 'l' or 'r'], probably belongs with them. - By "separator" I mean the commas/semicolons.
- Well, all of the ones that HTML and LaTeX support natively...
JacquesCarette
on 27 Jun 2018
Just to clarify - as is, this example is an inline list - that should be preserved, correct? @JacquesCarette @smiths Because this could either be hardcoded in as per the previous proposal, or ideally, could make use of HTML's and LaTeX's inline lists.
samm82
on 28 Jun 2018
Yes, we want to preserve the idea of in-line lists. I also agree that the generated html or latex code should use these languages in-line list code.
smiths
on 28 Jun 2018
I'm trying to add a package to the TeX preamble that will allow for changing the numbering system and for inline lists, and I've updated the stable for the examples, but log.log isn't empty and I'm not sure why.
Commit: 4e8d164
samm82
on 28 Jun 2018
log.log is badly named -- that's the logfile for 'tiny' !!! Maybe open an issue to rename that, so that it's not so hard to debug in the future.
JacquesCarette
on 28 Jun 2018
@JacquesCarette the only function that exists as you describe it is foldlList and is defined here:
It is also in HTML/Print (as found out before), but only locally, and slightly different
Can we define our new list-making function with foldlList in SentenceStructures?
EDIT: I forgot we weren't going to hardcode them - never mind
samm82
on 19 Jul 2018
I see you edited your last comment, but what's the status on this issue then?
szymczdm
on 20 Jul 2018
I think this might have to wait until after the merge of #906, but we'll have to implement a way to print a list using the methods native to LaTeX and HTML - I'll start by compiling a list of what common methods there are so we can at least start with those.
samm82
on 20 Jul 2018
After looking around for a while, it doesn't look like HTML allows for inline lists using parentheses as we desire, so I think we should hardcode this, but more generally than we are right now. We should make a foldInlineNumbered function that would use sParenNum (but not export it) that would work with foldlList as mentioned before. It wouldn't be easy to use Roman numerals, however.
Should we still try and use LaTeX's inline list functionality? This would be done via \begin{enumerate*}[label=(\arabic*)] using \usepackage[inline]{enumitem}. I honestly think this would be better just to hardcode.
samm82
on 20 Jul 2018
And should the separators be passed in our automatically generated? I think they should be automatically generated, but it might be easier to manually input them.
samm82
on 20 Jul 2018
A preliminary version of this implementation has been added here: d13efb41. Let me know if this is a bit "hacky". I was thinking of implementing separate functions for letters, but I could just define an EnumType data type that consists of Number, Upper, and Lower, and use pattern matching to determine what kind of enumeration should be used. I could do the same for a WrapType for Period or Parentheses, so it would be easier to add more implementations in the future as desired @szymczdm @JacquesCarette
samm82
on 20 Jul 2018
I went ahead and implemented EnumType in 086536e71 and made the function look a little nicer. There is a helper function makeList that isn't exported. Do we want roman numerals to be used? Because that would be a little bit messier, but very possible.
Also a note, the "separator" that @JacquesCarette mentioned earlier has to be passed in as a Sentence, so currently that is being done by S ";", but this could be changed.
samm82
on 20 Jul 2018
TODO
- [x] Revert commit 4e8d164cd745cc737bf (if we are sure we want to hardcode)
- [x] Add
WrapType - [x] Remove
Paren - [x] Add
SepType-> removeS ";"hack - [x]
Add Roman Numerals toEnumType - [x] Add
FoldTypeconsisting of {List,Options} to facilitate function merge - [x] Merge functions (
foldlList,foldlOptions,makeList)
- [x] Remove
foldlList- original - [x] Remove
foldlOptions
- [x] Remove
- [x] Switch to pattern matching instead of guards
samm82
on 23 Jul 2018
@JacquesCarette Would you like roman numerals to be a feature, or should we wait until we want to actually use it?
Also, is there anything else you would like done with the new foldlList function?
samm82
on 24 Jul 2018
If it takes < 1 hour to implement, go ahead, otherwise let's wait.
JacquesCarette
on 25 Jul 2018
Traditional Roman numerals go up to 3'999, but given that upper and lowercase letters both have 26 characters each, should I cap Roman numerals at 100? I already have a Haskell function that generates Roman numerals that I did as an exercise. The easiest way to do it is with | clauses though 馃槵
samm82
on 25 Jul 2018
I believe that both LaTeX and HTML know how to generate Roman numerals, as an option to their generators of enumerations. So there should be no need for us to generate these!
JacquesCarette
on 25 Jul 2018
But the current implementation of inline lists involves hardcoding the enumerators. Can we still use the LaTeX and HTML Roman numerals? I would assume they would still have to be hardcoded.
samm82
on 25 Jul 2018
Sigh. Then the current implementation of lists should be fixed, at least in LaTeX. Not sure about HTML, we might have to hardcode. Sigh.
JacquesCarette
on 25 Jul 2018
I just assumed that since we'd have to hardcode in HTML, instead of having two separate implementations, we would just hardcode both, especially since it was hardcoded even more so originally. So what should we do now? We could also just wait on adding Roman numerals since we don't use them yet and keep the hardcoding, but that would essentially result in replacing a hack with a lesser hack. Or, we could add an InlineList data type somewhere and hardcode it in HTML (using the new foldlList function and moving foldlEnumList to drasil-printing) and use the native LaTeX?
samm82
on 25 Jul 2018
I think it would be simpler to just wait on adding roman numerals.
JacquesCarette
on 25 Jul 2018
So to reiterate the original issue, sParenNum has been removed (thanks to the new list function(s)), and sSqBrNum will/should probably be removed after Label is implemented. Are there any other functions that can be (relatively easily) removed, or should we leave it to focus on more crucial work by marking it with the "waiting on label" label to revisit later?
samm82
on 26 Jul 2018
I'll also open a PR for the branch where the change was made (if you're sure the hardcoding is OK, at least for now).
samm82
on 26 Jul 2018
Leave it to focus on more crucial work. And hardcoding is ok for now.
JacquesCarette
on 26 Jul 2018
It seems as if Spec.hs has been deleted and the only helper function of this sort is sParen (in Sentence.hs), so I'm closing this issue.
samm82
on 1 May 2019
Nice to see you jumping right back in @samm82! I can tell that @JacquesCarette and I better get thinking of additional tasks to keep you busy. 馃槃
smiths
on 1 May 2019
Related issues
samm82
路
10Comments
samm82
路
4Comments
samm82
路
10Comments
smiths
路
11Comments
smiths
路
8Comments