On September 13th [EMAIL PROTECTED] committed:
> Modified: doc/trunk/design/syn/S03.pod
> ==============================================================================
>
> +Perl 6 also supports C<Str> decrement with similar semantics, simply by
> +running the cycles the other direction. However, leftmost characters
> +are never removed, and the decrement fails when you reach a string like
> +"aaa" or "000".
> +
> +Increment and decrement on non-<Str> types are defined in terms of the
> +C<.succ> and C<.pred> methods on the type of object in the C<Scalar>
> +container.
Apologies for the delay in responding to this; however the above is
still in S03.
The algorithm for increment and decrement on strings sounds really good,
however I'm concerned that dealing with all that has made the common
case of integer decrement a little less intuitive where the integer
happens to be stored in a string, for example in this case:
perl -wle '$a = 10; $b = shift; $a--; $b--; print "$a $b"' 10
Perl 5 prints "9 9", but Perl 6 will print "9 09".
If a 'number' is read in from a file, standard input, a webpage, a
command-line argument, and possibly even a database then it's likely to
be a string to start with.
I realize there are ways to get round this, for example by declaring the
variable as numeric. But not having to worry about declaring variable
types is quite Perlish.
And the above subtlety is something I wouldn't like to have to explain
to a beginner ("The program works fine when I hardcode 10 into it, but
not when I provide 10 as input!"); treating 10 and "10" differently with
the same operator seems a little PHPish.
About C<+> S03 says:
> +Microeditorial: As with most of these operators, any coercion or type
> +mismatch is actually handled by multiple dispatch. The intent is that
> +all such variants preserve the notion of numeric addition to produce a
> +numeric result, presumably stored in suitably "large" numeric type to
> +hold the result. Do not overload the C<+> operator for other purposes,
> +such as concatenation. (And please do not overload the bitshift
> +operators to do I/O.) In general we feel it is much better for you
> +to make up a different operator than overload an existing operator for
> +"off topic" uses.
I'm wondering if something similar should apply to C<-->; that string
and numeric decrement are different, so should have different operators.
Smylers
