HaloO,

Larry Wall wrote:
On the other hand, "09" has the advantage of still having the numeric
value 9.

Well, I think the canonical representation of of 9 is "9". The mapping
of numeric strings to numbers is N to 1. Is it defined that non-numeric
strings map to NaN or to zero?


 But the converse is not true if the user was expecting a
string decrement, since decrementing "10" in Perl 5 to get 9 is also
counterintuitive if you were expecting "09".  So Perl 5 just punts,
which is the third option.  In any case, there's always something
to explain to a beginner.

The core mystery is where people derive their expectations from!


 But I think in Perl 6 we're leaning more
toward preserving information than Perl 5 did.

This information being the length of the string I presume.


: I'm wondering if something similar should apply to C<-->; that string
: and numeric decrement are different, so should have different operators.

Well, you have to strike a balance somewhere.  On the one hand,
as you have pointed out, the exact semantics of "predecessor" are
slightly ambiguous in some cases,

There is another problem with the definition of string increment and
decrement. These operations should be compatible with the corresponding
order ops:

   $y = $x = 3;
   $x++;
   die unless $x > $y; # should never die

   $y = $x = 'zz99';
   $x++;
   die unless $x gt $y; # dies because 'zz99'.succ eq 'aaa00'

   $y = $x = A.new;
   $x++;
   die unless $x after $y; # generic case shouldn't die

BTW, would 'aaa00' after 'zz99' being true be useful? For the record
if we were to introduce string increment and decrement operators I would
name them mm and pp.

A similar problem exists with finite types

   my int8 ($x, $y) «=« 127;
   $x++; # type error or 127 or -128?
   die unless $x > $y; # should never die

For decrement of unsigned types---which Str essentially is---we
could define to stop at the zero element. The case of Bool prescribes
also capping at the top. So all the die conditions above should
incorporate an Inf test to be correct. E.g. A nice idea is to have a
type inf8 that has range -127..126 and -128 and 127 as encodeable
infinities such that

  sub foo ($x)
  {
     if $x.abs.does(Inf)
     {
        say "transfinite";
     }
     else
     {
        say $x;
     }
  }
  foo(inf8 127); # prints "transfinite"
  foo(127);      # prints 127
  foo(int8 127); # prints 127


and type unions only sweep
the problem under the rug of multiple dispatch, and you still have
to teach the newbies.

I agree with that.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity"
  -- C.A.R. Hoare

Reply via email to