Re: a junction or not
On 3/15/09 11:19 AM, Richard Hainsworth wrote: The following (the n: is to mark the lines) are legal: 1: my @x = 1,2,3,4; ([+] @x).say; # output 10 2: my @x = 1|11,2,3,4; ([+] @a).perl.say; # output any(10,20) 3: my @x = 1|11,2,3,4; ([+] @a).eigenstates.min.say; # output 10 However, the next line isnt 4: my @x = 1,2,3,4; ([+] @a).eigenstates.min.say; # Method 'eigenstates' not found for invocant of class 'Integer' [...] I've been pondering and experimenting with this. Now that the Object.eigenstates patch is in, all of the above cases do it indeed work. But what if you have more than one ace in your hand? 5: my @x = 1|11, 1|11, 10; ([+] @x).eigenstates.min.say Junction0x7f89311bca30 Not so useful. 6: my @x = 1|11, 1|11, 10; ([+] @x).perl.say any(any(12, 22), any(22, 32)) A junction of junctions. And three aces? 7: my @x = 1|11, 1|11, 1|11, 10; ([+] @x).perl.say any(any(any(13, 23), any(23, 33)), any(any(23, 33), any(33, 43))) Yikes! Is there a way of flattening such a beast into any(13, 23, 33, 43) ? Does a deeply nested Junction have any practical value that the flattened one does not? At any rate, it behaves much the same as a flattened version would when matched against: 8: my @x = 1|11, 1|11, 1|11, 10; ([+] @x) == 23 say Match! Match! And so, the solution almost presents itself: 9: my @x = 1|11, 1|11, 1|11, 10; say ([+] @x) ~~ 1..21 ?? OK !! Bust! OK 10: my @x = 1|11, 1|11, 1|11, 10, 9; say ([+] @x) ~~ 1..21 ?? OK !! Bust! Bust! And of course, that would have worked before the patch. Oh, and ++ for coming up with such a cool use for junctions in the first place! Bruce
Re: a junction or not
HaloO,
On Tuesday, 17. March 2009 10:25:27 David Green wrote:
That is, it would return a Junction of Str, not a Str. So the
question is how to get something that returns an expression to the
effect of:
'any(' ~ $choice.eigenstates.«perl.join(',') ~ ')'
say $choice.perl
...which will ultimately call (junction-of-.perl's).Str, and
Str(Junction:) is what produces the any(XXX) string. [Unless it
ends up being implemented some other way, of course!]
Note that this contradicts Larry's statement that .perl
autothreads. I think it can't autothread because we expect
it to put the junction constructor in front of the values
or the right operator as infix. So .perl is junction aware!
But it threads the .perl method through the eigenstates,
of course.
The other question is: given $choice as defined above, how do I find
out which type of junction it is?
I guess really Junctions need two public methods: .eigenstates for the
values, and, er, .eigenop(?!) to return how they're joined -- I'm
thinking it would return a code ref, i.e. any, all, etc.
A simple solution is to have subtypes of Junction like AnyJunction,
AllJunction, OneJunction and NoneJunction or perhaps like Junction::Any,
Junction::All, Junction::One and Junction::None.
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: a junction or not
Larry Wall wrote: I think I've mentioned before that .perl autothreads. It's the final (low-level) stringification of a junction that slaps the appropriate quantifier around that, I suspect. Please bear with me; I'm starting to get a little lost: are you telling me that $j.perl does what I'd expect of an indeterminate item, and that the trick is in getting a perlization of the Junction itself? If so, cool. So maybe $j.Str returns the eigenstring, while prefix:~ autothreads. Or maybe there's a method named .eigenstring or some such for use by print and say and anyone else who absolutely must end up with something printable. Or maybe there's a method that returns a frozen reference that masquerades as the Junction, but doesn't trigger autothreading. Or would that be opening up an infinitely regressing can of worms? I don't know; I've got this gut feeling that something's off here, but I can't quite put my finger on what it is. Although, maybe I can. As written (I believe), .perl generates a String representation of whatever code is needed to build the object that called it. However, there may come a point somewhere down the road where you'll want .perl to instead return a parse-tree of that code, with the ability to stringify appropriately. If you've written a separate .eigenstring function to perform the same purpose with Junctions, or you've set it up so that prefix:~ autothreads while Junction.Str returns the eigenstring, that will potentially be two functions that will need to be rewritten. More generally, a programmer who writes a function that operates on an Object (and thus autothreads when given a Junction) will be forced to decide between writing a second Junction-aware version if he wants to treat the Junction as a Junction instead of autothreaded Objects, or not bothering and thus not allowing the function to manipulate a Junction directly. In short, you have to reinvent the wheel every time the to Junction or not to Junction question arises. Providing a means to momentarily disable a Junction's autothreading properties would, in one fell swoop, solve every instance of this problem. At least, I think it would. If it wouldn't, it would at least solve a large swath of them. -- Jonathan Dataweaver Lang
Re: a junction or not
Jon Lang wrote:
Darren Duncan wrote:
Jon Lang wrote:
Larry Wall wrote:
This is basically a non-problem. Junctions have one public method,
.eigenstates, which is vanishingly unlikely to be used by accident by
any mere mortal any time in the next 100 years, give or take a year.
If someone does happen to be programming quantum mechanics in Perl 6,
they're probably smart enough to work around the presence of a
reserved--well, it's not even a reserved word-- a reserved method name.
Actually, the problem isn't with '.eigenstates'; the problem is with
'.perl'. If I'm viewing a Junction of items as a single indeterminate
item, I'd expect $J.perl to return a Junction of the items' perl by
default. Admittedly though, even that isn't much of an issue, seeing
as how you _can_ get that result by saying something to the effect of
Junction of $J.eigenstates.«perl - the only tricky part being how to
decide which kind of junction to use (e.g., any, all, one, none) when
putting the perl-ized eigenstates back together. (And how _would_ you
do that?) This would represent another corner-case where the
programmer would be tripped up by a simplistic understanding of what a
Junction is; but being a corner-case, that's probably acceptable.
I would assume that invoking .perl on a Junction would result in Perl code
consisting of the appropriate any/all/etc expression. -- Darren Duncan
Tough to parse, though; and feels like a kludge. I expect better of Perl 6.
What do you mean by tough to parse and feels like a kludge? Isn't the point
of .perl that it results in a string of Perl 6 code that is a Perl 6 value
expression? I wouldn't expect that a Perl 6 expression to result in a Junction
is any more difficult to parse than the source code returning an Array or some such.
For example, if you have:
my $choice = any(1..10);
Then $choice.perl should result in code like any(1..10). Or $choice.perl
would approximately be short for the expression:
'any('~($choice.eigenstates.map:{ $_.perl }.join(','))~')'
... except that the .perl of $choice would also be smart enough to pick
'any'/'all'/etc based on what its Junction value actually is.
Such as that seems perfectly elegant and uncomplicated to me.
If you had a problem with that, then I would expect you'd have a problem with
.perl in general for any value, particularly Array etc values.
-- Darren Duncan
Re: a junction or not
Darren Duncan wrote:
Jon Lang wrote:
Darren Duncan wrote:
I would assume that invoking .perl on a Junction would result in Perl
code
consisting of the appropriate any/all/etc expression. -- Darren Duncan
Tough to parse, though; and feels like a kludge. I expect better of Perl
6.
What do you mean by tough to parse and feels like a kludge?
If I'm understanding Larry correctly, then given:
my $choice = any(1..10);
$choice.perl will return the same thing that the following would:
any($choice.eigenstates.«perl)
That is, it would return a Junction of Str, not a Str. So the
question is how to get something that returns an expression to the
effect of:
'any(' ~ $choice.eigenstates.«perl.join(',') ~ ')'
Or, if I'm reading Larry incorrectly and $choice.perl provides the
latter, how do you get the former (without knowing ahead of time that
$choice is an any-junction)?
--
The other question is: given $choice as defined above, how do I find
out which type of junction it is? Do I somehow call something that
would produce the latter string, and then extract the first word from
it? Or is there a more direct way to find out which kind of Junction
you're dealing with?
--
Jonathan Dataweaver Lang
Re: a junction or not
On 2009-Mar-17, at 2:16 am, Jon Lang wrote:
$choice.perl will return the same thing that the following would:
any($choice.eigenstates.«perl)
That is, it would return a Junction of Str, not a Str. So the
question is how to get something that returns an expression to the
effect of:
'any(' ~ $choice.eigenstates.«perl.join(',') ~ ')'
say $choice.perl
...which will ultimately call (junction-of-.perl's).Str, and
Str(Junction:) is what produces the any(XXX) string. [Unless it
ends up being implemented some other way, of course!]
The other question is: given $choice as defined above, how do I find
out which type of junction it is?
I guess really Junctions need two public methods: .eigenstates for the
values, and, er, .eigenop(?!) to return how they're joined -- I'm
thinking it would return a code ref, i.e. any, all, etc.
-David
Re: a junction or not
On Mar 15, 12:57 pm, datawea...@gmail.com (Jon Lang) wrote: The problem that Richard just identified is that Junctions don't fully manage to hide themselves when it comes to their method calls. [...] I'm thinking that maybe Junction shouldn't be a type. Instead, it should be a meta-type, in (very rough) analogy to the concept of the meta-operator. In particular, Junction bears a certain resemblance to the hyper-operator. A couple of months ago I started a thread rfc: The values of a junction where I suggested that a solution tot he problem was to add a grep meta-operator that would enable an operator-based collapse of junctions. My suggested syntax from that thread was: my @values = 0..21 |==| $junc_value; Or my @values = Int |==| $junc_value; The idea was to match the range against the (possibly) junctional value, but return the set of matching values rather than just a True/ False comparison (Any binary operator that returns something boolean- like would be usable in the |op| meta chars. Given changes to meta- ops since then, perhaps my @values = 0..21 G== $junc_value would be more consistent. The advantage of using an operator over the existing grep method is that it could reasonable be expected to handle infinite ranges (and infinite junctions) analytically (in finite time). The advantage of using the operator over the eigenstates method is that it doesn't assume any knowledge pf the nature of the junction: all, any, one, none -- the operator would do the right thing without any additional user-introspection.
Re: a junction or not
Sigh. The current design of Junctions is quite extensible *because* it is based on a real type. You can easily write operators that work only on Junctions, just as you can easily write operators that are transparent to Junctions or autothread on Junctions by declaring their arguments to take Object or Any, respectively. That being said, the reason Junctions are there in Perl 6 is primarily *linguistic* rather than mathematical; Perl 6 has a Set type because we've had this argument already. Anyone who extends Junctions to try to do some kind of set theory is on the road to Perdition, or at least the road to Brain Pretzels Without End, amen. In my opinion. :-) Larry
Re: a junction or not
Larry Wall wrote: Sigh. The current design of Junctions is quite extensible *because* it is based on a real type. You can easily write operators that work only on Junctions, just as you can easily write operators that are transparent to Junctions or autothread on Junctions by declaring their arguments to take Object or Any, respectively. Right; that was the solution to which I was referring. That being said, the reason Junctions are there in Perl 6 is primarily *linguistic* rather than mathematical; Perl 6 has a Set type because we've had this argument already. Anyone who extends Junctions to try to do some kind of set theory is on the road to Perdition, or at least the road to Brain Pretzels Without End, amen. Agreed. My own concern has nothing to do with set theory; it's in making sure that there's an easy way to distinguish between method calls that are supposed to be fielded by the Junction itself (e.g., give me perl for the Junction) and method calls that are supposed to be fielded by the Junction's eigenstates (e.g., give me a Junction of perls for the eigenstates of this Junction) - bearing in mind that the Junction _does_ try to stay out of the way and pretend to be (a superposition of) its individual eigenstates as much as possible. _That's_ why I suggested pushing its methods into HOW: not to make it not a type, but rather to ensure that its method calls will never clobber (or be clobbered by) the method calls of its eigenstates. This allows the programmer to continue to think of 1 | 2 as an item, although I'm not sure which one most of the time, and only as a Junction when it is convenient to do so (i.e., by making his intent explicit). The business of referring to it as a meta-type was perhaps an unfortunate digression from my main point; but I mentioned it to justify why I would feel comfortable with allowing Junction to put things in HOW: not only the practical reason that you wouldn't need to present _another_ HOW-like collection of methods to keep the Junction's stuff out of the way, but also because Junction _is_ a strange creature in that it's a collection of items that can usually be treated as a single (indeterminate) item - and this would highlight this fact to the programmer, perhaps making the task of understanding the Junction easier by providing an analogy to another language feature that has similar properties (i.e., meta-operators). Admittedly though, this latter reason takes a back seat to the practicalities. Bottom line, the goal is to keep Junction's methods from conflicting with its members' methods. -- Jonathan Dataweaver Lang
Re: a junction or not
This is basically a non-problem. Junctions have one public method, .eigenstates, which is vanishingly unlikely to be used by accident by any mere mortal any time in the next 100 years, give or take a year. If someone does happen to be programming quantum mechanics in Perl 6, they're probably smart enough to work around the presence of a reserved--well, it's not even a reserved word-- a reserved method name. If it would make people happier, I suppose we could change it to something like .EIGENSTATES instead. Larry
Re: a junction or not
Larry Wall wrote: This is basically a non-problem. Junctions have one public method, .eigenstates, which is vanishingly unlikely to be used by accident by any mere mortal any time in the next 100 years, give or take a year. If someone does happen to be programming quantum mechanics in Perl 6, they're probably smart enough to work around the presence of a reserved--well, it's not even a reserved word-- a reserved method name. Actually, the problem isn't with '.eigenstates'; the problem is with '.perl'. If I'm viewing a Junction of items as a single indeterminate item, I'd expect $J.perl to return a Junction of the items' perl by default. Admittedly though, even that isn't much of an issue, seeing as how you _can_ get that result by saying something to the effect of Junction of $J.eigenstates.«perl - the only tricky part being how to decide which kind of junction to use (e.g., any, all, one, none) when putting the perl-ized eigenstates back together. (And how _would_ you do that?) This would represent another corner-case where the programmer would be tripped up by a simplistic understanding of what a Junction is; but being a corner-case, that's probably acceptable. -- Jonathan Dataweaver Lang
Re: a junction or not
Jon Lang wrote: Larry Wall wrote: This is basically a non-problem. Junctions have one public method, .eigenstates, which is vanishingly unlikely to be used by accident by any mere mortal any time in the next 100 years, give or take a year. If someone does happen to be programming quantum mechanics in Perl 6, they're probably smart enough to work around the presence of a reserved--well, it's not even a reserved word-- a reserved method name. Actually, the problem isn't with '.eigenstates'; the problem is with '.perl'. If I'm viewing a Junction of items as a single indeterminate item, I'd expect $J.perl to return a Junction of the items' perl by default. Admittedly though, even that isn't much of an issue, seeing as how you _can_ get that result by saying something to the effect of Junction of $J.eigenstates.«perl - the only tricky part being how to decide which kind of junction to use (e.g., any, all, one, none) when putting the perl-ized eigenstates back together. (And how _would_ you do that?) This would represent another corner-case where the programmer would be tripped up by a simplistic understanding of what a Junction is; but being a corner-case, that's probably acceptable. I would assume that invoking .perl on a Junction would result in Perl code consisting of the appropriate any/all/etc expression. -- Darren Duncan
Re: a junction or not
Darren Duncan wrote: Jon Lang wrote: Larry Wall wrote: This is basically a non-problem. Junctions have one public method, .eigenstates, which is vanishingly unlikely to be used by accident by any mere mortal any time in the next 100 years, give or take a year. If someone does happen to be programming quantum mechanics in Perl 6, they're probably smart enough to work around the presence of a reserved--well, it's not even a reserved word-- a reserved method name. Actually, the problem isn't with '.eigenstates'; the problem is with '.perl'. If I'm viewing a Junction of items as a single indeterminate item, I'd expect $J.perl to return a Junction of the items' perl by default. Admittedly though, even that isn't much of an issue, seeing as how you _can_ get that result by saying something to the effect of Junction of $J.eigenstates.«perl - the only tricky part being how to decide which kind of junction to use (e.g., any, all, one, none) when putting the perl-ized eigenstates back together. (And how _would_ you do that?) This would represent another corner-case where the programmer would be tripped up by a simplistic understanding of what a Junction is; but being a corner-case, that's probably acceptable. I would assume that invoking .perl on a Junction would result in Perl code consisting of the appropriate any/all/etc expression. -- Darren Duncan Tough to parse, though; and feels like a kludge. I expect better of Perl 6. -- Jonathan Dataweaver Lang
Re: a junction or not
On Mon, Mar 16, 2009 at 09:24:58PM -0700, Jon Lang wrote: : Darren Duncan wrote: : Jon Lang wrote: : Larry Wall wrote: : This is basically a non-problem. Junctions have one public method, : .eigenstates, which is vanishingly unlikely to be used by accident by : any mere mortal any time in the next 100 years, give or take a year. : If someone does happen to be programming quantum mechanics in Perl 6, : they're probably smart enough to work around the presence of a : reserved--well, it's not even a reserved word-- a reserved method name. : : Actually, the problem isn't with '.eigenstates'; the problem is with : '.perl'. If I'm viewing a Junction of items as a single indeterminate : item, I'd expect $J.perl to return a Junction of the items' perl by : default. Admittedly though, even that isn't much of an issue, seeing : as how you _can_ get that result by saying something to the effect of : Junction of $J.eigenstates.«perl - the only tricky part being how to : decide which kind of junction to use (e.g., any, all, one, none) when : putting the perl-ized eigenstates back together. (And how _would_ you : do that?) This would represent another corner-case where the : programmer would be tripped up by a simplistic understanding of what a : Junction is; but being a corner-case, that's probably acceptable. : : I would assume that invoking .perl on a Junction would result in Perl code : consisting of the appropriate any/all/etc expression. -- Darren Duncan : : Tough to parse, though; and feels like a kludge. I expect better of Perl 6. I think I've mentioned before that .perl autothreads. It's the final (low-level) stringification of a junction that slaps the appropriate quantifier around that, I suspect. So maybe $j.Str returns the eigenstring, while prefix:~ autothreads. Or maybe there's a method named .eigenstring or some such for use by print and say and anyone else who absolutely must end up with something printable. Larry
Re: a junction or not
Richard Hainsworth wrote:
The following (the n: is to mark the lines) are legal:
1: my @x = 1,2,3,4; ([+] @x).say; # output 10
2: my @x = 1|11,2,3,4; ([+] @a).perl.say; # output any(10,20)
3: my @x = 1|11,2,3,4; ([+] @a).eigenstates.min.say; # output 10
However, the next line isnt
4: my @x = 1,2,3,4; ([+] @a).eigenstates.min.say; # Method
'eigenstates' not found for invocant of class 'Integer'
But suppose I dont know until runtime whether @x contains a junction
or not, eg.,
my @s = 1|11,2,3,4,5,6,7; # as in the value of an ace in 21
my @x;
loop {
@x = @s.pick(3);
([+] @x).eigenstates.min.say;
};
Eg.
$ perl6
my @s=1|11,2,3,4,5,6;my @x; loop {...@x=@s.pick(3);([+]
@x).eigenstates.min.say}
8
6
Method 'eigenstates' not found for invocant of class 'Integer'
I suggested to Masak on irc that an integer is a singleton, hence a
degenerate Junction. He said not.
So, how to determine whether a junction is being used or not?
You can detect junctions by smart-matching against the Junction type
(e.g. $sum ~~ Junction).
my @s=1|11,2,3,4,5,6;
loop {
my $sum = [+] @s.pick(3);
say $sum ~~ Junction ?? $sum.eigenstates.min !! $sum;
}
Jonathan
Re: a junction or not
Jonathan Worthington wrote:
Richard Hainsworth wrote:
snip
Eg.
$ perl6
my @s=1|11,2,3,4,5,6;my @x; loop {...@x=@s.pick(3);([+]
@x).eigenstates.min.say}
8
6
Method 'eigenstates' not found for invocant of class 'Integer'
You can detect junctions by smart-matching against the Junction type
(e.g. $sum ~~ Junction).
my @s=1|11,2,3,4,5,6;
loop {
my $sum = [+] @s.pick(3);
say $sum ~~ Junction ?? $sum.eigenstates.min !! $sum;
}
Jonathan
Except it doesnt work :(
$ perl6
my %h=a b c Z 1|11,2,3;%h.perl.say
{a = any(1, 11), b = 2, c = 3}
my %h=a b c Z 1|11,2,3;my $s = [+] values %h;$s.perl.say
any(6, 16)
my %h=a b c Z 1|11,2,3;my $s = [+] values %h;say $s~~Junction ??
$s.eigenstates.min !! $s
Null PMC access in get_integer()
Re: a junction or not
This isn't the first (or second, or third, or fourth...) time that I've seen complications arise with regard to junctions. Every time, the confusion arises when some variation of the question is it a junction? is raised. Ultimately, this is because Perl is trying it's darnedest to treat Junctions as their members; this is something that it doesn't try anywhere else, leading to a counterintuitive approach. The other big example of this phenomenon that I've seen has to do with passing parameters into a routine: Should the code auto-parallelize, executing the code separately for each value in the junction, or should it execute only once, passing the parallelization buck on to whatever routines it happens to call? That is, should parallelization be eager or lazy? (I'm pretty sure that this was resolved, although I'm not recalling how.) The problem that Richard just identified is that Junctions don't fully manage to hide themselves when it comes to their method calls. Let's say that I'm writing a role that deals with quantum mechanics (say, Quantum), and for whatever reason I decide that I need an eigenstate method. Now we've got a problem: if I ever find myself dealing with a Junction that has at least one Quantum among its eigenstates, what happens when I call the .eigenstates method? I'm betting that I'll get Junction.eigenstates, rather than a Junction of Quantum.eigenstates. In fact, I see no easy way to get the latter. I'm thinking that maybe Junction shouldn't be a type. Instead, it should be a meta-type, in (very rough) analogy to the concept of the meta-operator. In particular, Junction bears a certain resemblance to the hyper-operator. Thus far, it's the only meta-type; and, like meta-operators, additional meta-types should be added sparingly. As I see it, the difference between a type and a meta-type is that all of the meta-type's methods are accessed via HOW. You wouldn't say $x.eigenstates to access a Junction's eigenstates; you'd say $x.^eigenstates for that. (Further speculation: maybe there's a meta-type that defines the default HOW methods.) That still doesn't solve the problem that Richard first raised, though. To do that, I'm thinking that his original suggestion should also be implemented: in the same way that an item can be treated as a one-item list for the purposes of list context (and vice versa), a non-Junction should be able to be treated as a Junction with a single eigenstate (i.e., a Singleton) for the purposes of junctive semantics. That is, $x.^eigenstates === ($x) if $x is not a junction. Not only does this reduce the need to test for junctions, but it also makes that test fairly straightforward: count the eigenstates. If you only have one, it isn't a junction. (Further speculation: perhaps undefined values have _no_ eigenstates...) -- Jonathan Lang
Re: a junction or not
On Sun, Mar 15, 2009 at 07:26:00PM +0100, Jonathan Worthington wrote:
You can detect junctions by smart-matching against the Junction type
(e.g. $sum ~~ Junction).
my @s=1|11,2,3,4,5,6;
loop {
my $sum = [+] @s.pick(3);
say $sum ~~ Junction ?? $sum.eigenstates.min !! $sum;
}
I see no particular reason not to add an .eigenstates method to Object
that returns a list of the object itself . It doesn't interfere with
the .eigenstates method defined in Junction, unless you want to
determine whether something is a Junction by seeing if it can respond
to .eigenstates, which seems wrongish.
Larry
Re: Collapsing Junction states?
The cancellation behavior makes no sense to me. I expect ?one(0, 1, 2, 2) to return false. That happens whether or not it collapses the 2's to one 2, but not if it ignores/cancels them. The question is, what should ?one(0, 1, 1) return? I think it's pretty clearly false, which implies that junctions created by one() should not collapse duplicates. So we have a demonstrated desire for baglike junctions; I haven't seen a compelling need for setlike ones, but I could easily be missing something there. IOW, I tentatively agree with the proposal to just make all junctions baglike. On 11/14/08, Mark Biggar [EMAIL PROTECTED] wrote: 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 -- Sent from Gmail for mobile | mobile.google.com Mark J. Reed [EMAIL PROTECTED]
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
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: 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: use junction
On Mon, Apr 25, 2005 at 08:33:06PM +0200, Juerd wrote:
: I think it would be great to be able to use a junction with use:
:
: use strict warnings;
:
: A disjunction could mean any of the listed modules suffices. This comes
: in handy when you code something that will work with any of three XML
: parsers. Although because ordering matters, the // operator is perhaps
: better.
:
: But use strict warnigs; looks great and I wonder if it can work.
Well, there's a bit of a syntactic problem with anywhere a term
might be expected after a term, since it will assume you want to
start a foo. For another example
sub foo (IntStr block) {...}
is probably not going to parse right. Maybe that's a good place for
sub foo (:(IntStr) block) {...}
Alternately, we install a small heuristic and document it in the fine print.
By and large, we've managed to avoid such heuristics in Perl 6, but maybe
this is a good spot for an evil heuristic.
The use ambiguity might easily be resolved by saying that use
always parses using indirect object syntax, which would distinguish
use strict warnings;
from
use strict: warnings;
(Note: such a colon could possibly be used to distinguish Perl 6 from
Perl 5 in Main too, at least if the first use needs a colon.)
I don't know of any easy fix for the type var ambiguity though.
However, all that being said, please note that
use strict warnings: @args;
is unlikely to be useful unless the two modules have a similar
interface. It'd be much more useful to be able to logically cascade
use statements as a whole.
Larry
Re: use junction
Larry Wall skribis 2005-05-03 6:22 (-0700):
sub foo (IntStr block) {...}
sub foo (:(IntStr) block) {...}
Alternately, we install a small heuristic and document it in the fine print.
I personally would not mind requiring whitespace around in those
cases.
If parens are used for the grouping, then why is the colon required?
The use ambiguity might easily be resolved by saying that use
always parses using indirect object syntax, which would distinguish
use strict warnings;
from
use strict: warnings;
I thought whitespace after the sigil was no longer allowed? That
certainly fits in the sigil-is-part-of-the-name-thing.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: use junction
Juerd wrote: I personally would not mind requiring whitespace around in those cases. Same here. Actually the whitespace after makes the destinction, or not? If parens are used for the grouping, then why is the colon required? Because it escapes into type-space like ::() escapes into name-space :) -- TSa (Thomas Sandlaß)
Re: Malfunction Junction, what's your function?
I wrote:
permute( @x_chars ) »{ $^a eq $^b ?? $^a :: ''}« permute( @y_chars )
Permutation is the wrong thing here, sorry. It's just:
( @x_chars »xx« @y_chars.elems ) # or was that .size?
»{ $^a eq $^b ?? $^a :: ''}«
( @y_chars xx @x_chars.elems ) # note: no hypering
e.g. a b c and x y give a a b b c c »{...}« x y x y x y
and finally a list of six empty strings.
And look Mami, all without junctions!
Lots of french ... ehm, freedom quotes involved, though :)
--
TSa (Thomas Sandlaß)
Re: Malfunction Junction, what's your function?
On 4/28/05, Thomas Sandlaß [EMAIL PROTECTED] wrote:
I wrote:
permute( @x_chars ) »{ $^a eq $^b ?? $^a :: ''}« permute( @y_chars )
Permutation is the wrong thing here, sorry. It's just:
I want to preface again that I have only recently started giving the
language aspect of p6 serious focus. Without doing any digging into
junctions and pretty much just listening to the buzz, I not only think
of things like being able to verify that a userid isn't on a
blacklist, I also think of the ability to do things like:
1. Give me all the items in list A that match any of the items in list B
2. Give me all the items in list A that aren't in list B
3. well - you get the idea
I don't want to have to invent some special purpose infix operation to
do it nor should do I believe it should require much thinking. That
doesn't mean it needs to be in the core. If not in the core, I think
it should be generalized and included in one of the first available
modules. FAQs such as union, difference, intersection of lists are
FAQs for a reason.
Of course, it is real easy for me to say it should 'just work' from
where I am sitting - you all are the ones that have done the hard
work. Having answered the questions enough times in p5 circles
though, it would be nice to have a real simple easy answer for p6.
Cheers,
Joshua Gatcomb
a.k.a. L~R
Re: Malfunction Junction, what's your function?
Joshua Gatcomb wrote: ... FAQs such as union, difference, intersection of lists are FAQs for a reason. ... it would be nice to have a real simple easy answer for p6. And indeed it could be: use Sets; my @a is Set = (1,2,3); my @b is Set = (2,3,4); say @a + @b; # (1,2,3,4) say @a / @b; # (2,3) etc. Possibly with nice Unicode equivalents. -- TSa (Thomas Sandlaß)
Re: Malfunction Junction, what's your function?
On Wed, Apr 27, 2005 at 08:46:53AM -0400, Joshua Gatcomb wrote:
The problem is that in the regex version I use capturing parens to
identify the character matched. For the purposes of the problem I
don't need to rely on the first character matched I just need to know
1.
Without doing a lot of research into junctions, I thought the
following would work:
my $matches = any( @x_chars ) eq any( @y_chars );
my $match = $matches.pick;
Perhaps the easiest way to explain the difficulty here is to note that
executing a relational op (i.e. returning a boolean) value on a junction
argument returns a junction of boolean values. So, the Ceq expression
above doesn't contain the intersection of chars that match, it's just
a junction of the (boolean) values returned by infix:eq on each
pair of arguments from @x_chars and @y_chars. Actually, since
there's two junction arguments, the result will be an Cany junction
of Cany junctions.
The worst that could happen is that I find out
there isn't a way to get a what matched from an any() eq any()
comparison.
Not using the standard infix:eq, no. But I suppose one could get
close to what you're wanting with something like:
sub infix:myeq(Str $a, Str $b) { return ($a eq $b) ? $a : ''; }
and then
my $matches = any( @x_chars ) myeq any( @y_chars );
my $match = $matches.pick;
although since $match is any( any( ... ), any( ... ), any( ... ) )
I'm not sure if C.pick would end up picking a junction as opposed
to one of the inner values, or if it could pick one of the empty
string values.
Anyway, hope this helps clear up why the original wasn't working.
Pm
Re: Malfunction Junction, what's your function?
Patrick R. Michaud wrote:
On Wed, Apr 27, 2005 at 08:46:53AM -0400, Joshua Gatcomb wrote:
The problem is that in the regex version I use capturing parens to
identify the character matched. For the purposes of the problem I
don't need to rely on the first character matched I just need to know
1.
Without doing a lot of research into junctions, I thought the
following would work:
my $matches = any( @x_chars ) eq any( @y_chars );
my $match = $matches.pick;
Perhaps the easiest way to explain the difficulty here is to note that
executing a relational op (i.e. returning a boolean) value on a junction
argument returns a junction of boolean values.
Is that so? Does Perl6 have some fundamental law of junction preservation?
I would expect $matches to be either false or true---the junction values
are garbage collected.
... or if it could pick one of the empty
string values.
That's my understanding. The junctive value is lazily evaluating the
list of all permutations from @x_chars and @y_chars one at a time.
The myeq is called once for .pick and the result goes into $match.
But if you could use 'permute( @x_chars ) »myeq« permute( @y_chars )'
after writing the permute function ;)
And I wonder if
permute( @x_chars ) »{ $^a eq $^b ?? $^a :: ''}« permute( @y_chars )
would do the same?
--
TSa (Thomas Sandlaß)
Re: Malfunction Junction, what's your function?
Minor note.
Would you want this:
sub infix:myeq(Str $a, Str $b) { return ($a eq $b) ? $a : ''; }
to be:
sub infix:myeq(Str $a, Str $b) { return ($a eq $b) ? $a but bool::true:
''; }
(Is that the right way to do it ?)
Paul
Re: Malfunction Junction, what's your function?
On Wed, Apr 27, 2005 at 10:30:35AM -0600, Paul Seamons wrote:
Minor note.
Would you want this:
sub infix:myeq(Str $a, Str $b) { return ($a eq $b) ? $a : ''; }
to be:
sub infix:myeq(Str $a, Str $b) { return ($a eq $b) ? $a but bool::true:
''; }
(Is that the right way to do it ?)
Firstly, everybody needs to remember that ?: is now ??:: :-)
And yes, if $a and $b are equal but evaluate to a false value, you
probably want to attach some truthfulness to the value for boolean
sake. I wonder if you shouldn't also return a bool::false for the
other case just to be explicit:
sub infix:myeq(Str $a, Str $b) {
return ($a eq $b) ?? $a but bool::true :: bool::false
}
Suddenly I'm suffering a visual overload of colons though.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Malfunction Junction, what's your function?
Thomas Sandla writes: Patrick R. Michaud wrote: On Wed, Apr 27, 2005 at 08:46:53AM -0400, Joshua Gatcomb wrote: The problem is that in the regex version I use capturing parens to identify the character matched. For the purposes of the problem I don't need to rely on the first character matched I just need to know 1. Without doing a lot of research into junctions, I thought the following would work: my $matches = any( @x_chars ) eq any( @y_chars ); my $match = $matches.pick; Perhaps the easiest way to explain the difficulty here is to note that executing a relational op (i.e. returning a boolean) value on a junction argument returns a junction of boolean values. Is that so? Does Perl6 have some fundamental law of junction preservation? I would expect $matches to be either false or true---the junction values are garbage collected. Nope, not unless we give comparitors special junctive semantics (which may end up being a good idea). Consider: my $match = any(a b c) eq any(c d e); my $weird = $match + 1; say Ok if $weird == 2; This program does not say Ok if the junction garbage collects its states. Indeed, the junction doesn't preserve under boolean context. my $match = ?(any(a b c) eq any(c d e)); # $match is now 1 or 0 Quantum::Superpositions made comparitors special. my $match = any(a b c) eq 'b'; # $match is 'b' There's something eerie and inconsistent about that, mostly that you have to mark your functions as comparitors when you want them to do that. But it is vastly less a pain in this case than having to write Patrick's myeq. The more I think about junctions, the less nice they seem to be. Not to say that they don't kick ass still. Luke
Re: Malfunction Junction, what's your function?
On Wed, Apr 27, 2005 at 06:29:46PM +0200, Thomas Sandlaß wrote:
Patrick R. Michaud wrote:
my $matches = any( @x_chars ) eq any( @y_chars );
my $match = $matches.pick;
Perhaps the easiest way to explain the difficulty here is to note that
executing a relational op (i.e. returning a boolean) value on a junction
argument returns a junction of boolean values.
Is that so? Does Perl6 have some fundamental law of junction preservation?
I would expect $matches to be either false or true---the junction values
are garbage collected.
I would certainly expect $matches to be false or true if the
expression was invoked in a boolean context, but I'm not certain
it can auto-collapse outside of that. In particular, we know that
$x = any(0, 1);
$y = $x + 1; # $y == any(1, 2)
so a slightly different formulation of this would be:
$w = any('a', 'b');
$x = $w eq 'b'; # $x == any(0, 1)
$y = $x + 1; # $y == any(1, 2)
I think the assignment to $x above shouldn't be collapsed directly
to a simple false or true value until it's evaluated in a boolean
context.
Pm
Re: Malfunction Junction, what's your function?
Thomas Sandlaß wrote:
Patrick R. Michaud wrote:
On Wed, Apr 27, 2005 at 08:46:53AM -0400, Joshua Gatcomb wrote:
The problem is that in the regex version I use capturing parens to
identify the character matched. For the purposes of the problem I
don't need to rely on the first character matched I just need to know
1.
Without doing a lot of research into junctions, I thought the
following would work:
my $matches = any( @x_chars ) eq any( @y_chars );
my $match = $matches.pick;
Perhaps the easiest way to explain the difficulty here is to note that
executing a relational op (i.e. returning a boolean) value on a junction
argument returns a junction of boolean values.
Is that so? Does Perl6 have some fundamental law of junction
preservation?
I would expect $matches to be either false or true---the junction values
are garbage collected.
You're both right.
The junction of junctions of bools gets created from the threading...
and then gets collapsed into a single bool, based on the predicates.
(any in all cases here).
... or if it could pick one of the empty
string values.
That's my understanding. The junctive value is lazily evaluating the
list of all permutations from @x_chars and @y_chars one at a time.
The myeq is called once for .pick and the result goes into $match.
I'm pretty sure the .pick would return one of the junctions of
chars/empty strings. You could do a .pick.pick to get a single result
back out. However, you'd be stuck with all the empty strings again. I
think you'd likely want something like
$matches.values».values.grep:{$_ ne ''}
but if you're going through that much trouble, just do:
@matches = @x_chars.grep:{$_ ~~ @y_chars};
and be done with it.
It's been established before that getting at _which_ values in a
junctions made the evaluation turn one way or the other is _not_
something that will be readily supported.
-- Rod Adams
Re: Malfunction Junction, what's your function?
On Wed, Apr 27, 2005 at 10:30:35AM -0600, Paul Seamons wrote:
Minor note.
Would you want this:
sub infix:myeq(Str $a, Str $b) { return ($a eq $b) ? $a : ''; }
to be [corrected]:
sub infix:myeq(Str $a, Str $b)
{ return ($a eq $b) ?? $a but bool::true :: ''; }
Perhaps, but I don't know that it makes much difference for the
example given. I probably should've chosen a name other than myeq
so that we aren't fooling ourselves into believing we're returning
booleans when we're really returning strings that match.
Pm
Re: Malfunction Junction, what's your function?
Rod Adams writes: Perhaps the easiest way to explain the difficulty here is to note that executing a relational op (i.e. returning a boolean) value on a junction argument returns a junction of boolean values. Is that so? Does Perl6 have some fundamental law of junction preservation? I would expect $matches to be either false or true---the junction values are garbage collected. You're both right. The junction of junctions of bools gets created from the threading... and then gets collapsed into a single bool, based on the predicates. Except that it doesn't. Not until it is evaluated in boolean context. any(0, 1) does not immediately collapse to 1. Without any other context, any(0, 1) means any value which is either zero or one and interprets the boolean value of nothing. You wouldn't expect perl to try to evaluate something as a boolean unless it's in some sort of boolean context, would you? The same holds for junctions. It's been established before that getting at _which_ values in a junctions made the evaluation turn one way or the other is _not_ something that will be readily supported. I don't think that's been established. I think that's been stated as a consequence of the current semantics. I don't see any linguistic reason why junctions /should not/ support that. It's just that they don't (right now). Luke
Re: Malfunction Junction, what's your function?
Luke Palmer wrote: Rod Adams writes: Perhaps the easiest way to explain the difficulty here is to note that executing a relational op (i.e. returning a boolean) value on a junction argument returns a junction of boolean values. Is that so? Does Perl6 have some fundamental law of junction preservation? I would expect $matches to be either false or true---the junction values are garbage collected. You're both right. The junction of junctions of bools gets created from the threading... and then gets collapsed into a single bool, based on the predicates. Except that it doesn't. Not until it is evaluated in boolean context. any(0, 1) does not immediately collapse to 1. Without any other context, any(0, 1) means any value which is either zero or one and interprets the boolean value of nothing. You wouldn't expect perl to try to evaluate something as a boolean unless it's in some sort of boolean context, would you? The same holds for junctions. Hmm. I was thinking that the eq made it boolean context, but you're right, it doesn't collapse in this case. It's been established before that getting at _which_ values in a junctions made the evaluation turn one way or the other is _not_ something that will be readily supported. I don't think that's been established. I think that's been stated as a consequence of the current semantics. I don't see any linguistic reason why junctions /should not/ support that. It's just that they don't (right now). I remember the topic coming up before during the junction wars of a few months ago. It was one of those things that separated junctions from sets in a rather dramatic way. And as you said, currently, they do not. If you wish to propose syntax and semantics to make it happen, go for it. But the way I see it, in order to make that happen, you'd have to remember what value was threaded to generate each resulting value, and have that essentially be a property of that value. Then the return of a junction threading would be a rather more complex object, with possible chaining of these properties, if the junction goes through several iterations of evaluation. If you have that, it would be straightforward to write functions that inspect these properties, and grep out what you wanted. My gut reaction though is that is gets expensive, and it seems odd to support this value history on only junctions. For instance, if you do $x = isprime(4);, do you expect the resulting $x to have a property saying it was derived from 4? That's a philosophical matter. It would have some real nasty side effects on performance if done large scale, but could prove invaluable for debugging and some specific problems. I think that if you want to know what matched, you should be using arrays and grep/map, not junctions. -- Rod Adams
