Thanks to @Steve_Frezza, we now have the opportunity to add more boolean operators to the DoenetML repository. Steve is contributing the addition of two new components:
<iff>: The logical biconditional operator. It checks to see whether booleans are either all true or all false, i.e., if they satisfy the if and only if condition.<implies>: The logical operator that false if the first argument is true and the second argument is false; it is true in all other cases. (Or, to put another way, it is true when the first argument is ‘false’ or the second argument is ‘true’.)
I find these components quite interesting because thinking about the terms iff and implies as logical operators in this way is foreign to me. As DoenetML evolves to include other disciplines, such differences in conventions are going to become more common. One proposal is to add namespaces to DoenetML components so that one could use a component like <discreteMath:graph> to refer to the graph theory graph, where the discreteMath namespace specifies that we aren’t referring to the usual DoenetML 2D <graph>.
So, some questions for our mathematician authors. Would having the DoenetML components <iff> and <implies> as defined above be confusing or would they make sense? Would any confusion be addressed if we had a namespace like logicalOperators so that they would typically need to be accessed via <logicalOperators:iff> and <logicalOperators:implies>?
Any guidance or discussion on this potential evolution of the DoenetML language would be appreciated!
The purpose of adding these operation primitives is to better enable more variety of Discrete Math logic problems, particularly interactive truth tables, Knights and Knaves puzzles, etc. Given that , , , are already present, these two round out the set of boolean operators common to Discrete Math Logic sections, at least when I taught it.
Other operators might be useful, like XNOR, NOR, NAND, but these are binary and very easy to implement with the extant primitives. and are not that easy, hence their selection for addition.
If we move to collecting the <logicalOperators:xyz>, this seems to be a tradeoff of conciseness (nice in the scripts) against the ability to find them. If you change this nomenclature, you might want to do it for lots of collections of operators.
I realize this doesn’t help with the larger discussion about namespaces, but I think taking iff and implies as-is, with no extra qualifiers / namespaces / descriptions makes sense. They’re both used and taught in math courses. In the UMN department, for example, it would be hard to craft homework for Math 3283W without those operators.
The main oddity for me is visual. We’d usually write “p iff q”, and something like <iff>$p $q</iff> looks a little odd. But there’s not much to do about that; xml tags don’t really lend themselves to infix operators.
I agree. I don’t see much distinction between the <and>$p $q</and> which already exists, even if I normally type $p and $q instead.
What is the difference between the <and>, <or>, <not>, and <xor> that already exist and <iff> and <implies>? They would just save having to manually recreate the logic within a custom boolean.
Not that I’m against having namespaces for other tags relevant to other disciplines eventually, but these don’t seem to me like the place to draw the line. They are math.
Great, it seems like we have a consensus that we should include them without any modifications.
I’m familiar with p iff q and p implies q. I’m not familiar with <iff>false false false</iff> evaluating to true. Since the latter was my first exposure to <iff> (and I’m also worried about iff making people want an if 
), I had some initial concerns about including it.
Note: these are not symbolic operators, they are boolean operators. They cannot be used to express p iff q and p implies q where p and q are symbols. They only work like <iff>true false</iff> (giving false) and <implies>false true</implies> (giving true). I’m not aware of how I’d use those in a math setting.
But I can use them in a condition like I would with “and” and “or”, right? Sometimes iff or implies is the logic I need in a condition or award when.
Also if I were building an interactive truth table (which is part of Discrete Math, taught by the math department at our institution) it would be a lot easier to display the correct letter if the logic behind the scenes matched the operators in the truth table itself, instead of needing to build an equivalent custom boolean.
Yes, that’s exactly a condition when they would work perfectly! They would work just like the <and> and <or> components. We haven’t created infix operators, so they wouldn’t work in the way you can say <when>$a or $b</when>. Any of <when><or>$a $b</or></when> or <when><iff>$a $b</iff></when> or <when><implies>$a $b</implies></when> would work.