Damian Conway wrote:
> Really? We don't have any trouble in Perl 5 with an = character
> being used in various unrelated operators:
>
> == comparison
> = assignment
> ~= match
s/~=/=~/
> => comma
> <= less than or equal to
But these are all roughly related to the concept of "equality", be it
testing equality, enforcing equality by assignment, equality in terms of
matching a pattern, setting a parameter to equal a value, testing is
something is equal or less than equal to something else.
The use of '=' seems entirely consistent in these operators.
> -- decrement
> - difference
> -= subtraction
> -> dereference
> -X file op
The first 3 all relate to the familiar concept of 'minus', or more
precisely a delta between two values. The last uses '-' as 'dash',
another familiar concept which doesn't grate against the first usage,
IMHO. The arrow is a special case. I don't read that first character
as '-', I think of the operator as one. I guess the visual cue forces
me to see it like that.
These operators may not be internally self-consistent, but I don't think
it's a problem having different meaning for '-', given that both meanings
are well understood to anyone who knows basic math and has used a command
line program with a -x argument.
> I'm just suggesting the same for the ~ character:
>
> ~~ smart-match
> ~ concatenate
> ~| stringy bitwise OR
> ~> append args
> <~ invocate
This is where I get lost. I see 4 different concepts being overloaded
onto '~'.
In the first it indicates 'match' just as it always has for =~ and !~.
In the second, it is being used for concatentation - nothing to do with
matching. In the third it is being used to cast stringwisely - nothing
to do with matching or concatenation. In the fourth and fifth it is being
used to re-order arguments - nothing to do with matching, concatenation
(well, possibly concatenation of argument lists) or stringwise casting.
Now that I look at it again, the '~~' operator bothers me in particular.
The first '~' seems to indicate 'stringwise' in keeping with '~|'
and the second implies 'match' in keeping with '=~'.
I find it questionable to use the same character twice in one operator
and have different semantics implied for each. '~' should either be
'match' or 'stringwise' but not both.
I would like to see '~' kept for matching and just matching. It is well
known in this role and is analogous to the "roughly equals" operator
in the Real World (extended ASCII character 247 - just don't ask me to type
it).
I also think '_' should be used for concatenation because it's in keeping
with the existing use of 123_456.
As a prefix character to indicate stringwise (numberwise, bitwise, etc)
casting, can we not use a single character prefix, e.g. 's' for string,
'n' for number, 'b' for bitwise, 'v' for 'vector', and so on?
$a s| $b; # stringwise
$a b| $b; # bitwise
$a n| $b; # numberwise
@a v| @b; # vector
@a vsn| @b; # vector stringwise bitwise
I see these as being similar to regex flags. In a regex we don't
have two separate metacharacters for matching \w case sensitively or
insensitively. Instead we use the 'i' flag outside the regex or
within the regex, scoping the parts of the pattern to which it applies:
m/foo/i
m/(?i:foo)/
m:i/foo/
I think we should adopt the same strategy for regular operators. Rather
than create umpteen new operators to perform every operation in every
different style, we should keep the operation orthogonal to the context
in which the operator is applied. So instead of having a vector addition
operator, we have an addition operator and a vector flag which can be
applied to it.
> I mean, compare:
> @a ~> grep {...} ~> map {...} ~> sort ~> @a;
> with:
> @a |> grep {...} |> map {...} |> sort |> @a;
>
> I don't know about *your* font, but in mine the ~> and <~ versions are
> at least twice as readable as the |> and <| ones.
In my font, or perhaps more importantly, to my eye, the |> and |< are
more readable. But regardless, I think it's more important to make the
operators consistent with each other, than to make them look pretty or
easy to read. The latter is important, of course, but I personally believe
that it's no use making something easy to read if the meaning is still hard
to comprehend. Better to make something harder to read but easier to
understand.
A
