>>(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
> 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 ov
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. Con
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 { @_
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
>card
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
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?
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 n
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 syntact
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 e
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 ..
11 matches
Mail list logo
