(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
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
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] -
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
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
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 no syntax
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
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,
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
