Jon Lang wrote:
I wouldn't mind 'x' becoming '~x' and 'xx' becoming 'x'; it strikes me
as a lot more intuitive - and I've wanted to see this done for a while
now. I suppose that you might also introduce a '?x' and/or a '+x' to
complete the set, though for the life of me I can't think of how
they'd work or what they'd be good for.
I don't think that every ~foo needs a corresponding +foo or ?foo. Sometimes
doing that makes sense, and other times not. So your idea may work on its own.
And actually if 'x' became '~x' and 'xx' became 'x', I think that would
increase the amount of symmetry with other sets of Perl 6 operators, where plain
'foo' is the most generic version and adding ~ or + or ? etc is making
specialized versions or post processing. So then, 'x' simply means make a list
of repeated items, and the ~ prefix means post-process with catenation.
So does anyone else have thoughts on that?
* ===, but xnor, ↔ aliases could be added
By the way, another alias for the above is 'iff' (if and only if)
<also andthen orelse> carry subtly varied semantics involving
short-circuiting behavior: andthen and orelse are like && and ||
except that they work off of success/failure instead of true/false;
"also" is an ordered, short-circuiting version of "&" (and thus
"all"). For some time now, I've wanted an analog for '|' and 'any' -
but the only name I can think of for it would be 'else', which has
some obvious clarity issues.
Thanks for the reminder. So then, none of those are analogous to distinct
boolean operators.
But here are a few more dyadic:
* nand aka ⊼ aka ↑
* nor aka ⊽ aka ↓
* implies aka imp aka →
* nimp aka ↛
* if aka ←
* nif aka ↚
Side note: one thing that I recently learned concerning implication
operators is that the direction of the implication doesn't necessarily
follow the direction of the arrow. In particular, "A if B" is "A←B",
and "A only if B" is "A→B": in both of the original statements, the
implication flows right to left.
I thought that the direction did matter, and that's why there are distinct
versions in each direction. It's like how < and > are the same thing but with
the direction reversed, or subset/superset or contains/contained-by.
If you read "A → B" as "A implies B" then that's the same as "if A then B", then
the cause-effect reads left to right, which does follow the direction of the
arrow, like Perl's "if cond() then action()".
If you read "A ← B" as "A if B", that the cause-effect reads right to left, like
Perl's "action() if cond()".
So practically speaking then, these operators would be served by Perl's basic
conditionals if each conditional block resulted in the thing specified when the
condition is true, and some appropriate other value otherwise, so they can be
used in an expression. But since its probably saner to keep the existing 'if'
etc as statements, then just make new ones as expressions; while using the same
keyword, they wouldn't conflict due to different usage syntax.
Most of these suggestions could be implemented in a "Unicode
Operators" module; I see little need to put them into the default
setting. I'm leery of introducing new unicade operators that don't
have ASCII aliases, as you might be inclined to do with set operators.
All of the logic operators I proposed *do* have ASCII aliases, which is the
alphanumeric terms: same as we have [not, and, or, xor], we have [iff/xnor,
nand, nor, implies/imp, nimp, if, nif], so I don't see a problem here.
Separately, while I support that one should be able to use all the Perl 6
features without touching trans-ASCII characters if they don't want to, we
shouldn't be afraid to exploit them in the default setting; any exploitations
would just be aliases for the operator names. See ext/Set.pm again for an
example of how this could work.
Besides-which, on modern computers, you usually can read all the Unicode
characters, whose use would probably make code more readable (and prettier), and
if you have a decent toolset, it is easy to type those characters too. I mean,
what modern system doesn't support "input methods" by default? People in most
parts of the world must be able to write their non-Latin characters efficiently
on Latin keyboards somehow right? So just use the same method to write your
math/etc symbols. I'm doing so right now and its hardly any slower than typing
ASCII characters. (Note, unlike say Chinese where there could be tens or
hundreds of thousands of characters, I would anticipate that a Perl 6 standard
setting that exploits Unicode would only involve a few dozen math/etc symbols,
not too many to deal with I think.)
-- Darren Duncan
