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
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"
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
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"
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.
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"
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:
C === C<< if 4.5 <= $_ <= 5.7 {...; break} >>
C === C<< if 4.5 < $_ < 5.3 {...; break} >>
C === C<< if 1.2 <= $_ {...; break} >>
C === C<< if $_ < 7.6 {...; break} >>
C === C<< if $_ < 4.5 || 5.7 < $_
{...; break} >> === C
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, Æ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"
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"
> 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"
>>(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.
