Sentence vs concept-level combinators

[JacquesCarette]

This issue should eventually apply to all examples, but it can start at DblPendulum. It should be done after the first part of #2398 is done.

Drasil/code/drasil-example/Drasil/DblPendulum/Unitals.hs

Lines 47 to 57 in dc6da83

	lenRod = makeUCWDS "l_rod" (cn "length of rod")
	(phrase len `the_ofThe` S "rod")
	(sub cL lRod) metre
	pendDisplacementAngle = makeUCWDS "pendDisplacementAngle" (cn "displacement angle of pendulum")
	(phrase angle `the_ofThe` phrase pendulum)
	(sub lTheta lP) degree
	initialPendAngle = makeUCWDS "initialPendAngle" (cn "initial pendulum angle")
	(S "the initial angle of" +:+ phrase pendulum)
	(sub lTheta lI) radian

Note the (phrase anglethe_ofThe phrase pendulum) (and same with rod). What's going on is that there is a sentence-level combinator the_ofThe being used. That's a fine thing, but in common use, it's applied on concepts, so explicit extraction needs to happen.

Better would be a combinator, in a separate package that can be imported qualified (say as C) so that this could instead be angle C.the_ofThe pendulum. In fact, even better would be if the sentence-level combinator was imported qualified (as S) and the concept-level ones not qualified, so that this could be angle the_ofThe pendulum or even the angle ofThe pendulum (there's a the combinator too!).

The point is that this piece of English actually is very semantic. It embodies the pattern "the unique attribute X associated to the unique object Y" where here X = angle and Y = pendulum. Recognition of the semantics of what the English is actually saying will let us generalize things.

This is another issue that requires some local fixes, as well as the creation of further issues that detail the future work that needs to be done to improve the examples overall.

[Ant13731]

My first idea to go about completing this was to import qualified Utils.Drasil, but after looking into it, both the sentence-level combinators and the concept-level ones are both in Utils.Drasil. A decent workaround might be to import qualified Utils.Drasil.Sentence first and then import Utils.Drasil as usual. However, I think this might have the result of importing two copies of Utils.Drasil.Sentence which might interfere the concept level combinators. I'm not sure what the best route to take is here.

[Ant13731]

We could also split up Utils.Drasil into two separate files (the concepts go with the general file while the sentence combinators get their own separate imports (this way they can be qualified). I got something to work but it's a really hacky solution that's probably worse than before.

[JacquesCarette]

A great big Utils.Drasil is probably not a good idea (it has grown too much). Having Utils.Drasil.Sentence and Utils.Drasil.Concepts sounds reasonable. The "rest" can be in Utils.Drasil until we figure out what to do with those when an issue arises.

[Ant13731]

As a note to myself, #2423 should also add a sentence ending operator

[Ant13731]

I'm having a little bit of trouble incorporating :. as an operator. I looked it up and I think the : is reserved for data/type constructors, so implementing it as a function would be impossible. I also tried to use the postfixoperator language but I keep getting parse errors when trying to implement it. Is there an example of other postfix operators I could take a look at?

Parse error in pattern: (+.)
|
| ((+.) a) = a :+: S "."
|

(this was also posted under the PR but that has been merged and closed so I put it here too)

[balacij]

For the postfix operators, you need to enable the PostfixOperators language extensions (e.g., {-# LANGUAGE PostfixOperators #-}) and you shouldn't need it to be in parantheses there. In your code snippet, I believe that Haskell thinks you are trying to do a pattern match there which is why it gave you a parse error.

Here's a small example of a postfix operator:

(+..) :: Integer -> Integer
(+..) n = n + 10

b :: Integer
b = (10 +..)

Regarding the :., I'm not entirely sure. Did you want something like this?

[Ant13731]

I wanted to make an operator that would take a sentence and just append a period to the end of it. Dr. Carette suggested I call it :. but I don't think normal function names can start with a :. I have also tried implementing it in the way you suggested but I'm not sure how to use it in practice. I have been getting the following error:

* Couldn't match expected type `t0 -> t1'
                  with actual type `Sentence'
    * The operator `(+.)' takes two arguments,
      but its type `Sentence -> Sentence' has only one
      In the expression: ((S "So then") +.)
      In an equation for `angFrequencyDerivSent2':
          angFrequencyDerivSent2 = ((S "So then") +.)
    |
248 | angFrequencyDerivSent2 = ((S "So then") +.)
    |

Would it be better to define it as a Data Constructor instead like :+:?

[balacij]

Hmm, do you mind showing your full code snippet (w/ +. definition)?

[Ant13731]

Here is the current definition:

-- | Helper which appends a period to the end of a sentence
(+.) :: Sentence -> Sentence
(+.) a = a :+: S "."

And here is where I was trying to implement it (as a test to see if it worked):

angFrequencyDerivSent2 = ((S "So then") +.)

[JacquesCarette]

So does that now work?

[Ant13731]

It works perfectly as a normal function like this:

angFrequencyDerivSent2 = ((+.) (S "So then"))

but it gives me this error when placed as a postfix:

* Couldn't match expected type `t0 -> t1'
                  with actual type `Sentence'
    * The operator `(+.)' takes two arguments,
      but its type `Sentence -> Sentence' has only one
      In the expression: ((S "So then") +.)
      In an equation for `angFrequencyDerivSent2':
          angFrequencyDerivSent2 = ((S "So then") +.)
    |
248 | angFrequencyDerivSent2 = ((S "So then") +.)
    |

[JacquesCarette]

Did you enable PostfixOperators in the file where you try to use it? Enabling it at the definition site doesn't help. [No, this is not obvious!]

[Ant13731]

Yes that works thanks!

[Ant13731]

Back to the original issue, the current set of functions available for concept-level combinations block out the case of using NounPhrases to get other NounPhrases. They only accept NamedIdeas, of which NP is not a part of. This means that we can't chain them together nicely (without converting to a Sentence first). @JacquesCarette, should I make a set of similar functions but that can be used by accepting and outputting NounPhrases?

[JacquesCarette]

So I think we'll want to think about levels of combinators:

1. Sentence. The worst, as this is glorified strings.
2. NounPhrase. This is slightly better, as it allows proper capitalization and pluralization.
3. NamedIdeas. This is best, as it properly represents a new idea that is formed from conjoining more basic ones. This is where we want to go.
4. Things 'above' NamedIdeas might also be amenable to joining. We're not there quite yet, but this is also something to aim for.

Right now, level 3 combinators are best, but I'm not sure how many we'll truly be able to create. We should keep our eyes open for level 4 too. When that's not possible, then yes, some chainable level 2 combinators would be better than dropping all the way down to 1.

Do try to keep notes on this. There might be a paper here.