Definition of Order in S29
In the definition of cmp, S29 says the function "returns |Order::Increase|, |Order::Decrease|, or |Order::Same| (which numify to -1, 0, +1)". Shouldn't the enumerations and their numerical values be listed in the same order? Joe Gottman
Re: Definition of Order in S29
Joe Gottman wrote: In the definition of cmp, S29 says the function "returns |Order::Increase|, |Order::Decrease|, or |Order::Same| (which numify to -1, 0, +1)". Shouldn't the enumerations and their numerical values be listed in the same order? Joe Gottman The enumerations and the numerical values are both in correct order. Since "abc" is less than "xyz", "abc" cmp "xyz" is being invoked with its arguments in increasing order, So it returns Order::Increase. That numifies to -1 because that's how "less-than" is usually encoded. =thom -- I wanna hang a map of the world in my house. Then I'm gonna put pins into all the locations that I've traveled to. But first, I'm gonna have to travel to the top two corners of the map so it won't fall down. -- Mitch Hedberg
Re: Definition of Order in S29
At 11:37 AM -0700 1/24/08, Thom Boyer wrote: Joe Gottman wrote: In the definition of cmp, S29 says the function "returns |Order::Increase|, |Order::Decrease|, or |Order::Same| (which numify to -1, 0, +1)". Shouldn't the enumerations and their numerical values be listed in the same order? The enumerations and the numerical values are both in correct order. Since "abc" is less than "xyz", "abc" cmp "xyz" is being invoked with its arguments in increasing order, So it returns Order::Increase. That numifies to -1 because that's how "less-than" is usually encoded. Thom, I don't think you understood Joe's more obvious question. AFAIK, the Order values are supposed to numify like this: Order::Increase -> -1 Order::Same -> 0 Order::Decrease -> +1 The above quoted text shows the numify in the order [-1,0,1], but the Order values are not in the corresponding sequence. To fix the problem, the S29 text should probably say: returns |Order::Increase|, |Order::Same|, or |Order::Decrease| (which numify to -1, 0, +1) That way, reading the S29 text makes more sense. This is, I believe, what Joe was pointing out needed to be fixed. -- Darren Duncan
Re: Definition of Order in S29
On 2008-01-24 Thom Boyer <[EMAIL PROTECTED]> wrote: > Joe Gottman wrote: > > In the definition of cmp, S29 says the function "returns > > |Order::Increase|, |Order::Decrease|, or |Order::Same| (which > > numify to -1, 0, +1)". Shouldn't the enumerations and their > > numerical values be listed in the same order? > > > > Joe Gottman > The enumerations and the numerical values are both in correct order. > Since "abc" is less than "xyz", "abc" cmp "xyz" is being invoked > with its arguments in increasing order, So it returns > Order::Increase. That numifies to -1 because that's how "less-than" > is usually encoded. Correct about Increase. But would ::Decrease numify to 0, and ::Same to +1? :) -- Dakkar - GPG public key fingerprint = A071 E618 DD2C 5901 9574 6FE2 40EA 9883 7519 3F88 key id = 0x75193F88 That's one small step for a man; one giant leap for mankind. -- Neil Armstrong signature.asc Description: PGP signature
Re: Definition of Order in S29
Thom Boyer wrote:
> The enumerations and the numerical values are both in correct order.
> Since "abc" is less than "xyz", "abc" cmp "xyz" is being invoked with
> its arguments in increasing order, So it returns Order::Increase. That
> numifies to -1 because that's how "less-than" is usually encoded.
Others have pointed out Joe's actual intent in asking the question; so
I won't belabor the point.
Instead, I'll say that the idea that Order::Increase numifies to -1 is
going to take some getting used to. While I understand the reasoning
behind it, my intuition would have been to numify it to +1 for an
increase and -1 for a decrease.
If C<"abc" cmp "xyz"> must numify to -1, could we please choose
something like 'Order::Before' and 'Order::After' instead of
'Order::Increase' and 'Order::Decrease'? Not only does this make more
intuitive sense, but it also pairs the Order values more closely with
the type-neutral comparison operators ('before' and 'after').
(Which brings up another point, which I'll freely admit I'm too lazy
to look up at the moment: do we already have a type-neutral operator
that corresponds to 'Order::Same'? I suspect that '===' is it; but my
grasp of the plethora of equivalence operators is somewhat shaky. If
not - and possibly even if so, depending on which paradigm is the most
important one to reinforce - I might recommend using 'same' to
complete the 'before'/'after' set of operators.)
--
Jonathan "Dataweaver" Lang
Re: Definition of Order in S29
At 7:20 PM -0800 1/24/08, Jonathan Lang wrote:
Instead, I'll say that the idea that Order::Increase numifies to -1 is
going to take some getting used to. While I understand the reasoning
behind it, my intuition would have been to numify it to +1 for an
increase and -1 for a decrease.
I don't see this as being a problem since I expect very few users
deal directly with the numbers anyway, and they're just a background
implementation and/or legacy detail.
The main place I would understand the actual numbers having any
semantic effect is if you want to chain comparators such as "$^a.foo
<=> $^b.foo or $^a.bar <=> $^b.bar" (I may have spelled wrong), sort
first by .foo then by .bar; that's counting on the result boolifying
to false when the 2 comparands are equal, and boolifying to true when
not; this isn't different in your suggestion vs otherwise.
So I recommend not changing this.
If C<"abc" cmp "xyz"> must numify to -1, could we please choose
something like 'Order::Before' and 'Order::After' instead of
'Order::Increase' and 'Order::Decrease'? Not only does this make more
intuitive sense, but it also pairs the Order values more closely with
the type-neutral comparison operators ('before' and 'after').
By contrast, at least looking at Order on its own, I think
Increase|Decrease works better than Before|After. Part of the reason
is that the first 2 work well for both prefix and infix notations,
while the second 2 just work for infix. Take for example "there is
an increase from foo to bar" or "foo increases to become bar", versus
"foo is before bar". At least this aspect is a preference of mine,
as I prefer standardizing on prefix notation for all routine/operator
calls where possible. Still, I suppose I may not complain too loudly
if the change you suggest was made.
I'd be more interested in hearing what precedents if any exist in
this regard. What do other languages call the same concepts?
-- Darren Duncan
Re: Definition of Order in S29
On Jan 24, 2008, at 23:23 , Darren Duncan wrote: I'd be more interested in hearing what precedents if any exist in this regard. What do other languages call the same concepts? data Ord = LT | EQ | GT -- Haskell -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
