Larry Wall wrote:
> eqv and === autothread just like any other comparisons. If you really
> want to compare the contents of two junctions, you have to use the
> results of some magical .eigenmumble method to return the contents
> as a non-junction. Possibly stringification will be sufficient, if
Darren Duncan wrote:
Larry Wall wrote:
It seems simpler to say that one() produces bags rather than sets.
If we don't make other modifications to the language then this would
mean that a Junction is defined over a union type, "Set|Bag with
additional behaviors", depending on what operator co
Larry Wall wrote:
It seems simpler to say that one() produces bags rather than sets.
If we don't make other modifications to the language then this would mean that a
Junction is defined over a union type, "Set|Bag with additional behaviors",
depending on what operator constructed it.
Now ma
S06:2362 says:
You can get the current routine name by calling C<&?ROUTINE.name>.
(The outermost routine at a file-scoped compilation unit is always
named C<&MAIN> in the file's package.)
Is this the same MAIN that is described later in
"Declaring a MAIN subroutine"? It seems like t
On Thu, Nov 13, 2008 at 09:40:19AM -0800, Larry Wall wrote:
> On Thu, Nov 13, 2008 at 05:02:56PM +0100, TSa wrote:
> > Patrick R. Michaud wrote:
> >> I expect that $a will become one(True, False, True). $a doesn't
> >> collapse to a non-Junction False until it is used in a boolean context.
> >
> >
On Thu, Nov 13, 2008 at 05:37:21PM +0100, TSa wrote:
> HaloO,
>
> reading the "Collapsing Junction states" thread I wondered
> how eqv and === handle junctions. I would expect
>
>all(1,2) === all(1,2)
>
> to evaluate to True and not expand to
>
>1 === 1 && 1 === 2 && 2 === 1 && 2 === 2
>
>
On Thu, Nov 13, 2008 at 05:02:56PM +0100, TSa wrote:
> HaloO,
>
> Patrick R. Michaud wrote:
>> I expect that $a will become one(True, False, True). $a doesn't
>> collapse to a non-Junction False until it is used in a boolean context.
>
> My proposal is a different unification behavior in one() jun
HaloO,
Patrick R. Michaud wrote:
By way of illustration, contrast the two assignments at
the end of the following code:
my @x = ;
my @y;
@y[1] = @x, 'c';
@y[1,2,3] = @x, 'c';
The second assignment would seem to clearly be a list
assignment, leaving @y with (undef, 'a', 'b', 'c
HaloO,
reading the "Collapsing Junction states" thread I wondered
how eqv and === handle junctions. I would expect
all(1,2) === all(1,2)
to evaluate to True and not expand to
1 === 1 && 1 === 2 && 2 === 1 && 2 === 2
which is False. OTOH,
2 === any(1,2,3)
should be False because 2.W
HaloO,
Patrick R. Michaud wrote:
I expect that $a will become one(True, False, True). $a doesn't
collapse to a non-Junction False until it is used in a boolean context.
My proposal is a different unification behavior in one() junctions.
my $a = one(1,2,3) % 2 == 1;
--> my $a = o
HaloO,
Leon Timmermans wrote:
But of what use would one() if it were to use those semantics? It
would be essentially the same as any(), and it would definitely not
DWIM.
So you want one(1,1,2,3) to compare equal to 2 or 3 and exclude 1
because it is in the junction twice. That could be accompl
On Thu, Nov 13, 2008 at 02:55:06PM +0100, Leon Timmermans wrote:
> On Thu, Nov 13, 2008 at 2:24 PM, TSa <[EMAIL PROTECTED]> wrote:
> > Pm wrote:
> > > Presumably the values of a one() junction do not collapse in
> > > this way, otherwise we could easily lose the fact that
> > > a value occurs more
HaloO,
Leon Timmermans wrote:
Still that doesn't solve the problem of his code example. If my
understanding of the synopses is correct, operations on junctions
generate a new junction, so `one(1,2,3) % 2 == 1` will collapse to
one(1 % 2 == 1, 2 % 2 == 1, 3 % 2 == 1), which is one(true, false,
tr
On Thu, Nov 13, 2008 at 2:24 PM, TSa <[EMAIL PROTECTED]> wrote:
> Do I understand your question right, that you want the return
> of == to be false because there is a one(1,0,1) junction? As
> Duncan points out junctions are immutable values and as such
> the % autothreads but the resulting values
HaloO,
Patrick R. Michaud wrote:
Presumably the values of a one() junction do not collapse in
this way, otherwise we could easily lose the fact that
a value occurs more than once:
my $a = (one(1,2,3) % 2 == 1);
Do I understand your question right, that you want the return
of == to be fals
> According to Synopsis 2, under "Immutable types", a Junction is a "Set with
> additional behaviors". This implies to me a Junction consists just of
> distinct unordered values. A Junction is not a Bag and it doesn't matter
> that we lose the fact that a value occurred more than once in the argu
Patrick R. Michaud wrote:
Are duplicate values in any/all/none junctions expected to "collapse"
such that each value becomes unique? For example, should
any(1,2,2,1,2,3,2) internally reduce to the equivalent of
any(1, 2, 3)? Or is this something that is left to individual
implementations to d
Are duplicate values in any/all/none junctions expected to "collapse"
such that each value becomes unique? For example, should
any(1,2,2,1,2,3,2) internally reduce to the equivalent of
any(1, 2, 3)? Or is this something that is left to individual
implementations to decide?
Presumably the values
18 matches
Mail list logo
