Changes between Version 1 and Version 2 of UnresolvedInfixExpressions

Timestamp:

Nov 6, 2010 5:52:07 AM (9 years ago)

Author:

reinerp

Comment:

--

UnresolvedInfixExpressions

@@ -19 +19 @@
 data Exp = 
      ...
-     | UnresolvedInfixE [(Exp, Exp)] Exp Section
+     | UnresolvedInfixE [(Exp, Op)] Exp Section
      ...
 }}}
-and we add the following datatype:
+and we add the following type synonym and datatype:
 {{{
+type Op = Exp
 data Section = NoSection
              | LeftSection Exp
@@ -96 +97 @@
  InfixE (Just e1) op Nothing      <--->    UnresolvedInfixE []        e1 (RightSection op)
  InfixE Nothing   op Nothing   <------------ this will be rejected when splicing.
+ e                                <--->    UnresolvedInfixE []        e NoSection
 }}}
-  In view of the previous dot point, we see that there is also no special treatment for trees of {{{InfixE}}} and {{{UnresolvedInfixE}}} constructors.
+  In view of the previous dot point, we see that there is no special treatment for trees of {{{InfixE}}} and {{{UnresolvedInfixE}}} constructors. 
+  [[BR]]
+  These equivalences tell us that {{{UnresolvedInfixE}}} expressions are unambiguous if either:
+     * the list has length 0; or
+     * the list has length 1 and we have {{{NoSection}}}
+  The redundancy introduced by these equivalences is discussed further down.
  * The following two syntax trees:
 {{{
@@ -113 +120 @@
   This demonstrates that it is necessary to include sectioning information in the {{{UnresolvedInfixE}}} constructor, as we do not want to silently convert illegal section expressions (such as {{{(2 + 3 +)}}} when {{{(+)}}} is right-associative) into legal, but different, section expressions (say {{{((2 + 3) +)}}}).
 
+== Template Haskell Quotations and {{{UnresolvedInfixE}}} ==
+If we have a Template Haskell quote containing infix expressions, for example
+{{{
+ foo = [| x + y * z |]
+}}}
+then how will these infix expressions be represented?
+
+The important point is: '''the infix expressions will have already been resolved'''. (This is because GHC knows that {{{(+)}}} and {{{(*)}}} in the above example refer to the in-scope ones, so the fixities are known when the quote is constructed -- so we should certainly communicate this information.)
+
+The precise representation of the (already-resolved) infix expressions will depend on whether the {{{InfixE}}} constructor will be removed, as discussed in the following section. At present, we can say the following:
+ * if the {{{InfixE}}} constructor is ''not'' removed, then (already-resolved) infix expressions will be written in terms of the {{{InfixE}}} constructor, as is currently the case.
+ * if the {{{InfixE}}} constructor ''is'' removed, then infix expressions will be written in terms of unambiguous {{{UnresolvedInfixE}}} expressions (see above for discussion of when {{{UnresolvedInfixE}}} expressions are unambiguous).
+
+== Redundancy; should {{{InfixE}}} be removed? ==
+Because of the equivalences discussed earlier, we see that the {{{InfixE}}} constructor will be completely redundant after these changes. It is not clear to me what this means for design. The following are some options.
+ * We could remove the {{{InfixE}}} constructor. Unfortunately, this means that every TH program which generates infix expressions would have to be changed.
+ * We could modify the {{{UnresolvedInfixE}}} constructor to remove the ambiguity -- the idea being that {{{UnresolvedInfixE}}} is reserved for infix expressions which are truly ambiguous. This would involve requiring the list to be of length >=2 when we have {{{NoSection}}}, and length >=1 when we have {{{LeftSection}}} or {{{RightSection}}}. To do this the most obvious way ("unrolling" part of the list) unfortunately makes the constructors very large:
+{{{
+ data Exp = 
+    ...
+    | UnresolvedInfixE       [(Exp,Op)] Exp Op Exp Op Exp
+    | UnresolvedLeftSection  Op Exp Op Exp [(Op,Exp)]    
+    | UnresolvedRightSection [(Exp,Op)] Exp Op Exp Op
+}}}
+ * We could put up with the redundancy, and perhaps write a {{{convertUnambiguousToInfixE :: Exp -> Exp}}} which converts all unambiguous {{{UnresolvedInfixE}}}s to {{{InfixE}}}s.
+
+== Is there a better definition of {{{UnresolvedInfixE}}}? ==
+The definition of {{{UnresolvedInfixE}}} I have given above is somewhat ugly, because it suggests an asymmetry which is not actually present. However, it manages to enforce the precise relationship that must hold between the number of operators and the number of operands -- which, for example, {{{InfixE}}} does not currently enforce.
+
+Is there a better definition of this constructor?