Collapsing Junction states?
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 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); Comments and/or pointers to relevant specifications that I've missed are welcomed. Thanks! Pm
Re: Collapsing Junction states?
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 decide? 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); Comments and/or pointers to relevant specifications that I've missed are welcomed. 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 arguments of the Junction constructor. Whether values are considered identical or not and get eliminated depends on what their .WHERE returns. Whether a Perl 6 implementation internally reduces the constructor value list doesn't matter as long as the semantics of using the Junction are as if it had; so eg that reduction could be done lazily, just when the Junction is first used. -- Darren Duncan
Re: Collapsing Junction states?
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 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 are assembled into a new junction according to the general rules, i.e. one(0,1). The number of elements in one(1,2,3) is not preserved. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Collapsing Junction states?
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 are assembled into > a new junction according to the general rules, i.e. one(0,1). > The number of elements in one(1,2,3) is not preserved. > 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. Regards,
Re: Collapsing Junction states?
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, true). If it collapses, it will be one(true, false), and thus true, but if it doesn't collapse it will be false. Hmm? The auto-threading is one operator at a time not the '% 2 == 1' as a whole. The intermediate junctions are assembled according to the general rule that duplicates are removed. Thus the steps here are 1) one(1,2,3) % 2 --> one(1,0,1) --> one(1,0) 2) one(1,0) == 1 --> True The comparison collapses the junction. Boolean context collapses junctions as well because you can think of it as comparison to True. That is, there is an overload &infix:<==>(Junction,Num-->Bool) that is not auto-threaded. BTW, would it be useful to have auto-threading for Set as well? That is, Junction inherits it from Set. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Collapsing Junction states?
> 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 arguments > of the Junction constructor. Whether values are considered identical or not > and get eliminated depends on what their .WHERE returns. Whether a Perl 6 > implementation internally reduces the constructor value list doesn't matter > as long as the semantics of using the Junction are as if it had; so eg that > reduction could be done lazily, just when the Junction is first used. -- > 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, true). If it collapses, it will be one(true, false), and thus true, but if it doesn't collapse it will be false. Either I'm missing something, or the behavior of `one' needs to be specified more thoroughly. I think I agree with Patrick that collapse needs to be delayed there. Regards, Leon
Re: Collapsing Junction states?
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 than once: > > > > > > my $a = (one(1,2,3) % 2 == 1); > > > > Do I understand your question right, that you want the return > > of == to be false because there is a one(1,0,1) junction? 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 $a = one(1,2,3) % 2 == 1; --> my $a = one(1%2, 2%2, 3%2) == 1; --> my $a = one(1%2 == 1, 2%2 == 1, 3%2 == 1); --> my $a = one( True, False, True ); > > As Duncan points out junctions are immutable values and as such > > the % autothreads but the resulting values are assembled into > > a new junction according to the general rules, i.e. one(0,1). > > The number of elements in one(1,2,3) is not preserved. > > 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. I agree that one() with collapsing values isn't dwimmy (or useful), which is part of the reason for my original message. Pm
Re: Collapsing Junction states?
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 accomplished by not putting it in at all, as well. So the unification step of a one() junction drops duplicates completely? I see your point because the uniqueness test all(@array) == one(@array) always returns true if the junctions are unified before the comparison takes place. So the only way out is to make the definition that a one() junction drops duplicates completely. My personal favorite use of one() junctions would be in types. A Dog^Cat is either a Dog or a Cat but never something that does a combined role. But we don't have that in the language. Instead we have Dog|Cat and the juxtaposition Dog Cat. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Collapsing Junction states?
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 = one(1%2, 2%2, 3%2) == 1; --> my $a = one(1,0,1) == 1; --> my $a = one(0) == 1; --> my $a = one(1%2 == 1, 2%2 == 1, 3%2 == 1); --> my $a = one(0 == 1) --> my $a = one( True, False, True ); --> my $a = one(False); I agree that one() with collapsing values isn't dwimmy (or useful), which is part of the reason for my original message. I agree as well, but make a different proposal how to resolve it. BTW, how does an empty junction work? That could happen not only with one() but also through one(1,2,1,2) in my proposal. So one() is just another way of writing False ;) Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Are eqv and === junction aware?
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.WHAT is Int and any(1,2,3).WHAT is Junction. Or are my expectations wrong? Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: More about arrayref/hashref in spectest suite
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'). But is the first assignment parsed as an item assignment or a list assignment? If it is parsed as an item assignment, how does the parser recognize it as such? Couldn't the distinction be made in the type analysis phase? Something similar how it would be resolved at runtime if &postcircumfix:<[ ]>:(Int) and &postcircumfix:<[ ]>:(List of Int) returned different types. E.g. ArrayItem and ArraySlice. Then the assignment operator could distinguish the cases. With enough type information the compiler could do the same analysis. Without it the issue is left up to the runtime dispatcher. Both dispatch targets treat the rhs different, of course. The ArrayItem case builds an arrayref, the ArraySlice assigns the elements with flattened @x. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Collapsing Junction states?
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() junctions. > >> my $a = one(1,2,3) % 2 == 1; >>--> my $a = one(1%2, 2%2, 3%2) == 1; > > --> my $a = one(1,0,1) == 1; > --> my $a = one(0) == 1; > >>--> my $a = one(1%2 == 1, 2%2 == 1, 3%2 == 1); > > --> my $a = one(0 == 1) > >>--> my $a = one( True, False, True ); > > --> my $a = one(False); > >> I agree that one() with collapsing values isn't dwimmy (or useful), >> which is part of the reason for my original message. > > I agree as well, but make a different proposal how to resolve it. > BTW, how does an empty junction work? That could happen not only > with one() but also through one(1,2,1,2) in my proposal. So one() > is just another way of writing False ;) It seems simpler to say that one() produces bags rather than sets. Larry
Re: Are eqv and === junction aware?
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 > > which is False. OTOH, > >2 === any(1,2,3) > > should be False because 2.WHAT is Int and any(1,2,3).WHAT is > Junction. Or are my expectations wrong? 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 it canonicalizes the output order. Larry
Re: Collapsing Junction states?
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. > > > > My proposal is a different unification behavior in one() junctions. > > > >> my $a = one(1,2,3) % 2 == 1; > >>--> my $a = one(1%2, 2%2, 3%2) == 1; > > --> my $a = one(1,0,1) == 1; > > --> my $a = one(0) == 1; > > --> my $a = one(0 == 1) > > --> my $a = one(False); I think your proposal (C drops duplicates) might have trouble with: my $a = (one(15, 25, 22, 21) % 10) % 2; Dropping duplicates, we get: --> my $a = one(15%10, 25%10, 22%10, 21%10) % 2; --> my $a = one(5, 5, 2, 1) % 2; --> my $a = one(2, 1) % 2; # omit duplicate 5 --> my $a = one(2%2, 2%1); --> my $a = one(0, 1); Preserving duplicates, we get: my $a = (one(15, 25, 22, 21) % 10) % 2; --> my $a = one(15%10, 25%10, 22%10, 21%10) % 2; --> my $a = one(5, 5, 2, 1) % 2; --> my $a = one(5%2, 5%2, 2%2, 1%2); --> my $a = one(1, 1, 0, 1); Note that ?$a would end up being True if we drop duplicates (top) but False if we preserve them (bottom). > It seems simpler to say that one() produces bags rather than sets. I agree, so Rakudo will go with that for now. Thanks! Pm
MAIN conflict in S06?
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 that section describes MAIN subroutines that are lexically nested within the mainline code of the outermost file-scoped compilation unit, and it seems a little confusing if both are called MAIN. I'm guessing that the statement at S06:2362 is an artifact of an earlier draft that didn't have the section on MAIN subroutines, but I'm wanting to verify that this is the case (or seek further clarification if it isn't). Thanks! Pm
Re: Collapsing Junction states?
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 maybe that's fine. Or alternately, why not just redefine a Junction for consistency to say it is a "Bag with additional behaviors" rather than a "Set with additional behaviors"? Would doing this break anything? Do any intended uses of a Junction specifically versus a plain Set|Bag involve asking how many instances of a value there are, or asking how many distinct values or value instances are in the Junction? Aside from the 3 answers: exactly none, exactly one, one or more? What I was originally going to suggest but Tsa suggested first: Keep the definition of a Junction as "Set with additional behaviors" but the one() constructor just excludes values that appear multiple times in its argument list. In other words, one() *is* the same as any() except for the added filter. -- Darren Duncan
Re: Collapsing Junction states?
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 constructed it. Now maybe that's fine. Or alternately, why not just redefine a Junction for consistency to say it is a "Bag with additional behaviors" rather than a "Set with additional behaviors"? Would doing this break anything? Do any intended uses of a Junction specifically versus a plain Set|Bag involve asking how many instances of a value there are, or asking how many distinct values or value instances are in the Junction? Aside from the 3 answers: exactly none, exactly one, one or more? The meaning of any() and all() do not change if the collection is allowed to be a Bag instead of a Set. There are two reasonable meanings for one(), either duplicates collapse done to single members of the collection or duplicates cancel (or are ignored, same thing). The later interpretation would mean that one(1,2,3,3) is the same as one(1,2), but constants aren't the interesting case, one(@a) is. I suppose we could define a :uniq(true|false) adverb to modify the meaning of one() so we could have both interpretations. Mark Biggar
Re: Are eqv and === junction aware?
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 > it canonicalizes the output order. Perhaps there should be a way of disabling the autothreading? Something similar to the way that Lisp can take a block of code and tag it as "do not execute at this time". The idea is that there may be some cases where one might want to look at a Junction as an object in and of itself, rather than as a superposition of other objects; and simply extracting its contents into a list or set won't always do, since it might be Junction-specific details at which you want to look. And as long as Junctions autothread by default, I don't see them losing any power. -- Jonathan "Dataweaver" Lang
