# 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
```