On 10/22/2010 06:16 AM, Damian Conway wrote:
That is, a C$value is an eigenstate of a C$junction if-and-only-if:
$value !~~ Junction$value ~~ $junction
In general this definition makes it impossible to return a list of
eigenstates from the junction. Just think of junctions containing
Moritz wrote:
$value !~~ Junction $value ~~ $junction
In general this definition makes it impossible to return a list of
eigenstates from the junction. Just think of junctions containing Code
objects.
Well, that's a deficiency in smartmatching: that Callable ~~ Code doesn't
check
On 11/01/2010 12:41 PM, Damian Conway wrote:
Moritz wrote:
$value !~~ Junction$value ~~ $junction
In general this definition makes it impossible to return a list of
eigenstates from the junction. Just think of junctions containing Code
objects.
Well, that's a deficiency
Food for thought, a few non-junction solutions:
On 10/22/2010 06:16 AM, Damian Conway wrote:
# Find the list of common elements in two lists...
sub intersection (@list1, @list2) {
(any(@list1) any(@list2).eigenstates;
}
sub intersection(@list1, @list2) {
uniq gather
a list of
eigenstates from the junction. Just think of junctions containing Code
objects. Or anything more complicated than the built-in value types.
[Originally sent to Moritz alone because of Reply not sending to the list]
Is it too late in this discussion to point out that, in non-perl
usage
Buddha Buck wrote:
Is it too late in this discussion to point out that, in non-perl
usage, eigenstates are associated with the operator, not with the
value fed into the operator?
[cut]
So asking for the eigenstates of a quantum superposition is asking the
wrong object for the property.
...or junctions.
That doesn't make either or != intrinsically invalid on vector types
(though they obviously are inappropriate for *some* vector types); it just
means you can't reasonably treat the two operators as universally
interchangeable, just because they sometimes are.
Well, I think returning
Martin D Kealey suggested:
Well, I think returning or throwing an Unordered exception would be
the appropriate way to handle those, both for complex numbers and for
junctions.
For complex numbers that might be true, because the order relationship
between two complex numbers isn't expressible
Martin D Kealey asked:
Or do we not invert junctions, and run the risk of unexpected
action-at-a-distance instead?
I think our current approach is correct. That is: we invert
junctions on operators that are themselves intrinsically inverted
(such as !=, !~~, !), but do not invert on those
.
That's certainly true, although junctions are supposed to guarantee
to coalesce all the threads they may generate back into a single superimposed
result back in the originating thread.
The problem only arises if an operation or subroutine that has been
junctively threaded terminates without returning
I have to admit to feeling uneasy about the whole action-at-a-distance
effect that junctions are capable of producing. They sit around pretending
to be a scalar, only to pop up and wreak havoc with ones expectations of
linearity when you're not expecting it.
That unexpected-action-at-a-distance
Jon Lang wrote:
Personally, I don't think that it should be a public method: one thing
about junctions is that you can use them interchangeably with ordinary
scalars; giving them a public method breaks that. In particular, code
that makes use of a Junction public method would break if you
On 2010-Oct-25, at 15:14, Damian Conway wrote:
Yes, Ted Z. pointed out to me that, as the name of this construct,
every has ambiguity and synonym issues. Other possibilities are:
select(@values) one(3..7)
those(@values) one(3..7)
whichever(@values) one(3..7)
On Oct 22, 6:41 pm, dam...@conway.org (Damian Conway) wrote:
Dave Whipp wrote:
When this issue has been raised in the past, the response has been that
junctions are not really intended to be useful outside of the narrow purpose
for which they were introduced.
Hmm. There are intentions
Ben Goldberg asked:
I'm probably missing something, but wouldn't it have been easier to
write that module by using eval STRING to create all of those infix
operators?
Sure. But the module is already slow to start up. I was concerned
that it would get even slower with an embedded eval. But, in
Damian Conway wrote:
So I'm going to go on to propose that we create a fifth class of
Junction: the transjunction, with corresponding keyword Cevery.
[...]
say (^10 G[] one(3,7));
3 4 5 6
which could also be:
say every(^10) one(3,7);
# Every value up to 10 that's greater than 3
Dave Whipp noted:
I think that the two proposals are equivalent, in the sense that either can
be trivially implemented using the other.
Agreed.
However, I am a little concerned that the transjunction magically changes
an operator that returns a Boolean value into one that returns a list.
Damian Conway wrote:
Yes, Ted Z. pointed out to me that, as the name of this construct,
every has ambiguity and synonym issues. Other possibilities are:
select(@values) one(3..7)
those(@values) one(3..7)
whichever(@values) one(3..7)
itemize(@values) one(3..7)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/22/10 13:00 , Dave Whipp wrote:
Damian Conway wrote:
I've been thinking about junctions, and I believe we may need a small
tweak to (at least) the jargon in one part of the specification.
When this issue has been raised in the past
Brandon mused:
It occurs to me: If their purpose is that narrow, why are they wasting
conceptual space in the core language?
Well, mainly because their purpose isn't narrow at all: it's parallelized data
comparisons (all(@values) $threshold), and multiway comparisons
(all(@values) ~~
In general I like where this is going but need a little hand holding
here- I'm not an expert on junctions or anything perl6-
So I'm going to go on to propose that we create a fifth class of
Junction: the transjunction, with corresponding keyword Cevery.
It seems that by these definitions every
In general I like where this is going but need a little hand holding
here- I'm not an expert on junctions or anything perl6-
So I'm going to go on to propose that we create a fifth class of
Junction: the transjunction, with corresponding keyword Cevery.
It seems that by these definitions
Damian Conway wrote:
I've been thinking about junctions, and I believe we may need a small
tweak to (at least) the jargon in one part of the specification.
When this issue has been raised in the past, the response has been that
junctions are not really intended to be useful outside
Dave Whipp wrote:
When this issue has been raised in the past, the response has been that
junctions are not really intended to be useful outside of the narrow purpose
for which they were introduced.
Hmm. There are intentions, and then there are intentions. I know
what I intended when I
I've been thinking about junctions, and I believe we may need a small
tweak to (at least) the jargon in one part of the specification.
Specificially, in S32-setting-library_Containers.pod, we currently have:
=item !eigenstates
method !eigenstates (Junction $j: -- Parcel
simultaneously using junctions (or some other new mechanism)? In
Perl 5, I would do
$hash{'foo'} = $hash{'bar'} = 'some value';
which gets tedious with more than one hash key. An alternative is always
@hash{qw(foo bar)} = ('some value') x 2;
which is probably
%hashfoo bar = ('some value') x 2
2009/6/8 Ville Koskinen vrk...@iki.fi:
Hello all,
I was curious if this is possible in Perl 6:
%hash{ 'foo' 'bar' } = 'some value';
# %hash{'foo'} eq 'some value' and %hash{'bar'} eq 'some value'
By autothreading, this would be equivalent to:
(%hash{'foo'} %hash{'bar'}) = 'some
On Mon, Jun 08, 2009 at 12:02:43PM +0100, Ville Koskinen wrote:
: An alternative is always
:
: @hash{qw(foo bar)} = ('some value') x 2;
:
: which is probably
:
: %hashfoo bar = ('some value') x 2;
:
: in Perl 6, but you always need to take care to write the correct integer
: in the list
Dave Whipp wrote:
I'm thinking that the solution to this issue may be a little more
radical than to-date: don't permit junctions to be stored in $
variables! Instead, require junctions to use a twiggle, to alert the
reader that the surprises may be lurking.
my $x = 1|2; #error
my $|x = 1|2
conditionals generally force full or partial
resolution on junctions, that lifetime won't tend to be very long.
Re: Tsa's comment about junctions being value types. In principle I agree,
except that the value semantics are only within the eigenthreads; outside
that, they are collections of indeterminate
On Wed, 1 Apr 2009, John Macdonald wrote:
If I understand correctly, (which is by no means assured) a function
call with a junction as an argument generally acts as if it were
autothreaded. So:
$x = any(1,2,3);
$y = f($x);
should work like:
$y = any( f(1), f(2),
Martin Kealey wrote:
On Tue, 31 Mar 2009, Jon Lang wrote:
Another issue: what happens if conditional code mutates a junction
that it filtered? For example:
$x = any (-5 .. 5);
if $x 0 { $x++ };
At this point, which of the following does $x equal?
any(-4 .. 6) # the original
a coercion to Set.
This would give the necessary extra syntax to ensure that the programmer
knows what s/he is doing. It means that junctions could be threshed and
sieved when desired.
There would have
to be some caveats about using that as the universe of values, however,
since none
Thinking about Jon Lang's -1|+1 example in another way, I wondered about
simultaneous conditions.
Consider
$x = any (1,2,5,6)
How do we compose a conditional that asks if any of this set of
eigenstates are simultaneously both 2 and 5?
Clearly the desired answer for $x is False, but
my $x
that will achieve this?
my @x = 1, 2, 5, 6; say ?(first { 2 $_ 5 }, @x); # false
Problem solved. It doesn't involve the cool junctions technology, but
it's not much longer, and perhaps slightly more understandable.
// Carl
that runs
the comparison -1 = $b. OTOH, since (*A*) spells out two
separate junctions, it would thread each one separately; resulting in
four threads being used to resolve the expression. In theory, at
least; in practice, he's looking for ways to simulate such threading
without actually having
On Wed, Apr 1, 2009 at 12:58 AM, Richard Hainsworth
rich...@rusrating.ru wrote:
Thinking about Jon Lang's -1|+1 example in another way, I wondered about
simultaneous conditions.
Consider
$x = any (1,2,5,6)
How do we compose a conditional that asks if any of this set of eigenstates
are
that there is an assumption that $x is a
point in a field (http://en.wikipedia.org/wiki/Field_theory_(mathematics)).
As you have illustrated, junctions do no form a field.
You would run into the similar problems if $x was a point in a ring
(http://en.wikipedia.org/wiki/Ring_(mathematics
The idea is that junctions should usually be invisible to the code,
and autothreading handles them behind the scenes. Once you start
using the eigenstates as a collection, you're breaking the model and
not gaining anything over just using a regular collection type.
But the behind the scenes
On Wed, Apr 01, 2009 at 09:44:43AM -0400, Mark J. Reed wrote:
The idea is that junctions should usually be invisible to the code,
and autothreading handles them behind the scenes. [ ... ]
If I understand correctly, (which is by no means assured) a function
call with a junction as an argument
Richard Hainsworth wrote:
Thinking about Jon Lang's -1|+1 example in another way, I wondered about
simultaneous conditions.
Consider
$x = any (1,2,5,6)
How do we compose a conditional that asks if any of this set of
eigenstates are simultaneously both 2 and 5?
Clearly the desired answer
HaloO,
Jon Lang wrote:
Another issue: what happens if conditional code mutates a junction
that it filtered? For example:
$x = any (-5 .. 5);
if $x 0 { $x++ };
At this point, which of the following does $x equal?
any(-4 .. 6) # the original junction gets mutated
any(-5 .. 0,
that runs the
comparison $a = -1 in (*B*) is the same thread that runs
the comparison -1 = $b. OTOH, since (*A*) spells out two
separate junctions, it would thread each one separately; resulting in
four threads being used to resolve the expression. In theory, at
least; in practice, he's
Jon Lang wrote:
[proposal that conditional statements should collapse junctions]
$x = +1 | -1;
if $x 0 { say $x is positive. }
else { say $x is negative. }
I suspect that both codeblocks would be executed; but within the first
block, $x == +1, and within the second codeblock, $x
, then perl6 junctions are not really modelling
quantum superpositions
I agree. We should make sure that junctions model quantum
computations.
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
when needed, but don't attempt to be too clever.
While it's easier to find clever programmers than to write clever software,
the gains from the latter are significant, as Larry's work pre- and
post-Perl has repeatedly demonstrated. When a language implementation
provides a feature like junctions
. There would have
to be some caveats about using that as the universe of values, however,
since none() junctions define a set outside of the eigenstates.
For that reason I'd still prefer people to track their universe of
values outside the junctions rather than rely on junctions for that.
And of course
to write clever software,
the gains from the latter are significant, as Larry's work pre- and
post-Perl has repeatedly demonstrated. When a language implementation
provides a feature like junctions that is arguably too clever by half to
start with, I'd rather there be a commensurate amount of cleverness
On Tue, 31 Mar 2009, Jon Lang wrote:
Another issue: what happens if conditional code mutates a junction
that it filtered? For example:
$x = any (-5 .. 5);
if $x 0 { $x++ };
At this point, which of the following does $x equal?
any(-4 .. 6) # the original junction gets mutated
appear to have a uniform (single) value in each
eigenthread.
Ugh. Let me float another problem, and a possible solution to both,
that doesn't require persistent threading environments:
$x = -1 | +1;
if $x 0 { say $x }
As I understand junctions right now, the result of this code is identical
possibilities within it that would have passed the decision point
exist.
With unless, while, until, and loop, the associated block is
the conditional block where the junction gets filtered. With if,
the main block likewise filters the junctions; but the else block
also provides junction filtering
Em Dom, 2009-03-29 às 22:57 -0700, Mark Lentczner escreveu:
What I see here is that there is a tendency to want to think about,
and operate on, the eigenstates as a Set, but this seems to destroy
the single value impersonation of the Junction.
Further, if one ever calls .!eigenstates() on
eigenstates to be callable on an Object as
described - and, in general, _any other_ function that operates
directly on junctions should be able to accept Objects as well,
treating the Object as a one-eigenstate junction.
Otherwise, the moment you write a function that passes a junction as a
parameter, your
Jon Lang wrote:
I stand corrected. That said: with the eigenstates method now
private, it is now quite difficult to get a list of the eigenstates of
the above expression.
I thought about that a bit, and I think eigenstates are not hard to
extract (which somehow makes the privateness of
On Sat, Mar 28, 2009 at 10:39:01AM -0300, Daniel Ruoso wrote:
That happens because $pa and $pb are a singular value, and that's how
junctions work... The blackjack program is an example for sets, not
junctions.
Now, what are junctions good for? They're good for situation where it's
On Sun, Mar 29, 2009 at 1:18 PM, John Macdonald j...@perlwolf.com wrote:
On Sat, Mar 28, 2009 at 10:39:01AM -0300, Daniel Ruoso wrote:
That happens because $pa and $pb are a singular value, and that's how
junctions work... The blackjack program is an example for sets, not
junctions.
Now
What I see here is that there is a tendency to want to think about,
and operate on, the eigenstates as a Set, but this seems to destroy
the single value impersonation of the Junction.
Further, if one ever calls .!eigenstates() on a Junction, then you
have really bollox'd your code up, as
I stand corrected. That said: with the eigenstates method now private,
it is now quite difficult to get a list of the eigenstates of the
above expression.
Yes, that's a concern. Most of the interesting junction-based algorithms
I've developed in the past rely on two facilities: the ability to
Daniel Ruoso wrote:
The thing is that junctions are so cool that people like to use it for
more things than it's really usefull (overseeing that junctions are too
much powerfull for that uses, meaning it will lead to unexpected
behaviors at some point).
What are the general boundaries
Em Sáb, 2009-03-28 às 16:17 +1100, Damian Conway escreveu:
Nested heterogeneous junctions are extremely useful. For example, the
common factors of two numbers ($x and $y) are the eigenstates of:
all( any( factors($x) ), any( factors($y) ) )
I think that's the exact case where we should
Em Sáb, 2009-03-28 às 13:36 +0300, Richard Hainsworth escreveu:
Daniel Ruoso wrote:
The thing is that junctions are so cool that people like to use it for
more things than it's really usefull (overseeing that junctions are too
much powerfull for that uses, meaning it will lead to unexpected
On Fri, Mar 27, 2009 at 05:49:02PM -0400, Henry Baragar wrote:
I believe that there are hands where $p = 15|26 which would not beat a
hand where $d = 17.
I believe that the correct way to calculate the value of the hand is:
my $p = ([+] @p).map{.eigenstates}.grep{$_ 21}.max;
Since the
Daniel Ruoso wrote:
But the semantics of sets are still somewhat blurry... there are some
possibilities:
1) Sets are in the same level as junctions, but have no collapsing and
allow you to get its values. The problem is if it autothreads on
method calls or not... It also makes
HaloO,
On Friday, 27. March 2009 12:57:49 Daniel Ruoso wrote:
1 - multi infix:+(Set $set, Num $a)
This would return another set, with each value of $set summed with $a.
I think that this mixed case should numify the set to
the number of elements to comply with array semantics.
infix:+ should
Patrick R. Michaud wrote:
On Fri, Mar 27, 2009 at 05:49:02PM -0400, Henry Baragar wrote:
I believe that there are hands where $p = 15|26 which would not beat a
hand where $d = 17.
I believe that the correct way to calculate the value of the hand is:
my $p = ([+]
On Sat, Mar 28, 2009 at 6:39 AM, Daniel Ruoso dan...@ruoso.com wrote:
Em Sáb, 2009-03-28 às 13:36 +0300, Richard Hainsworth escreveu:
Daniel Ruoso wrote:
The thing is that junctions are so cool that people like to use it for
more things than it's really usefull (overseeing that junctions
Thomas Sandlaß wrote:
Set operations are with parens.
Which Synopsis is this in?
--
Jonathan Dataweaver Lang
Daniel Ruoso wrote:
But even to compare two hands it gets weird...
my @a = 1|11, 9, 1|11;
my @b = 6,9,6;
my $pa = [+] @a;
my $pb = [+] @b;
if ($pa = 21 $pb = 21) {
if ($pa $pb) {
# B0RK3D
}
}
That happens because $pa and $pb are a singular value, and that's how
junctions
Henry Baragar wrote:
The blackjack program is an excellent example for junctions (and not so good
for sets, IMHO). The problem in the example above is that the calculation
of the value of a hand was not completed. The complete calculation is as
follows:
my $pa = ([+] @a).eigenstates.grep
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
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)
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
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 instead
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
On Fri, Mar 27, 2009 at 10:27 AM, Moritz Lenz
ml...@physik.uni-wuerzburg.de 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
On Fri, Mar 27, 2009 at 11:45 AM, Mark J. Reed markjr...@gmail.com 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
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
On Fri, Mar 27, 2009 at 10:39 AM, Dave Whipp d...@dave.whipp.name 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
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
have something like a filter function
yes, but
that takes a
junction and a test condition and returns a junction of those
eigenstates from the original one that passed the test.
But why is this a useful thing to do? I think that you're proposing, for
compound junctions:
ok any( 1|2, 12, 5|15
:
Maybe you could have something like a filter function
yes, but
that takes a
junction and a test condition and returns a junction of those
eigenstates from the original one that passed the test.
But why is this a useful thing to do? I think that you're proposing, for
compound junctions
Jon Lang wrote:
For that matter, I'm not seeing a difference between:
any( 12 ) # 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(12) == 2 is false
Nested heterogeneous junctions are extremely useful
Damian Conway wrote:
Jon Lang wrote:
For that matter, I'm not seeing a difference between:
any( 12 ) # 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(12) == 2 is false
Nested heterogeneous junctions
On Wed, Nov 05, 2008 at 11:28:00AM -0800, Larry Wall wrote:
But it seems to me that if stringification of a junction returns a
correct .perlish syntax, it's probably better to just let that happen
lazily, on the assumption someone might want .perl to autothread for
some reason, perhaps because
of method autothreading over junctions came up at
: the OSCON 2008 hackathon, but I don't know that it was ever
: resolved. If it was and I've just forgotten or overlooked the
: resolution, I'll be happy to have it pointed out to me.)
Well, at the time we thought there might need to be some kind
in boolean context';
I re-wrote the tests to use that kind of syntax, and add it to the
official tests:
http://svn.pugscode.org/pugs/t/spec/S03-junctions/boolean-context.t
My next step will be to fudge it for rakudo.
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Moritz Lenz wrote:
Tests 34 to 36 were a bit overcritical:
(0|undef say not ok 34) || say not ok 34;
(0undef say not ok 35) || say not ok 35;
(0^undef say not ok 36) || say not ok 36;
but are easily corrected. The rest seem fine to me.
Easier said than done.
Question to p6l: do and
On Sun, Aug 24, 2008 at 09:22:25PM +0200, Moritz Lenz wrote:
: Moritz Lenz wrote:
: Tests 34 to 36 were a bit overcritical:
:
: (0|undef say not ok 34) || say not ok 34;
: (0undef say not ok 35) || say not ok 35;
: (0^undef say not ok 36) || say not ok 36;
:
: but are easily corrected.
On Sun, Aug 24, 2008 at 03:00:54PM -0700, Larry Wall wrote:
: Question to p6l: do and || autothread? Or do they collapse the
: junction prior to evaluation? (I hope the latter, since I think it's
: more dwimmy).
:
: Also do prefix:? and prefix:! collapse the junction?
I think it would be
Larry Wall wrote:
On Sun, Aug 24, 2008 at 09:22:25PM +0200, Moritz Lenz wrote:
: Moritz Lenz wrote:
: Tests 34 to 36 were a bit overcritical:
:
: (0|undef say not ok 34) || say not ok 34;
: (0undef say not ok 35) || say not ok 35;
: (0^undef say not ok 36) || say not ok 36;
:
:
On Sun, Aug 24, 2008 at 05:05:46PM -0500, Patrick R. Michaud wrote:
: On Sun, Aug 24, 2008 at 03:00:54PM -0700, Larry Wall wrote:
: : Question to p6l: do and || autothread? Or do they collapse the
: : junction prior to evaluation? (I hope the latter, since I think it's
: : more dwimmy).
: :
On Mon, Aug 25, 2008 at 12:15:05AM +0200, Moritz Lenz wrote:
Larry Wall wrote:
I think it would be best if all boolean contexts collapse consistently,
and I would consider all of those to be boolean contexts. More
precisely, and || are boolean on the left, but not on the right.
Very
Hi all,
I use Perl6::Junction in Perl 5 and recently the author implemented the
values method on junctions. I needed this because I sometimes find
that I need to do something conceptually similar to this:
my $number = any( 0 .. 19 );
while ($number-values) {
my $rand int(rand(20
I'd say that this ought to be implemented using :v (as in, 'values';
cf. :k, :kv, and :p for lists and hashes): this should let you look at
the values within the Junction as if they were merely a list of
values, at which point you can construct a new Junction from them.
--
Jonathan Dataweaver
Ovid wrote:
(reversed the message a bit)
is 'b', any('a' .. 'h'), 'junctions should work';
This looks like a Test bug; it's doing something like:
is 'b', 'a' # not ok
is 'b', 'b' # ok
is 'b', 'c' # not ok
...
If you write:
ok 'b' === any('a'..'h')
The result is one passing
On Wed, Dec 20, 2006 at 10:26:41AM -0600, Jonathan Rockway wrote:
: Ovid wrote:
: (reversed the message a bit)
:is 'b', any('a' .. 'h'), 'junctions should work';
:
: This looks like a Test bug; it's doing something like:
:
:is 'b', 'a' # not ok
:is 'b', 'b' # ok
:is 'b', 'c
Almost a year ago (2005-04-27), I wrote the list asking a question about
junctions.
Specifically, the ability to find the intersection, union, etc of a list.
my $matches = any( @x_chars ) eq any( @y_chars );
my $match = $matches.pick;
all( any() eq any() );
Patrick Michaud offered an infix myeq
On Tue, Apr 04, 2006 at 09:16:23AM -0400, Joshua Gatcomb wrote:
: Almost a year ago (2005-04-27), I wrote the list asking a question about
: junctions.
: Specifically, the ability to find the intersection, union, etc of a list.
Junctions are not intended for that use. We have Sets for that now
On the other hand, if junctions really are sets of sets, then maybe it's
a mistake to autocoerce junctions to sets by swiping their internal set
of values. Arguably any(1,2,3) should coerce not to
(1,2,3)
but to
(
(1),
(2),
(3),
(1,2),
(1,3
1 - 100 of 297 matches
Mail list logo
