Smylers wrote:
Bzzzt, wrong language!
But Perl isn't an orthogonal language, it's a "diagonal" language.
http://www.oreilly.com/catalog/pperl2/excerpt/ch01.html
In the section quoted, it was indicated that "orthogonal" and
"diagonal" are being used to mean "minimalist" and "loaded with
special-purpose tools" (by analogy to "move left, then up" vs. "go
straight to your target"). However, the sense that I'd use
"orthogonal" in this case is "similarly-named operators perform
similar tasks, and differently-named operators perform different
tasks" - i.e., change part of the name in a certain way, and the
functionality changes in a predicatable manner.
IOW, it's all about organizing your toolkit so that you can easily
find the right tool - whereas the meaning referred to above is more
akin to using a swiss army knife instead of a toolkit.
For what it's worth, I don't like the proposal because I was already
having trouble getting my head round the number of different operators
for asking "is this thing at least vaguely like this other thing".
I agree that the distinctions between the five different equality
tests (=:=, ===, eqv, ==, eq) are rather difficult to grasp (I'm still
having trouble getting the difference between '===' and 'eqv', and
would appreciate some help). Part of the problem, however, is that
the names chosen aren't always clear on what the differences are.
Sure, there's the analogy between the '=:=' comparison and the :=
"assignment" (i.e., binding) - so it's obvious to me that '=:=' is an
identity test ("are these two variables bound to the same thing?"),
just like ':=' means "bind this variable to that thing". But beyond
that, confusion reigns. The similarity between 'eqv' and 'eq' implies
a similarity to their operations that isn't there; likewise with '=='
and '==='. IOW, 'eqv' is not to '===' as 'eq' is to '=='; nor is
'eqv' to 'eq' as '===' is to '=='. And '==' means more than just "do
these two variables have the same value?" as one would suppose by
analogy to '=' ("assign a value to the variable") - it means "do these
two variables have the same _numeric_ value?".
By changing things around so that what's currently called 'eqv' is
instead called '==', and the current '==' and 'eq' get replaced by
'+==' and '~==' (which would be "diagonal") or are removed altogether
(which would be "orthogonal"), the analogies between the various
equality tests become more intuitive: '==' and '===' are different
variations of 'test for equality of value' (again, I'm not quite clear
on how they differ), while '+==' and '~==' (if included) are like
'==', except that they qualify their arguments as numbers or strings
before testing (in analogy to the unary + and ~ prefix operators).
--
The strongest argument that I can see _against_ redefining '==' to
mean 'generic equivalence' is that it has a long history of meaning
"numeric equality" in perl pre-6 - which is why I included an
alternate proposal that leaves all existing operator names unchanged.
Please can proposals for new operators (not just operators, for that
matter) be supported by examples along with the form:
Look at this awkward code (which could plausibly occur in the wild),
and look how less awkward the code is when rewritten using my proposed
operator.
Not quite following the letter of your request, but hopefully
capturing its spirit:
I don't like the fact that three very different operator names (cmp,
<=>, leg) all mean subtly different variations of the same thing (what
do legs have to do with comparisons?). I'd rather have it such that
similar operations (e.g., "determine the order between these two
terms") have similar operators - thus, (<=>, +<=>, ~<=>) instead of
(cmp, <=>, leg). I'm hoping to either regularize the set of
comparison operators by banishing letter-soup versions as described
above, or to streamline it by ditching the implicit-coercion forms
entirely: under this minimalist version of the proposal, if you want
to ensure a numeric comparison between $a and $b, you'd say '+$a <=>
+$b'; and a string comparison would be '~$a <=> ~$b'. Under the
"organized toolkit" version, they'd be "$a +<=> $b" and "$a ~<=> $b",
respectively.
--
I have a problem with extending the numeric-vs-string comparisons idea
to include boolean comparisons, and then using those as logical
operators: my problem is that the resulting operators start looking
less like operators ('→') and more like line noise ('?>='), and they
aren't very intuitive (logical implication generally is not thought of
as an ordinal comparison of truth values, and I'd expect an awful lot
of people to type something like '?->' or '?=>' and expect it to mean
implication). In addition, precedence and associativity don't
neccessarily match up correctly: these kinds of "logical operators"
would have a higher precedence than &&, and would be list-associative.
If you're going to add more logical operators (which I don't have much
of a problem with, other than failing to see enough utility in them
for the effort), I'd rather they be created as much as possible by
analogy to existing logical operators - e.g., co-opt '->' and '<-' for
implication and come up with something else for bit-shifting.
--
Jonathan "Dataweaver" Lang
