The following arose out of a discussion on #perl6. Junctions are new and
different from anything I have encountered, but I cant get rid of the
feeling that there needs to be some more flexibility in their use to
make them a common programming tool.
Background: Imagine a hand of cards. Cards ma
Please find attached a patch to implement requested functionality.
Passes split-simple.t tests and includes a patch that updates those
tests and adds one more that verifies correct performance with a return
limit count.
Index: t/spec/S32-str/split-simple.t
=
Em Sex, 2009-03-27 às 13:36 +0300, Richard Hainsworth escreveu:
> On #perl6, rouso, masak and moritz_ explained that I am incorrectly
> thinking about junctions as sets and that for this task I should be
> using another perl idiom, namely lists.
Sorry for not taking each individual point on your
Em Sex, 2009-03-27 às 08:57 -0300, Daniel Ruoso escreveu:
> So I get that we do need some cool support for sets as well, I mean...
> no collapsing, no autothreading... but maybe some specific behaviors...
As an aditional idea...
multi infix:<⋃>(Set $a, Set $b) {...}
multi infix:<⋂>(Set $a, Set $b
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #64220]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=64220 >
rakudo: /<[..b]>/
rakudo 7d9cd9: OUTPUT«Cannot get character of empty string [...]
* m
>From a high-level perspective, the blackjack example seems perfect for
junctions. An Ace isn't a set of values - its one or the other at a
time. It seems to me if you can't make it work with junctions - f you
have to use sets instead - then there's something wrong with the
implementation of junc
On Thu, Mar 26, 2009 at 06:00:29PM -0700, Ron Schmidt via RT wrote:
> Please find attached a patch to implement requested functionality.
> Passes split-simple.t tests and includes a patch that updates those
> tests and adds one more that verifies correct performance with a return
> limit count.
>
Em Sex, 2009-03-27 às 09:17 -0400, Mark J. Reed escreveu:
> From a high-level perspective, the blackjack example seems perfect for
> junctions. An Ace isn't a set of values - its one or the other at a
> time. It seems to me if you can't make it work with junctions - f you
> have to use sets inste
On Fri, Mar 27, 2009 at 10:27 AM, Moritz Lenz
wrote:
> Mark J. Reed wrote:
>> From a high-level perspective, the blackjack example seems perfect for
>> junctions. An Ace isn't a set of values - its one or the other at a
>> time. It seems to me if you can't make it work with junctions - f you
>>
On Fri, Mar 27, 2009 at 11:45 AM, Mark J. Reed wrote:
> Given two
> junctions $d and $p, just adding $d + $p gives you all the possible
> sums of the eigenstates. Given two sets D and P, is there an equally
> simple op to generate { d + p : d ∈ D, p ∈ } ?
Dropped a P there - should be { d + p :
Mark J. Reed wrote:
> From a high-level perspective, the blackjack example seems perfect for
> junctions. An Ace isn't a set of values - its one or the other at a
> time. It seems to me if you can't make it work with junctions - f you
> have to use sets instead - then there's something wrong with
On 2009-Mar-26, at 10:50 pm, Patrick R. Michaud wrote:
But what to do with something like C< 3 cmp '3' >, or any
infix: where the operands are of differing types? Do we
constrain C to only work on similarly-typed operands (in which
case my sort above would fail), or am I overlooking somethi
Richard Hainsworth wrote:
The following arose out of a discussion on #perl6. Junctions are new and
different from anything I have encountered, but I cant get rid of the
feeling that there needs to be some more flexibility in their use to
make them a common programming tool.
I strongly agree w
In the case of strings and numbers, I'd recommend using leg instead of
cmp - that is, coerce both items to strings, then compare the strings.
But as far as cmp goes, "3 cmp '3'" should fail because a number
isn't a string.
--
Jonathan "Dataweaver" Lang
Author: pmichaud
Date: 2009-03-27 20:45:51 +0100 (Fri, 27 Mar 2009)
New Revision: 26016
Modified:
docs/Perl6/Spec/S05-regex.pod
Log:
[S05]: Correct typo "by use if" ==> "by use of"
Modified: docs/Perl6/Spec/S05-regex.pod
===
--
On Fri, Mar 27, 2009 at 10:39 AM, Dave Whipp wrote:
> Richard Hainsworth wrote:
>>
>> The following arose out of a discussion on #perl6. Junctions are new and
>> different from anything I have encountered, but I cant get rid of the
>> feeling that there needs to be some more flexibility in their u
Richard Hainsworth wrote:
The following arose out of a discussion on #perl6. Junctions are new
and different from anything I have encountered, but I cant get rid of
the feeling that there needs to be some more flexibility in their use
to make them a common programming tool.
Background: Imag
[I’d been planning to put this suggestion on hold until the spec is
sufficiently complete for me to attempt to implement it as a module. But
people are discussing this again, so maybe it's not just me. I apologize
if I appear to be beating a dead horse...]
Jon Lang wrote:
Maybe you could hav
> That's not right, is it? Or I don't understand what perl 6 does with
> the capturing parens that's different from perl 5. In perl 5 (and what
> I would expect from perl 6), @split would contain the following strings
> at the following array indices:
>
...
Your concern seems to be with the add
> Can you give us any update on these tests on the same platform?
>
I'll be able to check early tomorrow (Saturday) afternoon.
BTW, this mail account will be disappearing in a month or so. I have
1parr...@gmail.com as a substitute.
--
Email and shopping with the feelgood factor!
55% of in
Dave Whipp wrote:
> [I’d been planning to put this suggestion on hold until the spec is
> sufficiently complete for me to attempt to implement it as a module. But
> people are discussing this again, so maybe it's not just me. I apologize if
> I appear to be beating a dead horse...]
>
> Jon Lang wro
Jon Lang wrote:
> For that matter, I'm not seeing a difference between:
>
>any( 1&2 ) # any of all of (1, 2)
>
> ...and:
>
>any( 1, 2 ) # any of (1, 2)
Those two are very different.
any(1,2) == 2 is true
any(1&2) == 2 is false
Nested heterogeneous junctions are extremely u
Damian Conway wrote:
> Jon Lang wrote:
>
>> For that matter, I'm not seeing a difference between:
>>
>> any( 1&2 ) # any of all of (1, 2)
>>
>> ...and:
>>
>> any( 1, 2 ) # any of (1, 2)
>
> Those two are very different.
>
> any(1,2) == 2 is true
>
> any(1&2) == 2 is false
>
>
> Nest
Hi all. I've been thinking about stringification, forms, and things
like that.
As exegesis 7 points out, sprintf, pack, and the forms language all
essentially take data and specifies how to turn it into a "string" (I'm using
"string" loosely here). Likewise with .perl -- it takes some data
24 matches
Mail list logo
