diff options
| -rw-r--r-- | stdlib/infix.tl | 7 | ||||
| -rw-r--r-- | txr.1 | 96 |
2 files changed, 42 insertions, 61 deletions
diff --git a/stdlib/infix.tl b/stdlib/infix.tl index 7eee5ad7..1d8f8066 100644 --- a/stdlib/infix.tl +++ b/stdlib/infix.tl @@ -292,12 +292,7 @@ (finish-infix (parse-infix exp)))) ((match-case exp ([] exp) - ([@nil] exp) - ([. @toks] - (let ((iexp (infix-expand-hook toks env nil))) - (if (eq iexp toks) - exp - ^[,iexp]))) + ([. @nil] exp) (@(require (@tok) (null type-sym) (or (not (bindable tok)) @@ -54199,12 +54199,20 @@ alternatives: Transform the form through .codn parse-infix . .IP 2. -Recognize the form as one of several cases to be rewritten into -a different form by the auto-detection logic itself. +In certain cases, convert a one-element compound form to that element; +for instance +.code "(a)" +to +.codn "a" . .IP 3. Recognize the form as "phony infix" and apply a trivial transformation. .IP 4. Pass the form through; decline to perform a transformation. +In addition to compound forms which are not indicated for processing through +the above alternatives 1-3, transformation is also not performed on forms which +are atoms. Square bracket forms are also left untransformed. In the infix +syntax, square bracket expressions appear as a postfix notation for array +indexing, but in that role they are not forms. .RE A form is recognized as applicable for @@ -54339,72 +54347,41 @@ expansion hook will replace by .codn "(+ i j)" . -A form not eligible for -.code parse-infix -may be transformed by infix the auto-detection logic. Three cases -are treated this way: -.RS -.IP 1. -A square brackets form containing one element is left untransformed. -.IP 2. -A square brackets form is temporarily converted to an ordinary -form, and processed recursively through the auto-detection rules. -If the recursive rules provide a transformation, then the transformed form is -inserted as the single element of a new square brackets form and -returned instead of the original square brackets form. Otherwise no -transformation takes place to the original square -.IP 3. -An ordinary compound form containing one element is replaced by -that element if these conditions hold: the form is not a valid function +Alternative 2 above deals with compound forms containing one element. +Such a compound form may be replaced by its contained +element, if the if these conditions hold: the form is not a valid function call form, and if the element is a bindable symbol, that symbol has a binding as a lexical variable or a global variable. -.RE - -For instance, the form -.code "[a + b]" -falls under rule 2, and is temporarily considered to be -.codn "(a + b)" . -That expression is detected for infix transformation, and translated to -.codn "(+ a b)" . -Therefore, the original -.code "[a + b]" -form is replaced by -.codn "[(+ a b)]" . - -After this replacement, -.code "[(+ a b)]" -is again subject to the auto-detection logic. This time it is recognized -as a square brackets form which contains one element, and is left -untransformed. -The form +For example, the form .code "(42)" is replaced by .code 42 -under rule 3. - +under rule 2. The form .code "(list)" -falls under rule 3, but doesn't meet its conditions, assuming that the +is not transformed, assuming that .code list -symbol refers to the standard function. The form is then a valid function -call. - +symbol refers to the standard function, because it is then +a function call form. In the form .codn "(let ((a 3)) (a))" , -the subform +if the symbol +.code a +does not also refer to a function, the subform .code "(a)" -meets rule 3, provided there isn't a function named +is transformed to .code a -in scope. In that case it is transformed to -.codn a . +because +.code a +is a variable. The form .code "((a [i + 1]))" is transformed to .code "(a [i + 1])" -by rule 3 and processed again. This time it falls under one of the earlier +and processed again. This time it falls under one of the earlier rules for applying .code parse-infix which will transform it to @@ -54416,8 +54393,8 @@ expansion hook will then turn into .codn "(+ i 1)" . -A form not falling into any of the above rules is recognized as "phony infix" -if it conforms to one of two situations: +A form not falling into any of the above rules may be processed under +alternative 3 as "phony infix", if it conforms to one of two situations: .RS .IP 1. It consists of at least three elements, where the first element is not @@ -54489,16 +54466,25 @@ because it doesn't have three or more elements. Only compound expressions are recognized as infix. A sequence of atoms like .code "a * b" -isn't an expression. It may be a subexpression of an infix +isn't an expression, because it isn't an object. +It may be a subexpression of an infix expression, but a whole infix expression is always a Lisp list, which means that it is notated with parentheses: .codn "(a * b)" . -Informally speaking, the Infix Syntax feature does not eliminate the -outer parentheses. +The infix syntax feature doesn't process parentheses because +it works with the object representation of expressions, not +with the printed syntax. This is why parentheses do not appear +in the operator table given int the following section. +However, in the Interactive Listener it is possible to work +without outer parentheses, and also in infix simultaneously: +see the variables +.code *listener-auto-compound-p* +and +.codn *listener-auto-infix-p* . Whitespace is required between atoms in infix expressions, because they are ordinary Lisp lists. The infix feature does not introduce -any new token-level syntax. The expression +any new character-level or token-level syntax. The expression .code "(b + a ++)" cannot be written .code "(b+a++)" |