well-formedness should disallow 1 == 1 == true == 1 == false

[sorawee]

well-formedness should disallow 1 == 1 == true == 1 == false, 1 <> 1 <> true, 1 < 2 < 3 (this results in error but because Boolean cannot be less than anything, which is not a well-formedness error), etc.

I would like to propose that, all operators that allow operator chaining should be close under the operator. For example, Number + Number = Number, and String + String = String, so + could be chained. However, for many other operators this is not true, so it should be disallowed.

It is true that + could be customized by _plus, and the returned type might not be the same as the operand's type. However, since it's user-defined, it's their responsibility.

I think these are the only operators that should be okay to chain:

• +
• -
• *
• /
• and
• or

[peblair]

To a limited extent, I think there are instances where chaining comparison operators might assist readability. For example, if a == b == c was syntactic sugar for (a == b) and (b == c). Another example: 0 <= x < 10 expanding to (0 <= x) and (x < 10).

Perhaps a general grammatical rule for this would be the following: Given the following pseudo-grammar:

binop-expr: binop-assoc-expr | binop-comp-expr
binop-assoc-expr: expr (assoc-binop expr)*
(* To remove any ambiguity about where a single expr goes *)
binop-comp-expr: expr comp-binop expr (comp-binop expr)*

assoc-binop: PLUS | DASH | STAR | SLASH  | AND | OR | CARET
comp-binop: LEQ | GEQ | EQUALEQUAL | SPACESHIP | EQUALTILDE | NEQ  | LT  | GT

Expand binop-comp-expr as follows:

comp-binop(A, <comp1>, comp-binop(B, <comp2>, comp-binop(C,..., Y, <compN>, Z)...))
=>*
assoc-binop(assoc-binop(A,<comp1>,B),AND,assoc-binop(assoc-binop(B,<comp2>,C),
  AND,assoc-binop(...,AND,assoc-binop(Y,<compN>,Z)...)))

Or something similar.

I understand if there are reasons against doing that, but I just feel it's worth mentioning that such notation is often used in mathematics, so some beginners might be more comfortable with it.

[schanzer]

Speaking as a member of the math-ed community: please don't allow this. a==b==c and a<b<c are just as bad as 1+2+3.

I can see how this is useful shorthand, of course, so I'm not saying it's a bad idea. Just offering that if it is done, it should not be done because of mathematical precedent.

[peblair]

Another data point: the Racket 2htdp teaching languages seem to support multi-comparisons in this fashion.

Example: (< 1 2 3) ;; => #true

[/appeal-to-authority]

[sorawee]

If @belph 's BNF is to be integrated to Pyret, please don't name it "assoc" because it's not!

[peblair]

My mistake :) It was just meant to illustrate the concept. Perhaps sugarable-binop would be more appropriate.

[blerner]

This sounds less like a well-formedness error, and more like an error naturally caught by the type checker, no?