Jon Lang writes:
> Approaching this with the notion firmly in mind that infix:<..> is
> supposed to be used for matching ranges while infix:<...> should be
> used to generate series:
>
> With series, we want C< $LHS ... $RHS > to generate a list of items
> starting with $LHS and ending with $RHS.
Darren Duncan wrote:
specific, the generic "eqv" operator, or "before" etc would have to be
Correction, I meant to say "cmp", not "eqv", here. -- Darren Duncan
Aaron Sherman wrote:
2) The spec doesn't put this information anywhere near the definition of the
range operator. Perhaps we can make a note? This was a source of confusion
for me.
My impression is that a "Range" primarily defines an "interval" in terms of 2
endpoint values such that it define
OK, there's a lot here and my head is swimming, so let me re-consolidate and
re-state (BTW: thanks Jon, you've really helped me understand, here).
1) The spec is somewhat vague, but the proposal that I made for single
characters is not an unreasonable interpretation of what's there. Thus, we
could
On Wed, Jul 21, 2010 at 12:04 AM, Jon Lang wrote:
> Mark J. Reed wrote:
>> Perhaps the syllabic kana could be the "integer" analogs, and what you
>> get when you iterate over the range using ..., while the modifier kana
>> would not be generated by the series ア ... ヴ but would be considered
>> in
What we call the beginning is often the end
And to make an end is to make a beginning.
The end is where we start from.
—T. S. Eliot, Four Quartets
On behalf of the Parrot team, I'm happy to announce Parrot 2.6.0
"Red-rumped." Parrot (http://parrot.org/) is a virtual machine aimed
at running al
Mark J. Reed wrote:
> Perhaps the syllabic kana could be the "integer" analogs, and what you
> get when you iterate over the range using ..., while the modifier kana
> would not be generated by the series ア ... ヴ but would be considered
> in the range ア .. ヴ? I wouldn't object to such script-spe
On Tue, Jul 20, 2010 at 11:28 PM, Aaron Sherman wrote:
> So, what's the intention of the range operator, then?
... is a generator that lazily enumerates a series. .. is a
constructor for a Range object. They're two different things, with
different behaviors. In particular, consider that pi ~~
Aaron Sherman wrote:
> So, what's the intention of the range operator, then? Is it just there to
> offer backward compatibility with Perl 5? Is it a vestige that should be
> removed so that we can Huffman ... down to ..?
>
> I'm not trying to be difficult, here, I just never knew that ... could
> o
Approaching this with the notion firmly in mind that infix:<..> is
supposed to be used for matching ranges while infix:<...> should be
used to generate series:
Aaron Sherman wrote:
> Walk with me a bit, and let's explore the concept of intuitive character
> ranges? This was my suggestion, which se
Side note: you could get around some of the problems, below, but in order to
do so, you would have to exhaustively express all of Unicode using the Str
builtin module's RANGES constant. In fact, as it is now, it defines ASCII
lowercase, but doesn't define Latin lowercase. Presumably because doing s
Well, then, let's start building that consensus. I firmly believe
DateTimes should definitely be value types, immutable. Otherwise you
can't use them for hash keys, for one thing.
Note that timestamps in Perl have always been values; it's just that
they used to be specifically integers, whose va
On Tue, Jul 20, 2010 at 10:00 PM, Jon Lang wrote:
> Solomon Foster wrote:
>> Ranges haven't been intended to be the "right way" to construct basic
>> loops for some time now. That's what the "..." series operator is
>> for.
>>
>> for 1e10 ... 1 -> $i {
>> # whatever
>> }
>>
>> is la
Solomon Foster wrote:
> Ranges haven't been intended to be the "right way" to construct basic
> loops for some time now. That's what the "..." series operator is
> for.
>
> for 1e10 ... 1 -> $i {
> # whatever
> }
>
> is lazy by the spec, and in fact is lazy and fully functional in
>
On Tue, Jul 20, 2010 at 7:31 PM, Aaron Sherman wrote:
> 2) We deny that a range whose LHS is "larger" than its RHS makes sense, but
> we also don't provide an easy way to construct such ranges lazily otherwise.
> This would be annoying only, but then we have declared that ranges are the
> right wa
pugs-comm...@feather.perl6.nl wrote:
Modified:
docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
[S32/Temporal] Reverted DateTime back to being mutable. I think we ought to
make a big change like this only after reaching some kind of consensus to do
so, not least because I just implement
Author: Kodi
Date: 2010-07-21 02:12:24 +0200 (Wed, 21 Jul 2010)
New Revision: 31777
Modified:
docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
[S32/Temporal] Reverted DateTime back to being mutable. I think we ought to
make a big change like this only after reaching some kind of consensus
This is a long reply, but I read it over a few times, and I don't see any
fat to trim. This isn't really a simple issue for which intuition is going
to be a sufficient guide, though I agree fully that it needs to be high on
or at the top of the list.
On Sun, Jul 18, 2010 at 6:26 AM, Moritz Lenz w
On Tue, Jul 20, 2010 at 5:51 PM, wrote:
> +C objects are immutables.
> +
I think just the adjective works better here ("are immutable")... but
more to the point:
> +A C can also be created by modifying an existing object:
It's mildly confusing to say they're immutable and then turn around
and
Author: dolmen
Date: 2010-07-20 23:51:26 +0200 (Tue, 20 Jul 2010)
New Revision: 31776
Modified:
docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
[S32/Temporal] Make DateTime immutable.
Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod
On Fri, Jul 16, 2010 at 06:37:41PM -0700, Tyler Curtis wrote:
> At parrot r48099, with Rakudo version Kiev-272-gdd8d5d7, "state"
> variables are not implemented.
> However, Rakudo version Kiev-272-gdd8d5d7 produces the following error
> message:
>
> ===SORRY!===
> Symbol '$c' not predeclared in
Author: tene
Date: 2010-07-20 20:35:35 +0200 (Tue, 20 Jul 2010)
New Revision: 31773
Modified:
docs/Perl6/Spec/S03-operators.pod
Log:
Fix minor typo
Modified: docs/Perl6/Spec/S03-operators.pod
===
--- docs/Perl6/Spec/S03-operators.
On Mon Jan 04 16:40:58 2010, dave.wh...@gmail.com wrote:
> By principle of least surprise, all three of these should result in
> the same output:
>
> rakudo: say (0,1).grep: {!($^x%2)}
> rakudo db84bc: 0
>
> rakudo: say (0,1).grep: !(*%2)
> rakudo db84bc: #{empty-list}
>
> rakudo: say (0,1)
On Tue Apr 13 08:51:39 2010, masak wrote:
> rakudo: subset Foo of Array where { .elems == 5 }; sub bar(Foo
> $_) {}; bar([1,2,3])
> rakudo cb4521: OUTPUT«Nominal type check failed for parameter
> '$_'; expected Array but got Array instead [...]
> * masak submits rakudobug
> it's not the nominal
On Tue Apr 13 09:02:12 2010, masak wrote:
> rakudo: class G {}; subset A of Array where { all(|$_) ~~ G };
> say [G.new, G.new, G.new] ~~ A
> rakudo 3b5a79: OUTPUT«0»
> :(
> rakudo: say all(42) ~~ Int
> rakudo 3b5a79: OUTPUT«0»
> maybe junctional smartmatching simply isn't in place yet.
Ti
On Mon Jul 19 09:25:15 2010, masak wrote:
> rakudo: say Int ~~ Num
> rakudo cf5f19: OUTPUT«1»
> die die die!
> Int isn't a Num?
> mathw: Not any more
> It's a Numeric
> And we go to quite a length to make Int pretend it's a Num.
> Almost certain it shouldn't be these days though.
> * masak
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #76574]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=76574 >
rakudo: say Int ~~ Num
rakudo cf5f19: OUTPUT«1»
die die die!
Int isn't a Num?
math
# New Ticket Created by Audrey Tang
# Please include the string: [perl #76584]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=76584 >
# Fails: get_string() not implemented in class 'P6Invocation'
class C { method M {} }; sa
On Sun Jul 18 23:16:41 2010, moritz wrote:
> I've rebased the patch to cleanly apply to current rakudo HEAD, no
> functional changes.
>
> (I don't feel qualified to review this patch, but I hope that jnthn gets
> around to it soon)
I reviewed it and moritz++ applied it earlier on with a tweak. So
On Sat Jun 26 02:34:03 2010, moritz wrote:
> 11:29 * moritz_ has a case of totally wrong line number
> 11:29 <@jnthn> OH NOES
> 11:29 <@jnthn> moritz_: How rong is rong?
> 11:29 <@moritz_> jnthn: line 67 for a 30 line file
> 11:29 <@jnthn> lol
> 11:30 <@moritz_> rakudo: class A { has $.x is rw };
On Mon May 03 02:19:31 2010, stefa...@cox.net wrote:
> 02:07 < sorear> rakudo: module Soric4::Event; macro foo is parsed( 0 ) { }
> 02:07 <+p6eval> rakudo c4857a: OUTPUT«Confused at line 11, near "module
> Sor"current instr.: 'perl6;HLL;Grammar;panic' pc 500
> (ex
On Fri Jun 18 00:34:24 2010, cognominal wrote:
> I am not sure how much * is supposed to DWIM
>
More than it was. When you submitted:
> > < 1 2 3 >.map: * ~ 2
> 12 22 32
> > < 1 2 3 >.map: 2 ~ * ~ 2
> No candidates found to invoke
> >
> > (*+1)(1)
> 2
> >
> > (*+*)(1,2)
> 3
> > (*+*+*)(1,2,3)
32 matches
Mail list logo
