Re: Table of Perl 6 "Types"

(this reply moved to p6l)

ava...@gmail.com 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.

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

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

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<when 4.5..5.7 {...}> === C<< if 4.5 <= $_ <= 5.7 {...; break} >>
C<when 4.5^..^5.3 {...}> === C<< if 4.5 < $_ < 5.3 {...; break} >>
C<when 1.2... {...}> === C<< if 1.2 <= $_ {...; break} >>
C<when ...^7.6 {...}> === C<< if $_ < 7.6 {...; break} >>
C<when ...^4.5 | 5.7^... {...}> === C<< if $_ < 4.5 || 5.7 < $_
{...; break} >> === C<when 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

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

Scripty-code (without explicit types) uses Num, not Real.

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

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

To bad; because that's exactly the syntax that I'd expect to use.

--
Jonathan "Dataweaver" Lang

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