Three-way relationships

[jack]

So, in some programming languages I can say:

x=y=0

To mean "Set y equal to nought and x equal to that[1]". In others, you'd get "Set x equal to one if y is already zero, else zero."

But in what language can I say:

if (x===y==0)

to mean "if x and y are both zero"?

The obvious problem is common operator associativity doesn't work. If the operators are nested binary operators, "y==0" would have to return two values, both the result, and "0".

You could have a system whereby you *did* return a number of things, eg. the result in list[0] and the various operators or other hints in list[1..n], and then let logic decide how to use the hints. That might also be useful where a function really really wants to return two values.

But is there a consistent way of doing this without turning it into an unreadable mess? :)

[1] Non-pedant corner: non-pedants might say "set x and y equal to nought"

Comments

[deborah_c]

There are, IIRC, languages which allow cases like "x < y <= z" to be parsed as one might expect, although at the moment I'm at a loss to remember which. That's a special case, though, and can be handled by special-case parsing, rather than as normal expression evaluation.

I shall now be annoyed with myself until I remember where I've seen this...

[celestialweasel.livejournal.com]

BCPL allows this, IIRC.

[deborah_c]

Thank you. Eighteen years has evidently clouded my memory :-)

[simont]

Eighteen years have evidently clouded your memory! :-)

[cartesiandaemon.livejournal.com]

That's odd. Maybe time is being a mass noun?

[ewx.livejournal.com]

I'd say "eighteen years" can describe an interval, as well as eighteen objects which happen to be intervals themselves.

[deborah_c]

Thank you. Or, more prosaicly, I could have deleted "The passage of" from the start because it sounded too pompous :-)

[stephenpthomas.livejournal.com]

As does Inform.

[simont]

You could have comparison operators notionally return a magic tuple type. (x==y) returns a tuple consisting of a boolean (the result of that comparison) and also the value of y. Then you define that the comparison operator, when given a tuple as one argument, has the effect of doing the comparison against the second element of the tuple, and then logical-ANDing the boolean result with the first element. Oh, and still returning a tuple consisting of the result of that AND and the second argument. Also, you define that any attempt to pass a tuple to something that isn't a comparison operator has the effect of implicitly discarding the second element of the tuple and turning the whole thing back into a boolean.

This tuple type then exists only in the mind of the source language analyser, so by the time you get to code generation it doesn't cause any additional trouble. And the effect is that you can chain arbitrarily many comparison operators – x < y == z <= w > k – and the effect will be the same as if you'd written all the comparisons separately and logical-ANDed the results. Except, of course, that any side effects in the expressions y, z and w would only be evaluated once.

You might have to make a decision about parentheses. It's not clear to me that (x == y) == z is justifiable on the same grounds of common mathematical idiom that justify x == y == z. Possibly, therefore, applying parentheses to a magic tuple should also have the effect of discarding its second element. Or possibly one should be even stricter, and merely set a flag in the tuple that disallows the application of a comparison operator to it at all (on the basis that you probably coded that by accident, and would prefer to be told of your mistake than to have the wrong code silently generated).

On a related note, a friend of mine some years ago seriously considered writing a language in which a valid syntax for the FOR statement was "FOR 0 <= i < n".

FOR 0 <= i < n

[cartesiandaemon.livejournal.com]

See deborah's comment -- I thought some languages *did* do those things. Though I can't remember where, and it must have been a special case.

[cartesiandaemon.livejournal.com]

Hmmm. And you could hopefully also bend this to allow "if (x && y > 0)" to mean "if both are greater than nought."

(I haven't worked out where I use zero and where I use nought yet)

[simont]

non-pedants might say "set x and y equal to nought"

Then they'd be in for a rude shock the first time they tried to instruct a C compiler to assign charptr = intptr = NULL;.

[cartesiandaemon.livejournal.com]

Exactly. Being a non-pedants is dumb :)