HaloO,
John M. Dlugosz wrote:
Huh?
if you call
$q = aaa;
incr($q);
then the value passed in is a Str. The static type is Any, the dynamic
type is Str.
Sorry, I got that messed up. The ::Type captures the dynamic type
of the value, of course. But I want to get at the constraint of
the
HaloO,
John M. Dlugosz wrote:
Do we still get to keep the current semantics if we specificially
declare a string? e.g.
I'd vote for that.
I'd vote for it as well with the following rational. Note that
a simple scalar parameter involves three types:
1) the constraint of the parameter
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
sub incr (Any $x is rw)
{
if $x.VAR.WHAT ~~ Str {...} # -100 - -101
else {...} # -100 - -99
}
This doesn't work because $x.VAR accesses the inner container and
that has constraint Any which effectively is
Just out of idle curiousity, (and so I can explain it when training), I
would like to know the original motivation for string/number arithmetic.
My guess is automatic generation of predictable filenames. Am I anywhere
close?
--
Email and shopping with the feelgood factor!
55% of income to
On Thu, Apr 24, 2008 at 1:20 AM, Ph. Marek [EMAIL PROTECTED] wrote:
On Mittwoch, 23. April 2008, Larry Wall wrote:
On Wed, Apr 23, 2008 at 04:03:01PM +0100, Smylers wrote:
: The algorithm for increment and decrement on strings sounds really good,
: however I'm concerned that dealing with
Ph. Marek philipp.marek-at-bmlv.gv.at |Perl 6| wrote:
I think that's a can of work, and I'd be +1 on TSa:
If the programmer really wants to decrement 10 to 09 she has
to cast that to Str: (10 as Str)--. So we have 10.HOW === Str
but 10.WHAT === Num Str.
It's behaving as Num ∪ Str,
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
HaloO,
John M. Dlugosz wrote:
If the programmer really wants to decrement 10 to 09 she has to
cast that to Str: (10 as Str)--. So we have 10.HOW === Str
but 10.WHAT === Num Str.
It's behaving as Num ∪ Str, while the declaration Num Str in
juxtaposition means Num ∩ Str.
Hmm? I meant
On Thu, Apr 24, 2008 at 09:15:15PM +0200, TSa wrote:
I had hoped that WHAT denotes a more specific type than HOW. E.g.
subset ThreeChars of Str where {$_.elems == 3}
my ThreeChars $x = 'xxx';
$x.WHAT; # ThreeChars
$x.HOW; # Str
$x === 'xxx'; # false because type i.e.
HaloO,
Larry Wall wrote:
You are confusing the container with the object. .WHAT and .HOW are
both dynamically typed, and $x.WHAT returns Str, because objects do
not carry subtypes. The container enforces the ThreeChars constraint,
but does not require a ThreeChars object.
Thanks for helping
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
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
... Is it defined that non-numeric
strings map to NaN or to zero?
Zero.
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.
People have
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
Hmm? I meant Num ∩ Str. This intersection type is a subtype of
Str and Num without type coercion and it beats both in specificity
when it comes to dispatch.
There are methods in Str that are not in Num, and vice versa. A
variable declared as
Larry Wall larry-at-wall.org |Perl 6| wrote:
Neither, probably. You'd get an undef of type Num. Which might or
might not convert to NaN or 0 under various circumstances.
The orthodox documentation has Failure being undef that throws an
exception if you try and get a value from it.
On Thursday 24 April 2008 20:31, John M. Dlugosz wrote:
That makes me think of another way to confuse people who don't really
know the difference between numbers and strings:
$x = -100;
$x++;
say $x; # prints -101, not -99.
There's plenty of other ways to confuse people too;
On Thursday 24 April 2008 23:54, smuj wrote:
There's plenty of other ways to confuse people too; try $x with 999 or
1.23e9 :-)
One can even confuse oneself! Forget the dot in 1.23e9 :-)
Cheers,
smuj
--
smuj
([EMAIL PROTECTED])
On Thursday 24 April 2008 22:09, Larry Wall wrote:
That makes me think of another way to confuse people who don't really
know the difference between numbers and strings:
$x = -100;
$x++;
say $x; # prints -101, not -99.
Interesting point. At one time we had the increments
Larry Wall larry-at-wall.org |Perl 6| wrote:
The initializer needs to go =inside= the
signature. I think you meant to write
(my int8 ($x, $y)) «=« 127;
It should already parse that way. scope_declarator is a noun,
and nouns may be used on the left side of an infix operator. When
smuj smuj-at-iol.ie |Perl 6| wrote:
Do we still get to keep the current semantics if we specificially declare a
string? e.g.
my Str $x = -100;
$x++;
say $x; # prints -101
my $y = -100;
$y++;
say $y; # prints -99
Cheers,
smuj
I'd vote for that.
As well as a hand full of adjectives.
On September 13th [EMAIL PROTECTED] committed:
Modified: doc/trunk/design/syn/S03.pod
==
+Perl 6 also supports CStr decrement with similar semantics, simply by
+running the cycles the other direction. However,
HaloO,
Smylers wrote:
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
On Wed, Apr 23, 2008 at 04:03:01PM +0100, Smylers wrote:
: 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
On Mittwoch, 23. April 2008, Larry Wall wrote:
On Wed, Apr 23, 2008 at 04:03:01PM +0100, Smylers wrote:
: 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
23 matches
Mail list logo
