On Thu, Apr 24, 2008 at 08:10:12PM +0200, TSa wrote:
> 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?
Neither, probably. You'd get an undef of type Num. Which might or
might not convert to NaN or 0 under various circumstances.
>> 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!
People generally derive their expectations from their current
frustrations, I think...
>> 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.
Plus the fact that it's a string...
>> : 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?
If you really want that particular consistency, I'd rather guarantee it
by making increment of zz99 fail. Otherwise you have the (worse IMO)
inconsistency of making infix:<after> inconsistent with infix:<gt>.
> For the record
> if we were to introduce string increment and decrement operators I would
> name them mm and pp.
$xmm doesn't work too well...
> A similar problem exists with finite types
>
> my int8 ($x, $y) «=« 127;
You have your hyperop backwards there, btw. The little end points to
the smaller thing.
> $x++; # type error or 127 or -128?
> die unless $x > $y; # should never die
Never gets there. $x++ fails with a type constraint, because native
types are really storage types with subset semantics. The actual type
of $x is really something like:
Int where -128..127
> For decrement of unsigned types---which Str essentially is---we
> could define to stop at the zero element.
I think decrementing 0 should fail for unsigned numeric types.
> The case of Bool prescribes also capping at the top.
That's a special case to make it easy to use ++ and -- to force true or
false.
> So all the die conditions above should
> incorporate an Inf test to be correct.
Inf is just a special value that you can use in a signature, so multiple
dispatch already can handle that.
> 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
Fine, but *please* don't use lowercase for fancy types that the
hardware has no clue about. In any case, I suspect someone should
define the Surreal role first.
Larry
