Math-like operator syntax

[Michiel]

I've always tried to follow mathematical notation in designing the
syntax of Mist. That is, as much as possible with the characters that
are both in the ASCII table and on a standard keyboard. For concepts
that don't exist in traditional mathematics, or when the ASCII table
fails me, the syntax should at least 'make some sense' (for arbitrary
values of 'some').

This has had several effects on the syntax as it stands now:

* Equality is =, assignment is <-.

* As in other programming languages, inequality operators include <,
>, <=, >= and <>, which are close enough. And composed operators
follow the intuitive rule: ( A [op1][op2] B ) = ( A [op1] B or A [op2]
B ). In Mist, this concept is extended to include the operator <>=,
which denotes comparability.

* The mod function uses the keyword "mod".

* The implication operator is b1 => b2, as in: b1 implies b2.

* A range/interval is denoted a..b, the elements between a (lower
bound) and b (inclusive upper bound).

* Tuples are written like this: (1, 2, 3). (1) is identified with the
value 1.

* The and/or operators are the keywords "and" and "or", which are the
next best thing to the wedge and vee notation.

* A pointer is ^, not * as in many languages derived from C. Because
it's at least, you know, pointy. That's a strong pointer. A weak
pointer is `, which might be seen as half a ^. (If you really want to
see it.)

* The notation #A (the number sign) returns the number of elements in
(size of) A. This would work for arrays, sets, matrices, etc.

Well, I think you'll agree that those choices make sense, although if
you don't agree, I'm happy to discuss it. I'm now facing a couple of
syntax decisions I'm not sure about:

------------------------------
The operator <=> could be used for the "logical equality" or "if and
only if" operator. It would be a function taking two booleans and
returning a boolean. Let me start with the cons:

Cons:

* There is already the = operator, which does something very similar.
It is _almost_ two artificial ways to do the same thing.

* Any description of the Mist programming language would have to list
every operator, and this one may confuse/deter people. It is not a
very well-known operator, at least to programmers.

Pros:

* It would look more natural for logical formula's. At least to
logicians.

* It has lower precedence than the comparison operators, so you don't
need parentheses in an expression like: a < x <=> b < y.

* It would implicitly cast its operands to bool, so 1 <=> 2 is true.
This may have use-cases. It may also be a 'con', but at least it's a
difference between = and <=>.
------------------------------

------------------------------
About the tuples. Tuple flattening is something you may not always
want for your tuples. For more information about the phenomenon, read:
http://code.google.com/p/mist/wiki/Tuples

Anyway, the proposed syntax for 'non-flattening tuples' is [1, 2, 3].
I believe it would work. Do you?
------------------------------

There are probably more, but I can't think of them right now.

[Michiel Helvensteijn]

> The operator <=> could be used for the "logical equality" or "if and
> only if" operator. It would be a function taking two booleans and
> returning a boolean. Let me start with the cons:
>
> Cons:

* If there is the implication operator => and the iff operator <=>,
people may expect <= to be related, but that's actually the smaller/
equal operator.

> Pros:

* There's no way to split up the operator to make it mean something
else grammatically. So if you make that mistake, you'll get an error,
not unexpected behavior.

> There are probably more, but I can't think of them right now.

------------------------------
Another one is the <-> operator. It's the swap operator. a <-> b
interchanges the values of a and b.

This shares practically the same pros and cons with the <=> operator.

Cons:

* You can already do this in several ways. (a, b) <- (b, a), swap(a,
b) are two examples.

* Again, it's not a very well-known operator.

* Again, since <- and <-> are related, people may expect -> to exist
as well. But that may not be a good idea. There should be one way to
do a standard assignment. Not one for right-to-left and one for left-
to-right.

Pros:

* It looks natural. Donald Knuth uses it in Art Of Computer
Programming, so it's not totally out of the blue.

* There is no way to break up the operator to make it mean something
different.
------------------------------