Re: Table of Perl 6 Types
(perhaps this discussion belongs on p6l) It sure does;) (this reply moved to p6l) [EMAIL PROTECTED] wrote: Dave Whipp wrote: An Int is Enumerable: each value that is an Int has well defined succ and pred values. Conversely, a Real does not -- and so arguably should not support the ++ and -- operators. Amonst other differences, a Range[Real] is an infinite set, whereas a Range[Int] has a finite cardinality. ++ and -- aren't meant to increment or decrement to the next/last value in the set, they're increment or decrement by one (see perlop). I can see your point about them not making sense for Real since it's not an enumerable set like integers but I don't think it would be in the spirit of DWIM ... Imagine I have a concrete type FixedPoint8_1000 that stores numbers from 0 to 1000 in an 8-bit value, and does Real. Incrementing a value stored in this type by one isn't a meaningful operation. wrt the perlop reference, we manipulate strings with ++ and --; and we're going to have enumerated types (albeit backed by intergers). I'm sort-of hoping that we'll be able to use the operators on iterators, too. I think what I'm saying is that succ/pred semantics are more general than just +/- 1; and perl6 does not need to be bound by perl5's perlop. I can't find a formal defn of autoincrement in the perl6 docs. I wouldn't see a problem with defining a Real role that has a fairly sparse set of operations. Afterall, a type that does support ++ and -- (e.g. Int, Num) could easily does Enumerable if it wants to declare that it supports them. Dave.
Re: Table of Perl 6 Types
I wouldn't see a problem with defining a Real role that has a fairly sparse set of operations. Afterall, a type that does support ++ and -- (e.g. Int, Num) could easily does Enumerable if it wants to declare that it supports them. What about the scripty-doo side of Perl6? One of the overriding design considerations that Larry put forward at the very beginning was that the easy things are easy part of the philosophy would still remain. I want to still be able to do something like perl -pia -e '@F[2]++' somefile.xsv And it just DWIM for numbers like 1.2 ( - 2.2). If Real is what 1.2 is implicitly coerced into, what do I do now? Remeber a few truisms: * The most common usage of Perl after bad CGIs is systems administration. * The most powerful feature of Perl for sysadmins is the scalar Rob
Re: Table of Perl 6 Types
On 1/12/06, Dave Whipp [EMAIL PROTECTED] wrote: (perhaps this discussion belongs on p6l) It sure does;) (this reply moved to p6l) [EMAIL PROTECTED] wrote: Dave Whipp wrote: An Int is Enumerable: each value that is an Int has well defined succ and pred values. Conversely, a Real does not -- and so arguably should not support the ++ and -- operators. Amonst other differences, a Range[Real] is an infinite set, whereas a Range[Int] has a finite cardinality. ++ and -- aren't meant to increment or decrement to the next/last value in the set, they're increment or decrement by one (see perlop). I can see your point about them not making sense for Real since it's not an enumerable set like integers but I don't think it would be in the spirit of DWIM ... Imagine I have a concrete type FixedPoint8_1000 that stores numbers from 0 to 1000 in an 8-bit value, and does Real. Incrementing a value stored in this type by one isn't a meaningful operation. wrt the perlop reference, we manipulate strings with ++ and --; and we're going to have enumerated types (albeit backed by intergers). I'm sort-of hoping that we'll be able to use the operators on iterators, too. I think what I'm saying is that succ/pred semantics are more general than just +/- 1; and perl6 does not need to be bound by perl5's perlop. I can't find a formal defn of autoincrement in the perl6 docs. I wouldn't see a problem with defining a Real role that has a fairly sparse set of operations. Afterall, a type that does support ++ and -- (e.g. Int, Num) could easily does Enumerable if it wants to declare that it supports them. I just meant that my Real $x = 5; # Or Num or ... say ++$x; should print 6 by default as opposed to Error: no 'next' for real value. The next/prev semantics are, and should be more general than ±1, I just think that ±1 should remain the default for reals ints.
Re: Table of Perl 6 Types
On 1/12/06, Ævar Arnfjörð Bjarmason [EMAIL PROTECTED] wrote:
The next/prev semantics are, and should be more general than ±1, I
just think that ±1 should remain the default for reals ints.
So, Num (and all types that derive from Num) should have a next of {
@_[0] + 1 } and a prev of { @_[0] - 1 } (boundschecking against the
limits of the type, of course) ... ?
That sounds reasonable and dwimmish to me.
Rob
Re: Table of Perl 6 Types
Dave Whipp wrote:
An Int is Enumerable: each value that is an Int has well defined succ
and pred values. Conversely, a Real does not -- and so arguably should
not support the ++ and -- operators. Amonst other differences, a
Range[Real] is an infinite set, whereas a Range[Int] has a finite
cardinality.
I think that Dave has a point about a Range[Real] being an infinite
set: According to DWIM, if I see 4.5..5.7, I don't think of 4.5,
5.5; I think of numbers greater than or equal to 4.5 but less than
or equal to 5.7. Likewise, 4.5^..^5.3 contains numbers greater
than 4.5 but less than 5.3, not an empty list.
Mind you, I generally wouldn't be using such a range for iterative
purposes; rather, I'd be using it as a matching alternative to
comparison operators:
Cwhen 4.5..5.7 {...} === C if 4.5 = $_ = 5.7 {...; break}
Cwhen 4.5^..^5.3 {...} === C if 4.5 $_ 5.3 {...; break}
Cwhen 1.2... {...} === C if 1.2 = $_ {...; break}
Cwhen ...^7.6 {...} === C if $_ 7.6 {...; break}
Cwhen ...^4.5 | 5.7^... {...} === C if $_ 4.5 || 5.7 $_
{...; break} === Cwhen not 4.5..5.7 {...}
That said: if I _did_ use it for iterative purposes, I'd rather get
the current approach of turning it into a step-by-one incremental list
than have perl 6 complain about trying to iterate over an infinite
set. Well, unless I said something like loop ...4.3 {...}; in that
case, I'd expect Perl to complain about not knowing where to start.
--
Jonathan Dataweaver Lang
Re: Table of Perl 6 Types
On 1/12/06, Jonathan Lang [EMAIL PROTECTED] wrote: I think that Dave has a point about a Range[Real] being an infinite set: According to DWIM, if I see 4.5..5.7, I don't think of 4.5, 5.5; I think of numbers greater than or equal to 4.5 but less than or equal to 5.7. Likewise, 4.5^..^5.3 contains numbers greater than 4.5 but less than 5.3, not an empty list. That's good, because that's what it does. A range object in list context expands into a list, but in scalar context it is there for smart-matching purposes: 3.5 ~~ 3..4 # true 4 ~~ 3..^4 # false etc. The only remaining problem is that we have no syntax for ...3, which doesn't make sense as a list, but does make sense as a range. Luke
Re: Table of Perl 6 Types
Rob Kinyon wrote: I wouldn't see a problem with defining a Real role that has a fairly sparse set of operations. Afterall, a type that does support ++ and -- (e.g. Int, Num) could easily does Enumerable if it wants to declare that it supports them. What about the scripty-doo side of Perl6? One of the overriding design considerations that Larry put forward at the very beginning was that the easy things are easy part of the philosophy would still remain. I want to still be able to do something like perl -pia -e '@F[2]++' somefile.xsv And it just DWIM for numbers like 1.2 ( - 2.2). If Real is what 1.2 is implicitly coerced into, what do I do now? Scripty-code (without explicit types) uses Num, not Real.
Table of Perl 6 Types
Luke Palmer wrote:
That's good, because that's what it does. A range object in list
context expands into a list, but in scalar context it is there for
smart-matching purposes:
3.5 ~~ 3..4 # true
4 ~~ 3..^4 # false
etc.
The only remaining problem is that we have no syntax for ...3, which
doesn't make sense as a list, but does make sense as a range.
So just include a ... prefix operator that's useful for pattern
matching in scalar context, but fails if you try to use it in list
context.
More precisely, cause any range with an indeterminant lower bound to
fail if you try to use it in list context; so not only would loop
...5 {...} fail, but so would loop (not 3..4) {...} or loop (not
5...) {...}; but loop (not ...5) {...} would work, generating a
list of 6, 7, 8, 9, and so on.
BTW: where is the behavior in scalar context documented? I don't
remember seeing it. (I also seem to recall seeing something about $a
..^ $b being equivalent to $a .. ($b - 1); but I could be mistaken.
I hope that's not the case, as the only time that it would make sense
would be when the both bounds are whole numbers and the range is being
used in list context.)
--
Jonathan Dataweaver Lang
Re: Table of Perl 6 Types
On Thu, Jan 12, 2006 at 08:29:29PM +, Luke Palmer wrote: : The only remaining problem is that we have no syntax for ...3, which : doesn't make sense as a list, but does make sense as a range. Well, it could be a lazy list that you only ever pop, I suppose. In any event, it doesn't work syntactically because ... is where a term is expected, so it's a yada-yada-yada with an unexpected term following it. Larry
Re: Table of Perl 6 Types
Larry Wall wrote: On Thu, Jan 12, 2006 at 08:29:29PM +, Luke Palmer wrote: : The only remaining problem is that we have no syntax for ...3, which : doesn't make sense as a list, but does make sense as a range. Well, it could be a lazy list that you only ever pop, I suppose. In any event, it doesn't work syntactically because ... is where a term is expected, so it's a yada-yada-yada with an unexpected term following it. To bad; because that's exactly the syntax that I'd expect to use. -- Jonathan Dataweaver Lang
Re: Table of Perl 6 Types
Larry Wall skribis 2006-01-12 12:40 (-0800): Well, it could be a lazy list that you only ever pop, I suppose. In any event, it doesn't work syntactically because ... is where a term is expected, so it's a yada-yada-yada with an unexpected term following it. Why avoid having both ... and ...$foo? MMD, longest-match, ugly hacks, there's a bag full of tricks that could be used, so I gathered there must be a philosophical reason not to have this. I just can't think of any that would weigh more than having ...$foo around. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
