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 c
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
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 effec
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
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.
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
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 t
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 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
On Thu, Apr 24, 2008 at 03:31:52PM -0500, John M. Dlugosz wrote:
> BTW, it will require a new rule in the specification to allow «=« as a
> form of pseudo-assignment to declarations. But it has problems with the
> list on the RHS anyway.
I don't see why, since there's no list there...and anyway
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. Nothing
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 Num
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 been
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 define
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 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 typ
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
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 conv
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
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 deal
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
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
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 havi
On September 13th [EMAIL PROTECTED] committed:
> Modified: doc/trunk/design/syn/S03.pod
> ==
>
> +Perl 6 also supports C decrement with similar semantics, simply by
> +running the cycles the other direction. However, lef
24 matches
Mail list logo