[perl6/specs] e04fd4: [S02] added non-junction :exists example
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: e04fd48df44b7149fea01598e2df32dd2738b097 https://github.com/perl6/specs/commit/e04fd48df44b7149fea01598e2df32dd2738b097 Author: Carl Masak cma...@gmail.com Date: 2011-01-09 (Sun, 09 Jan 2011) Changed paths: M S02-bits.pod Log Message: --- [S02] added non-junction :exists example Also un-forgot bumping the version.
Re: Junction Algebra
Here's another useful one: any($x) eqv all($x) eqv one($x) eqv $x but: none($x) !eqv $x That is, applying any, all, or one to a one-item list produces the equivalent to a single item. For an empty list: any() eqv all() eqv (). But what about one() and none()? -- Jonathan Dataweaver Lang
Re: Junction Algebra
On Mon, 30 Mar 2009, Jon Lang wrote: Here's another useful one: any($x) eqv all($x) eqv one($x) eqv $x but: none($x) !eqv $x That is, applying any, all, or one to a one-item list produces the equivalent to a single item. For an empty list: any() eqv all() eqv (). But what about one() and none()? It seems to me that one is out of step with the scalarness of junctions; it implies that you have to look for two things, firstly that there is some value in the eigenstates that satisfies whatever condition, and secondly that every other value does not. I suspect that the confusion arises because the original intention would have been to have something along the lines of: none === !any something === !all except that one doesn't fit the bill as something. But back to the original question, since none is just a funny spelling for !any, their mutual combination can be flattened accordingly: none($a, any($b, $c)) == none($a, $b, $c) And (given a suitable interpretation of a monadic none): all($a, none($b, $c)) == all($a, none($b), none($c)) Question: Or in general, it doesn't matter how many times you mention a simple scalar in an expression, it always has the same value, so that ( $a = $x = $b ) == ( $a = $x $x = $b ) always holds true. However I suspect that if $x = any(-1, +1) this may no longer be the case. This would certainly be false: ( $a = any(-1,+1) = $b ) == ( $a = any(-1,+1) any(-1,+1) = $b ) Consider if $a and $b are both 0 ... For this to work it seems that the auto-threading logically must reach back to the point where the junction is created, or at least to be tied to the identity of the junction in some way. Which latter would imply that any($a, $b) !== any($a, $b) There must be a logical way out, but how? Any other comments? What about: $x = any(-1,+1); $x $x and die; # must not happen (same eigenstate must # be used on both sides of '' ?) $x $x.eigenstates.any() or die; # matches for -1 +1 -Martin
Re: Junction Algebra
On Mon, Mar 30, 2009 at 9:44 PM, Martin D Kealey mar...@kurahaupo.gen.nz wrote: This would certainly be false: ( $a = any(-1,+1) = $b ) == ( $a = any(-1,+1) any(-1,+1) = $b ) Clearly, the RHS is true for $a == $b == 0, but I'm not sure the LHS shouldn't also be. Isn't it just syntactic sugar for the RHS? Logically, you might want it to mean something like ∃$x: $x == any(-1,+1) $a = $x $x = $b, but I don't think it does. -- Mark J. Reed markjr...@gmail.com
Re: Junction Algebra
On Mon, 30 Mar 2009, Mark J. Reed wrote: ( $a = any(-1,+1) = $b ) == ( $a = any(-1,+1) any(-1,+1) = $b ) Clearly, the RHS is true for $a == $b == 0, but I'm not sure the LHS shouldn't also be. Isn't it just syntactic sugar for the RHS? I suspect not. Rather I think that $a = any(-1,+1) = $b corresponds to $tmp = any(-1,+1); $a = $tmp = $b and thence to $tmp = any(-1,+1); $a = $tmp $tmp = $b The more I think about this, the more I come to the conclusion that a junction should appear to have a uniform (single) value in each eigenthread. Logically, you might want it to mean something like ∃$x: $x == any(-1,+1) $a = $x $x = $b, but I don't think it does. I think that flows fairly cleanly from the Junction-isa-Object implementation, and the way that references are taken. This is not going to play well with subexpression folding: junctions have to be considered unclean, in that two junctions must not be merged even if they're immutable and indistinguishable (except for object identity). $a = any($x, $y); $b = any($x, $y); assert $a !== $b; Earlier Moritz suggested that one could modify an external object from within the eigenthreads to accumulate the list of eigenstates, in defiance of having the !eigenstates() method private. That's almost reasonable, but it assumes that eigenthreads don't work on separate snapshot copies of the world, and that those snapshots aren't discarded after their results are flattened by the junctive operator. -Martin
Re: Junction Algebra
Richard Hainsworth conjectured:
1) Is the following true for an any junction?
any( ... , any('foo','bar')) === any(...,'foo','bar')
If yes, then
if an 'any' junction is contained in an outer 'any', the inner 'any' can be
factored out?
Yes. More precisely, an 'any' that is directly nested inside another
'any' can be flattened.
By directly, I mean with no intervening levels of non-'any'
junctions. That is, not like: any(...,all(...,any('foo', 'bar')))
2) Also, is the following true for nested 'all' junctions? viz.
all(... , all('foo', 'bar')) === all(...,'foo','bar')
Yes, with a similiar directly caveat, as above.
3) Conjecture: The following is true of all junction types, eg.,
junc(..., junc(...)) === junc(..., ...)
No. As Patrick so ably pointed out, this is not true for 'one' nor for 'none'
Damian
Junction Algebra
Included in my 'On junctions' message were some questions that have not
been directly answered. I simplify and expand them here.
Here I use === to mean 'is the same as'.
(I am not sure which of == or === should be used.)
1) Is the following true for an any junction?
any( ... , any('foo','bar')) === any(...,'foo','bar')
If yes, then
if an 'any' junction is contained in an outer 'any', the inner 'any' can
be factored out?
2) Also, is the following true for nested 'all' junctions? viz.
all(... , all('foo', 'bar')) === all(...,'foo','bar')
3) Conjecture: The following is true of all junction types, eg.,
junc(..., junc(...)) === junc(..., ...)
4) Are there any transformations of other nested junctions?
Richard
Re: Junction Algebra
On Sat, Mar 28, 2009 at 02:08:22PM +0300, Richard Hainsworth wrote: 3) Conjecture: The following is true of all junction types, eg., junc(..., junc(...)) === junc(..., ...) The conjecture is false for one/none junctions: one(0, one(1, 1)) # true one(0, 1, 1) # false none(0, none(0, 0)) # false none(0, 0, 0) # true I'm still considering the any/all cases. Pm
Re: Junction Algebra
On Sat, Mar 28, 2009 at 10:19:31AM -0500, Patrick R. Michaud wrote: On Sat, Mar 28, 2009 at 02:08:22PM +0300, Richard Hainsworth wrote: 3) Conjecture: The following is true of all junction types, eg., junc(..., junc(...)) === junc(..., ...) The conjecture is false for one/none junctions: one(0, one(1, 1)) # true one(0, 1, 1) # false Boy, I typoed that one. I meant to write: one(1, one(1, 1)) # true one(1, 1, 1)# false Pm
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
a junction or not
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?
Richard
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: rfc: The values of a junction
On Jan 5, 2:24 pm, d...@dave.whipp.name (Dave Whipp) wrote: Handling all the variations around this (including compound junctions) will be quite tricky to implement, even if we did have introspection for junctions. Incidentally, we'd also need introspection of arrays, to extract the infinite ranges without iterating over them.
rfc: The values of a junction
I spent a fair amount of time with Rakudo over the holiday break (see
http://dave.whipp.name/sw/perl6 for the writeup). I was generally
impressed with both the language and its implementation. There were,
unsurprisingly, a bunch of things missing. Some of these were things
that are in the spec, but not yet in Rakudo. Others are things that feel
important, but which could be added later, via modules. But one
omission, junctional collapse, appears to me to require core language
support: it is not a feature that can be added as a user module.
The term collapse is a metaphor taken from quantum mechanics. It is
apt, because the concept of the values of a junction makes sense only
in the context of the action of an operator on the junction. It is my
proposal that we add a new meta-operator to S03 that acts to apply other
operators (equality and inequality tests) to junctions:
@domain |op| $junction -- @values ## junction-collapsing grep
@domain !|op| $junction -- @values ## it's negated partner
The operator has the semantics of a grep, but with the ability to
handle infinite ranges in finite time. The reason for this should become
apparent from a motivating example. Consider a blackjack hand: a set of
cards where the value of aces is either 1 or 11. The total value of a
hand can be described as a junction:
my $ace = 1 | 11;
my $seven = 7;
my @hand = $ace xx 3, $seven;
my $junc_value = [+] @hand; ## any( 10, 20, 30, 40 )
There are a bunch of possible values in the junction. The one we care
about is the largest that is not greater than 21. Using Perl6 as it
stands today, the way to extract this value is brute force:
my $concrete_value = max (0..21).grep: { $^score == $junc_value };
This will work, but doesn't scale. Imagine we wanted all the possible
values, and know nothing about their domain:
my @all_values = (-Inf..Inf).grep: { $^score == $junc_value };
This code has an obvious performance problem that would be tricky to
optimize away! And that problem is the justification of my assertion
that junctional collapse requires core language support. Using a grep
meta operator:
my $concrete_value = max 0 .. 21 |==| $junc_value;
my @all_values = -Inf .. Inf |==| $junc_value;
the infinite range can be handled correctly.
Adding a new meta-operator should not be undertaken lightly. I believe
that the collapse of junctions is a necessary feature of the language,
and one that cannot be added as a user-module. Furthermore, alternatives
such as a eigenvalues method on the Junction class fail to address the
core property of junctions that their value depends on the operator that
is used to observe them.
Another hurdle that the meta operator must overcome it to demonstrate
that it is sufficiently general. If the only values of op was ==,
then we wouldn't need a meta. Also, the operator has application
beyond collapsing junctions. Some more examples:
say ^Inf || one 4 .. Inf; ## result == 5
say @lines |~~| /word/;## no junction: a standard grep
An additional feature -- not part of my core proposal, but one that I
think would add value -- would be to allow a typename to be used as the
LHS domain, in place of an infinite range:
say ::Str |eq| any foo bar baz ; ## match against all strings
say ::Str !|ne| all foo bar baz ; ## same result
say ::Str !|eq| none foo bar baz ; ## same again!
or a finite range:
subset BJ_score where { $_ == any 0 .. 21 };
say score is { max( ::BJ_score |==| $junc_score ) // bust }
I'd like to think that this proposal is an obvious way to meet a
necessary need. Even if this exact approach is not chosen, I hope to
have at least convinced you that core language support is needed to
extract the values of a junction; and that a Junction::eigenvalues
method is not the correct way to achieve this.
Dave.
ps. The reason for choosing vertical bars, |op|, as the meta-op syntax
is partly by analogy to the concept of absolute value that
mathematicians express using vertical bars; and partly a less-cute
distillation of a bra-ket suggestion I make in the writeup that I
referenced above.
Re: rfc: The values of a junction
Em Seg, 2009-01-05 às 07:57 -0800, Dave Whipp escreveu:
my $ace = 1 | 11;
my $seven = 7;
my @hand = $ace xx 3, $seven;
my $junc_value = [+] @hand; ## any( 10, 20, 30, 40 )
There are a bunch of possible values in the junction. The one we care
about is the largest that is not greater than 21. Using Perl6 as it
stands today, the way to extract this value is brute force:
my $concrete_value = max (0..21).grep: { $^score == $junc_value };
Well, that considering we don't have any introspection into junctions,
but I think it should be quite straight-forward to make junctions behave
as a list of its members...
my $ace = 1 | 11;
my $seven = 7;
my @hand = $ace xx 3, $seven;
my $junc_value = [+] @hand;
my $concrete_value = max $junc_value.grep: { $^scope 21 };
daniel
Re: rfc: The values of a junction
That doesn't solve the general problem:
my $junc = any -4 .. Inf;
my @domain = -Inf .. 4;
my @values = @domain |==| $junc;
say @values.perl
[ -4 .. 4 ]
How do you code that using grep?
From: Daniel Ruoso dan...@ruoso.com
To: Dave Whipp d...@dave.whipp.name
Cc: perl6-language@perl.org
Sent: Monday, January 5, 2009 11:24:29 AM
Subject: Re: rfc: The values of a junction
Em Seg, 2009-01-05 às 07:57 -0800, Dave Whipp escreveu:
my $ace = 1 | 11;
my $seven = 7;
my @hand = $ace xx 3, $seven;
my $junc_value = [+] @hand; ## any( 10, 20, 30, 40 )
There are a bunch of possible values in the junction. The one we care
about is the largest that is not greater than 21. Using Perl6 as it
stands today, the way to extract this value is brute force:
my $concrete_value = max (0..21).grep: { $^score == $junc_value };
Well, that considering we don't have any introspection into junctions,
but I think it should be quite straight-forward to make junctions behave
as a list of its members...
my $ace = 1 | 11;
my $seven = 7;
my @hand = $ace xx 3, $seven;
my $junc_value = [+] @hand;
my $concrete_value = max $junc_value.grep: { $^scope 21 };
daniel
Re: rfc: The values of a junction
Daniel Ruoso wrote:
my $concrete_value = max $junc_value.grep: { $^score 21 };
In the general case, both the junction and the domain may be infinite:
my @domain = -Inf .. 3;
my $junc = any -4 .. Inf;
my @values = @domain |==| $junc;
say @values.perl
[-4..3]
Handling all the variations around this (including compound junctions)
will be quite tricky to implement, even if we did have introspection for
junctions. Certainly not stuff I'd want in typical user-code.
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: Are eqv and === junction aware?
HaloO
Jon Lang wrote:
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?
I consider stringified junction comparison as second class that
we don't use for other objects either. An .eigenmumble definitely
needs a nicer name. So, don't we have an item enforcement operator?
If that would discharge junctions to mere objects we would have:
my $a = all(1,2,3);
my $b = $a;
if item $a === item $b { say junctions are identical }
And then we can invent some short form of that. Things that come
to my mind are =i=, =$= and =^= where the latter nicely reminds
one of the one() junction and also is the indicator for the meta
level where junctions loose their autothreading power and become
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.
Conversion to another type violates the requirement for === that
two objects of different types cannot be identical.
We have other operations that should not autothread but demote
junctions to objects:
any(1,2,3) ~~ Junction
Here it hardly makes sense to expand that to
1 ~~ Junction || 2 ~~ Junction || 3 ~~ Junction
Note that this demotion to object means that
any(1,2,3) ~~ Int
evaluates to false because the lhs is of type AnyJunction of Int.
To me this is the same as
[1,2,3] ~~ Int
which is false because there is an Array of Int not an Int.
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: 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: 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?
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
Re: Elimination of Item|Pair and Any|Junction
Autrijus Tang [EMAIL PROTECTED] writes:
On Fri, Jul 22, 2005 at 03:40:34PM -0700, Larry Wall wrote:
I dunno. I'm inclined to say that it should default to Item|Pair, and
let people say Any explicitly if they really want to suppress autothreading.
Otherwise conditionals and switches are going to behave oddly in the
presence of accidental junctions.
Okay. However, in that view, I suspect many builtins will be defined on
Item|Pair, for example perl, clone, id, as well as various coercion
builtins. Considering that builtins are Code objects but not Routines,
maybe they, too, should default to Item|Pair -- except the ones that
operates on junctions, of course.
This leads me to think that maybe users don't really need to write down
the two junctive types, under the hierarchy below:
- Object
- Any
- Item
- ...pretty much everything
- Pair
- Junction
- num, int, str...
Since junctions are still boxed objects, having the Object type to
effectively mean Any|Junction seems natural (everything is an object).
Also, since Any unifies Item and Pair, the rule for implicit types of
argument becomes:
sub ($x) { }# Item $x
- $x { } # Any $x- i.e. Item|Pair but not Junction
{ $^x } # Any $x- i.e. Item|Pair but not Junction
Maybe there's a case for introducing Bundle types, akin to CPAN bundles. These
would be types only in the very losest sense, that could be used in function
prototypes to stand for particular bundles of types. So instead of Any being in
the class hierarchy where you propose it'd be a bundle that expanded to the
equivalent of doing:
any(Object.all_subclasses.grep - $class { !$class.does(Junction) })
That way we get to arrange the class hierarchy in the way that makes the most
sense conceptually, but slice still slice it appropriately for Type
specifiers.
Just a thought.
Re: Elimination of Item|Pair and Any|Junction
Larry Wall wrote:
On Wed, Jul 27, 2005 at 06:28:22PM +0200, TSa (Thomas Sandlaß) wrote:
: Since we are in type hierachies these days, here's my from ::Any
: towards ::All version.
That's pretty, but if you don't move Junction upward, you haven't
really addressed the question Autrijus is asking. We're looking
for a simple type name that means none(Junction) for use as the
default type of the $x parameter to - $x {...}. Whatever we call
it, this type/class/role/subtype has to admit Item and Pair objects
but not Junctions. (And if that's the wrong way to think about it,
please tell us why.)
Sorry, here's the patch:
: Code @Array %Hash $Item
: | // |
with: | TupleRecord |
invocant(s) : ||
:/ \__ ___|_
|: | |\|| | |
.Method : Sub Block |Value Inf Undef Junction
/|: |\ | |
/ |: | \Ref[Code]|
Rule |: | Macro|
|:_/|__/|\___
|: | | | | | |
Multi : | ~Str +Num \Ref :Pair /Match/
Now the Junction is nicely constraint with the upper bound Item (less
specific) and a lower bound Value (more specific). This also reads
nice if you want to (explicitly) allow both:
sub ( Value|Junction $val_junc )
What sub ( $any ) should default to, I don't know. My $Item indicates
Item, but could also be $Value. Or unspecific $(Item|Value).
--
$TSa.greeting := HaloO; # mind the echo!
Re: Elimination of Item|Pair and Any|Junction
On Thu, Jul 28, 2005 at 00:26:27 +0800, Autrijus Tang wrote: Er, but Junctions take methods, the same way Objects do, so if there is an Object in the type hierarchy, Junction probably belongs to it. Maybe there is a role called 'Junctive'? I think junctions are orthogonal to other types, except when people try to deal with them explicitly... The all encompassing type is not really a type, but more of a shortcut. My take: Any Object Item Atom ... Pair Junction int, str, ... where any of these can also 'do' Junctive. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me tips over a cow: neeyah!! pgpvvnhW5imFv.pgp Description: PGP signature
Re: Elimination of Item|Pair and Any|Junction
On Thu, Jul 28, 2005 at 09:27:00AM -0700, Larry Wall wrote: Or maybe Any really does mean Object and we're just viewing our hierarchy too strictly if we make every relationship isa. That's one thing that neither this formulation nor Thomas's are making very clear--which type relations are really subclassing, which are role composition, and which are subtype constraints. FWIW, I've been reading up on Scala's formulation of trait/class/delegation hierarchy, and I feel a bit like flipping through a puzzle book to look at the hints, if not answers. :-) http://scala.epfl.ch/docu/files/api/index.html And I'm still not entirely sure I believe the not-yet-bound-ness of Pairs is all that different from the not-yet-bound-ness of Junctions to the extent that a different type level is warranted. Junctive autothreading are outside bindings -- they can be viewed as a two-phase exception handling from parameter type mismatches that fires away more function applications. Pairs on the other hand are bound normally; they just have a preferred zone unless overriden by the parameter signature; this resolution is strictly within the same one-step binding. I think there may be more types to come that has its preferred binding semantic, than outside-the-box devices like Junctions. I guess I still think there ought to be a way of marking Pairs on the call end as to whether they're intended for named args or not, without warping the whole top-level type system to that end. I can see marking things explicitly for named bindings: foo(:literalpair); foo(*%nameds); foo(*$pair); foo([EMAIL PROTECTED]); That will mean that foo($pair) will always be positional. Thanks, /Autrijus/ pgpcAv844aT1u.pgp Description: PGP signature
Re: Elimination of Item|Pair and Any|Junction
On Fri, Jul 29, 2005 at 05:59:43AM +0800, Autrijus Tang wrote:
I can see marking things explicitly for named bindings:
foo(:literalpair);
foo(*%nameds);
foo(*$pair);
foo([EMAIL PROTECTED]);
Er, sorry, the last one should be
foo(*%{ hash @list_of_pairs });
Thanks,
/Autrijus/
pgpBLMrCD5fBT.pgp
Description: PGP signature
Elimination of Item|Pair and Any|Junction
On Fri, Jul 22, 2005 at 03:40:34PM -0700, Larry Wall wrote:
I dunno. I'm inclined to say that it should default to Item|Pair, and
let people say Any explicitly if they really want to suppress autothreading.
Otherwise conditionals and switches are going to behave oddly in the
presence of accidental junctions.
Okay. However, in that view, I suspect many builtins will be defined on
Item|Pair, for example perl, clone, id, as well as various coercion
builtins. Considering that builtins are Code objects but not Routines,
maybe they, too, should default to Item|Pair -- except the ones that
operates on junctions, of course.
This leads me to think that maybe users don't really need to write down
the two junctive types, under the hierarchy below:
- Object
- Any
- Item
- ...pretty much everything
- Pair
- Junction
- num, int, str...
Since junctions are still boxed objects, having the Object type to
effectively mean Any|Junction seems natural (everything is an object).
Also, since Any unifies Item and Pair, the rule for implicit types of
argument becomes:
sub ($x) { }# Item $x
- $x { } # Any $x- i.e. Item|Pair but not Junction
{ $^x } # Any $x- i.e. Item|Pair but not Junction
Does this sound sane?
Thanks,
/Autrijus/
pgpbsmHzHG4yc.pgp
Description: PGP signature
Re: Elimination of Item|Pair and Any|Junction
On Wed, Jul 27, 2005 at 08:01:25PM +0800, Autrijus Tang wrote:
: On Fri, Jul 22, 2005 at 03:40:34PM -0700, Larry Wall wrote:
: I dunno. I'm inclined to say that it should default to Item|Pair, and
: let people say Any explicitly if they really want to suppress autothreading.
: Otherwise conditionals and switches are going to behave oddly in the
: presence of accidental junctions.
:
: Okay. However, in that view, I suspect many builtins will be defined on
: Item|Pair, for example perl, clone, id, as well as various coercion
: builtins. Considering that builtins are Code objects but not Routines,
: maybe they, too, should default to Item|Pair -- except the ones that
: operates on junctions, of course.
:
: This leads me to think that maybe users don't really need to write down
: the two junctive types, under the hierarchy below:
:
: - Object
: - Any
: - Item
: - ...pretty much everything
: - Pair
: - Junction
: - num, int, str...
:
: Since junctions are still boxed objects, having the Object type to
: effectively mean Any|Junction seems natural (everything is an object).
:
: Also, since Any unifies Item and Pair, the rule for implicit types of
: argument becomes:
:
: sub ($x) { }# Item $x
: - $x { } # Any $x- i.e. Item|Pair but not Junction
: { $^x } # Any $x- i.e. Item|Pair but not Junction
:
: Does this sound sane?
Yes. The only thing I don't like about it is that any() isn't an Any.
Maybe we should rename Any to Atom. Then maybe swap Item with Atom,
since in colloquial English you can say that pair of people are
an item. That would give us:
- Object
- Item
- Atom
- ...pretty much everything
- Pair
- Junction
- num, int, str...
which nicely distinguishes Item from Junction. On the other hand,
I actually kinda dislike the word Atom for common use (too much
exposure to Lisp, I guess), so maybe we just want
- Object
- Mumble
- Item
- ...pretty much everything
- Pair
- Junction
- num, int, str...
where Mumble is something like Atom/NonJunction/Unit/Scalar/[your ad here].
Larry
Re: Elimination of Item|Pair and Any|Junction
Larry~
On 7/27/05, Larry Wall [EMAIL PROTECTED] wrote:
On Wed, Jul 27, 2005 at 08:01:25PM +0800, Autrijus Tang wrote:
: On Fri, Jul 22, 2005 at 03:40:34PM -0700, Larry Wall wrote:
: I dunno. I'm inclined to say that it should default to Item|Pair, and
: let people say Any explicitly if they really want to suppress
autothreading.
: Otherwise conditionals and switches are going to behave oddly in the
: presence of accidental junctions.
:
: Okay. However, in that view, I suspect many builtins will be defined on
: Item|Pair, for example perl, clone, id, as well as various coercion
: builtins. Considering that builtins are Code objects but not Routines,
: maybe they, too, should default to Item|Pair -- except the ones that
: operates on junctions, of course.
:
: This leads me to think that maybe users don't really need to write down
: the two junctive types, under the hierarchy below:
:
: - Object
: - Any
: - Item
: - ...pretty much everything
: - Pair
: - Junction
: - num, int, str...
:
: Since junctions are still boxed objects, having the Object type to
: effectively mean Any|Junction seems natural (everything is an object).
:
: Also, since Any unifies Item and Pair, the rule for implicit types of
: argument becomes:
:
: sub ($x) { }# Item $x
: - $x { } # Any $x- i.e. Item|Pair but not Junction
: { $^x } # Any $x- i.e. Item|Pair but not Junction
:
: Does this sound sane?
Yes. The only thing I don't like about it is that any() isn't an Any.
Maybe we should rename Any to Atom. Then maybe swap Item with Atom,
since in colloquial English you can say that pair of people are
an item. That would give us:
- Object
- Item
- Atom
- ...pretty much everything
- Pair
- Junction
- num, int, str...
which nicely distinguishes Item from Junction. On the other hand,
I actually kinda dislike the word Atom for common use (too much
exposure to Lisp, I guess), so maybe we just want
- Object
- Mumble
- Item
- ...pretty much everything
- Pair
- Junction
- num, int, str...
where Mumble is something like Atom/NonJunction/Unit/Scalar/[your ad here].
While we are talking about words... I dislike having Object encompass
Juction. I get the feeling that some people will write functions that
take Objects and not expect Junctions to slip in. I suppose that
could be one of those hurdles that developers just have to jump, but
it doesn't feel like it should be.
Matt
--
Computer Science is merely the post-Turing Decline of Formal Systems Theory.
-Stan Kelly-Bootle, The Devil's DP Dictionary
Re: Elimination of Item|Pair and Any|Junction
On Wed, Jul 27, 2005 at 12:19:10PM -0400, Matt Fowles wrote: While we are talking about words... I dislike having Object encompass Juction. I get the feeling that some people will write functions that take Objects and not expect Junctions to slip in. I suppose that could be one of those hurdles that developers just have to jump, but it doesn't feel like it should be. Er, but Junctions take methods, the same way Objects do, so if there is an Object in the type hierarchy, Junction probably belongs to it. However we can tone down the ordinariness of Object so people will be less inclined to use it. Boxed? Thanks, /Autrijus/ pgpO521iJVLcV.pgp Description: PGP signature
Re: Elimination of Item|Pair and Any|Junction
HaloO,
Larry Wall wrote:
Yes. The only thing I don't like about it is that any() isn't an Any.
Maybe we should rename Any to Atom. Then maybe swap Item with Atom,
since in colloquial English you can say that pair of people are
an item.
Since we are in type hierachies these days, here's my from ::Any
towards ::All version. The bottom part where everything finds
together is missing for this installment.
::Any
... | ..
___:_|_:static type :
| : | : | | = context :
Package: | : Void Bool :
| : | :.
Module: |
___|___: |
| | : |
Class Grammar : |
|___| : |
| : |
Role : Object
: |
: | || |
: Code @Array %Hash $Item
: | // |
with: | TupleRecord |
invocant(s) : ||
:/ \__ __|_
|: | |\ / || | | |
.Method : Sub Block | | Inf Undef Match Junction
/|: |\ | |
/ |: | \Ref[Code]|
Rule |: | Macro|
|:_/|__/|\
|: | | | | |
Multi : | ~Str +Num \Ref :Pair
..: | | | |\|
| |Int| \ |
___/| | | | Entry[::T where T.does(Hash)]
| | | |/|\|
*List Pipe =Iterator Enum ?Bit Pos[::T where T.does(Str|Array)]
|\___
| | |
**Eager Lazy Ref[Array|Hash]
any() == lub( all --- any ) == glb( any -- all ) lesser -- greater
all() == glb( all --- any ) == lub( any -- all )
Some operators and prefixes are added in to show their
relation to the corresponding type. I hope it looks familiar.
Here is some pseudo code that describes a bare minimum data layout
required to support the respective types.
type Item[::T]
{
has $.value of T;
}
type Pair[::T]
{
has $.key;
has $.value of T;
}
type Tuple[::T where T does lub( @.values )] # lub = least upper bound
{
has @.values of T;
has $.value ::= @.values; # auto-enreference for Item subtyping
has T $.head ::= @.values[0];
has T $.tail ::= @.values[-1];
}
type Record[::T where T does lub( @.values )]
{
has @.keys;
has @.values of Pair[T];
has @.pairs ::= { zip @.keys, @.values };
has $.value ::= @.pairs;
}
type Code
{
has %.MY;# lexical scratchpad
has .block;
has $.value ::= { use %.MY; .block() }; # coderef literal
}
type Junction[::T where enum any all one none]
{
has @.values;
has Junction $.value ::= { @.values as Junction[T] };
has .evaluate ::= ::JUNCTION_MAGIC; # what's the exact type of this?
}
--
$TSa.greeting := HaloO; # mind the echo!
Re: Elimination of Item|Pair and Any|Junction
On Wed, Jul 27, 2005 at 06:28:22PM +0200, TSa (Thomas Sandlaß) wrote:
: Since we are in type hierachies these days, here's my from ::Any
: towards ::All version.
That's pretty, but if you don't move Junction upward, you haven't
really addressed the question Autrijus is asking. We're looking
for a simple type name that means none(Junction) for use as the
default type of the $x parameter to - $x {...}. Whatever we call
it, this type/class/role/subtype has to admit Item and Pair objects
but not Junctions. (And if that's the wrong way to think about it,
please tell us why.)
Larry
Re: Elimination of Item|Pair and Any|Junction
Larry Wall wrote:
On Wed, Jul 27, 2005 at 06:28:22PM +0200, TSa (Thomas Sandlaß) wrote:
: Since we are in type hierachies these days, here's my from ::Any
: towards ::All version.
That's pretty, but if you don't move Junction upward, you haven't
really addressed the question Autrijus is asking. We're looking
for a simple type name that means none(Junction) for use as the
default type of the $x parameter to - $x {...}. Whatever we call
it, this type/class/role/subtype has to admit Item and Pair objects
but not Junctions. (And if that's the wrong way to think about it,
please tell us why.)
Suggestions:
Definite
Singelton (but that may mean no pairs, oops)
Solid
Settled
NonJunctive (yuck)
Terminal
NonThreaded (yuck)
Simple (but that could exclude arrays and hashs)]
Basic
Interesting question: are junctions infectious, are class object that
include a member with ajunction type also junctions?
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: Elimination of Item|Pair and Any|Junction
On Wed, Jul 27, 2005 at 09:12:00AM -0700, Larry Wall wrote: Yes. The only thing I don't like about it is that any() isn't an Any. snip - Object - Mumble - Item - ...pretty much everything - Pair - Junction - num, int, str... Hrm. I thought the original motivation of forcing people to write Any|Junction was precisely to discourage people from accidentally write sub foo (Any $x) and have $x accept a Junction. In other words, any() should not be of type Any. Hence it still feels natural for me that Any occurs at the position of Mumble. Thanks, /Autrijus/ pgplBqGItv0yM.pgp Description: PGP signature
Re: Elimination of Item|Pair and Any|Junction
At 9:12 AM -0700 7/27/05, Larry Wall wrote:
Yes. The only thing I don't like about it is that any() isn't an Any.
Maybe we should rename Any to Atom. Then maybe swap Item with Atom,
since in colloquial English you can say that pair of people are
an item. That would give us:
- Object
- Item
- Atom
- ...pretty much everything
- Pair
- Junction
- num, int, str...
which nicely distinguishes Item from Junction. On the other hand,
I actually kinda dislike the word Atom for common use (too much
exposure to Lisp, I guess), so maybe we just want
- Object
- Mumble
- Item
- ...pretty much everything
- Pair
- Junction
- num, int, str...
where Mumble is something like Atom/NonJunction/Unit/Scalar/[your ad here].
At 11:35 AM -0700 7/27/05, Larry Wall wrote:
We're looking
for a simple type name that means none(Junction) for use as the
default type of the $x parameter to - $x {...}. Whatever we call
it, this type/class/role/subtype has to admit Item and Pair objects
but not Junctions. (And if that's the wrong way to think about it,
please tell us why.)
Between what you've said, I prefer the top diagram myself. Where
something and Pair are each Item. Item seems more generic, and is
what one often calls a constituent of a list being iterated through.
So the $x parameter to - $x {...} should be called Item.
So then the question is what to replace Atom with:
- Object
- Item
- Mumble
- ...pretty much everything
- Pair
- Junction
- num, int, str...
In my brainstorming, I found it is a lot easier to come up with words
that mean single than non-junction. So working from that perspective
...
Why don't we just call it a Single?
- Object
- Item
- Single
- ...pretty much everything
- Pair
- Junction
- num, int, str...
The noun Single is common in speech, unambiguous in meaning, and
looks visually distinct from all the other types. It is often used
side by side in speech, such as she is a single and they are a
pair. Also, Single doesn't suggest being indivisible like Atom does.
I also vote against the use of Scalar there, since Scalar seems too
specific. Likewise with NonJunction, if we can help it, because it
looks messy.
-- Darren Duncan
Re: Elimination of Item|Pair and Any|Junction
On Wed, Jul 27, 2005 at 12:19:10PM -0400, Matt Fowles wrote: : While we are talking about words... I dislike having Object encompass : Juction. I get the feeling that some people will write functions that : take Objects and not expect Junctions to slip in. I suppose that : could be one of those hurdles that developers just have to jump, but : it doesn't feel like it should be. In which case - Any - Object - Item - ...pretty much everything - Pair - Junction - num, int, str... would be a little more like Thomas's type lattice. (Though I expect he'd treat the value types as constrained subtypes of Num, Int, Str, etc.) It seems stupid to split Object into just two things. But maybe there are other magical beasties like Pair that go alongside Pair, such as ordinary lazily bound argument lists before they are bound to a particular signature, or semicolons/pipes before it's determined if the signature is semicolon-sensitive. Basically, anything that's magical to the binder goes on that level, and according to the above would be an Object but not an Item. However we do it, we can only aim for Least Surprise, since No Surprise is not really attainable here. Larry
Re: Elimination of Item|Pair and Any|Junction
On Thu, Jul 28, 2005 at 03:55:55AM +0800, Autrijus Tang wrote: Hrm. I thought the original motivation of forcing people to write Any|Junction was precisely to discourage people from accidentally write sub foo (Any $x) and have $x accept a Junction. In other words, any() should not be of type Any. Hence it still feels natural for me that Any occurs at the position of Mumble. FWIW, if Any is to be ruled to be the top type and includes Junction, then I support Darren's proposal of Single, and maybe the Object type can be simply eliminated to Any: Any - Item - Single - Pair - Junction - int, num, str This also means that int num str will fit to Any via autoboxing. Thanks, /Autrijus/ pgpQPssdL4iZm.pgp Description: PGP signature
s/.../{ $junction }/
Hi,
while writing a preliminary p6explain, I wondered if the following
should work:
my $text = aBc;
$text ~~ s/B/{ C|D }/;
say $text.values; # aCc aDc
This would be extremely handy for p6explain, as I'm currently parsing a
datafile which looks like...
+
Standard mathematical infix operator.
@infix_ops
+ - * /
[EMAIL PROTECTED]
Reduce metaoperator.
Think of a join on the syntax level.
I could then do something like this:
# $rule is '[EMAIL PROTECTED]'
$rule ~~ s/[EMAIL PROTECTED]/{ any split , %rule{'@infix_ops'} }/;
copy_contents_to $rule.values;
Comments?
--Ingo
--
Linux, the choice of a GNU | self-reference, n. - See self-reference
generation on a dual AMD |
Athlon!|
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ß)
Malfunction Junction, what's your function?
Ok - sorry for the cheesy subject line but I couldn't resist. So I am working on porting some interesting pieces of code I wrote in p5 at the Monastery to p6 for the benefit of others - primarily to show how easy the transition can be. Since Pugs doesn't have p6 rules yet I wanted to show off the power of junctions instead of using the pcre support. Basically I need to know if any character in string x matches any character in string y - easy right: $str =~ /[chars]/ becomes any( @x_chars ) eq any( @y_chars ). 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; Ok - so maybe not - perhaps I should just change .pick to .values hmmm - still not working - perhaps I need to give the junctions more information as to what I am after all( any() eq any() ); Hmmm - perhaps the problem isn't with junctions but with Pugs but to know for sure I need to find out what, if anything, is the proper way to do what I want. 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. Cheers, Joshua Gatcomb a.k.a. L~R
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
use junction
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. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
junction adverb: :except
Hypothetical here: If we want to calculate a set of values for a junction which map nicely to a range with a few outliers, would it be possibly to have a qualifier :except which allows us to make exceptions to our given range? I.e., (Ignore for the moment the inefficiency of the choice of this particular algorithm.) my $year = 1900; # or whatever my $leap_year = $year % 400 == any(0..400 :by(4) :except(100,200,300)); Here except would be a modifier on the range being generated for any(). I could also see except being used to strip choices from junctions: my $j = 1|2|3|4; my $k=$j :except(2); # 1|3|4 Let me know if I'm totally abusing junctions here... David
Re: junction adverb: :except
David Christensen writes: Hypothetical here: If we want to calculate a set of values for a junction which map nicely to a range with a few outliers, would it be possibly to have a qualifier :except which allows us to make exceptions to our given range? I.e., (Ignore for the moment the inefficiency of the choice of this particular algorithm.) my $year = 1900; # or whatever my $leap_year = $year % 400 == any(0..400 :by(4) :except(100,200,300)); Here except would be a modifier on the range being generated for any(). I could also see except being used to strip choices from junctions: my $j = 1|2|3|4; my $k=$j :except(2); # 1|3|4 Let me know if I'm totally abusing junctions here... No, you're abusing adverbs. You can't give an adverb to a variable (because adverbs don't modify actually nouns :-). I don't know if we've destroyed Damian's comparator semantic, but if not, then you can just do: my $k = ($j != 2); But if that no longer happens, it's best a method on the junction. Except every time we add a method to junction, we destroy the ability to automatically thread that method over the junction. I've proposed several solutions to this over the years (applying to autodelegating iterators as well). I still think it's something that that needs to be solved. Luke
Re: Junction Values
On Sat, 19 Feb 2005 18:42:36 +1100, [EMAIL PROTECTED] (Damian Conway) wrote: the Awesome Power of Junctions: As I tried to express elsehwere, this what I'm looking for. Instinctively, and for a long time since I first came across Q::S, I thought that the killer app of Junctions is there somewhere, I'm just not seeing it yet. I'd really like to see some practical demonstrations of the Awesome Power. Something that goes beyond producing a boolean result from a set of values that could equally be done using hyperoperators? Njs.
Re: Junction Values
Rod Adams asked: This sound reasonable enough? Frankly, no. ;-) Sorry, but your latest proposal sounds complex, multiply special-cased, and way too much of an imposition on the programmer (which is specifically what junctions are supposed to avoid). I'm going to continue to strongly recommend that we stick with junctions that are simply another (fully assignable) kind of scalar value, and which always autothread in any scalar context that isn't explicitly typed CJunction. To protect the innocent (or the timorous) I'm also going to recommend a Cno autothreading pragma, which will prevent non-explicit junctions from autothreading. And that's all I'm going to recommend. Then, if you don't want implicit autothreading, you can turn it off completely: Cno autothreading. And if you want explicit (non-auto)threading, you can use an explicit junction, even under Cno autothreading: is_prime( any($x) ) And everywhere else, junctions will just Do The Right Thing, even to the point of ensuring that any side-effects on your unordered data are appropriately non-orderly. ;-) I truly appreciate the thought and effort that all of you--especially Rod and Patrick--have put into this discussion, but I'm afraid I have to bow out of it now. Damian PS: FWIW, I'd have absolutely no objection to us adding a fifth core junctive type (perhaps CAdjunction, perhaps just CSet ;-) that has *no* associated predicate, but which implements full set semantics: my $x = set(1..3); my $y = set(1,3,5,7,9); my $n = 2; $x | $y # set(1,2,3,5,7,9) $x $y # set(1,3) $x - $y # set(2) !$x # set(none(2));-) $x $y # $x is a proper subset of $y $x = $y # $x is a subset of $y $x == $y # $x is the set $y $x ~~ $y # $x is the set $y $n $y # $n is an element of $y $n ~~ $y # $n is an element of $y set()# empty set $x.values# list of elements of set $x $x.powerset # power set of $x $x x $y # cross product of $x and $y # etc., etc.
Re: Junction Values
Nigel Sandever wrote:
On Sat, 19 Feb 2005 18:42:36 +1100, [EMAIL PROTECTED] (Damian Conway) wrote:
The Awesome Power of Junctions:
As I tried to express elsehwere, this what I'm looking for.
Instinctively, and for a long time since I first came across Q::S, I thought
that the killer app of Junctions is there somewhere, I'm just not seeing it
yet.
I'd really like to see some practical demonstrations of the Awesome Power.
Something that goes beyond producing a boolean result from a set of values that
could equally be done using hyperoperators?
Well, that was one of my stumbling blocks early on. They don't really
give you the power to do anything you couldn't previously do. They just
make certain things a lot easier to do.
But I'll take a whack at giving you something non-trivial to do without
junctions:
$re1 = /^ -[x]* x -[x]* $/; # match a string with exactly one
'x' in it.
$re2 = /^ -[y]* y -[y]* $/; # ditto 'y'
$re3 = /^ -[z]* z -[z]* $/; # ditto 'z'
$re4 = all($re1, $re2, $re3); # matches if x,y, z all appear
exactly once, in any order.
$re5 = one($re1, $re2, $re3); # matches if there is exactly one x,
y, or z
$re6 = any($re1, $re2, $re3); # matches if there is at least one of
x,y,z that appears exactly once.
$re7 = none($re1, $re2, $re3); # matches if there are 0 or 2+ of
each of x,y,z.
And all seven of these can be used as any stored RE can:
if $x ~~ $re6 {...};
given $x {
when $re5 {...}
when 'santa' {...}
when ($re1 | $re3) $re3 {...}
}
Looking at the junctioned RE's:
#6 would is straight forward to do as a single RE in this case, and in
the general case.
#5 would be fairly trivial to in this case, but not in the general case.
#4 is possible with a lot of zero-length look aheads and look-behinds,
but very ugly.
#7 I have no idea how to attack as a single RE in anything close to
approaching elegance.
So what have we gained here? The ability to join several RE's together,
into something that still acts like a single RE. Show me the equivalent
code without junctions, and then we'll compare the power of junctions.
btw, the examples above assume the ability to store a junction. So you
either have to 'use junctions;', or convince Larry to rescind that
restriction.
HTH.
-- Rod Adams
Re: Junction Values
Damian Conway wrote: Rod Adams asked: This sound reasonable enough? Frankly, no. ;-) Sorry, but your latest proposal sounds complex, multiply special-cased, and way too much of an imposition on the programmer (which is specifically what junctions are supposed to avoid). Funny. I thought it was simple and elegant. My explanation might have been complex, as well as the motivations, but I truly considered it a straight forward and simple solution. As for too much of an imposition on the programmer, that's essentially what I was asking for all along. To be imposed upon to decide when threading occurs. I won't apologize for that, or change my position on it. But I was making the imposition optional. And, actually, now that I better understand your latest proposal, I realize how amazing close we are. Then, if you don't want implicit autothreading, you can turn it off completely: Cno autothreading. And if you want explicit (non-auto)threading, you can use an explicit junction, even under Cno autothreading: is_prime( any($x) ) Change that C any($x) to C »$x« , and the important differences between our positions shrink dramatically. Reason I don't like any() here is that $x already has a junctive condition on it. While any() with a single value does not change in the least how this will be evaluated in the long run, it could be confusing to wrap an all() junction inside an any() call. Doubling up the type works for all the types except none(). Use »« for an explicit call designator, and you revert to the type already in the junction. Give me my »« as a secondary way of always explicitly threading, and I'll go away happy. You can keep the rest of your proposal the same. I'll just start using them wherever I think threading should happen, even if I never needed to use them in most of the places I will. It'll be a good visual to myself of what's going on. Don't give them to me, and I'll frown for a while, but then likely get over it. I truly appreciate the thought and effort that all of you--especially Rod and Patrick--have put into this discussion, but I'm afraid I have to bow out of it now. I understand bowing out of this perfectly. There other tasks whose time I've raided for this discussion, and the backlog is starting to look pretty nasty. But it has been a good and healthy discussion. Many things have come of it. Thanks to all the participants. PS: FWIW, I'd have absolutely no objection to us adding a fifth core junctive type (perhaps CAdjunction, perhaps just CSet ;-) that has *no* associated predicate, but which implements full set semantics: my $x = set(1..3); my $y = set(1,3,5,7,9); my $n = 2; $x | $y # set(1,2,3,5,7,9) $x $y # set(1,3) $x - $y # set(2) !$x # set(none(2));-) $x $y # $x is a proper subset of $y $x = $y # $x is a subset of $y $x == $y # $x is the set $y $x ~~ $y # $x is the set $y $n $y # $n is an element of $y $n ~~ $y # $n is an element of $y set()# empty set $x.values# list of elements of set $x $x.powerset # power set of $x $x x $y # cross product of $x and $y # etc., etc. Now THAT is an even better idea than the separate Set class I was going to champion whenever I next had time for such a thing! I support this concept fully! -- Rod Adams PS - Looks like Matt gets his wish. This juggernaut of a thread is coming to a close. I'd be happy to proof his summary of it if he gives me an advanced copy.
Re: Set sigils (was: Re: Junction Values)
On Sat, Feb 19, 2005 at 01:43:57PM -0800, Ashley Winters wrote:
Instead of primary sigils, what about secondary sigils on an array to
mark it as an unordered set?
@|foo = any
@foo = all
@^foo = one # can arrays be curried arguments? hmm
@!foo = none
After all, why should scalars get all the good secondary sigils? :)
Just noting that secondary sigils aren't limited to scalars:
@*biglist = 1... ; # global @::*::biglist
has %.dictionary; # public attribute
has @:children;# private attribute
say @?BLOCK; # which blocks am I in?
{ sort @^list; } # placeholder array
%=POD{'DATA'} # filehandle for =begin DATA stream
Pm
Re: Junction Values
On Sun, 20 Feb 2005 03:17:19 -0600, [EMAIL PROTECTED] (Rod Adams) wrote:
--020209010404060902000407
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Nigel Sandever wrote:
On Sat, 19 Feb 2005 18:42:36 +1100, [EMAIL PROTECTED] (Damian Conway) wrote:
The Awesome Power of Junctions:
Well, that was one of my stumbling blocks early on. They don't really
give you the power to do anything you couldn't previously do. They just
make certain things a lot easier to do.
But I'll take a whack at giving you something non-trivial to do without
junctions:
$re1 = /^ -[x]* x -[x]* $/; # match a string with exactly one
[SNIP]
And all seven of these can be used as any stored RE can:
if $x ~~ $re6 {...};
given $x {
when $re5 {...}
when 'santa' {...}
when ($re1 | $re3) $re3 {...}
}
SNIP]
So what have we gained here? The ability to join several RE's together,
into something that still acts like a single RE. Show me the equivalent
code without junctions, and then we'll compare the power of junctions.
By the power of a single good example, you can now count me amongst the
convinced.
btw, the examples above assume the ability to store a junction. So you
either have to 'use junctions;', or convince Larry to rescind that
restriction.
Patricks's arguement that there is no real difference between a scalar that
contains a Junction and a scalar that contains a coderef or any type of ref
when
it comes to requiring the programmer to know (or test for) what the scalar
holds, was enough to convince me that no additional pragmas are required for
junctions. Though I wouldn't object to Damian's cno autothreading.
My only problem was that I couldn't see the larger benefit of them. Your
example
above is sufficient to convince that being able to encapsulate not just a set
of
data, but /required result/ of *any* operations performed using that set data
did the trick for me.
I now view the junction
my $x = any( @values );
as roughly equal to:
my $junction = bless [ @values ], 'any';
and similarly for the other three. Simplistic, but enough for my mind to make
the transition.
Using the hyper operators, you would have to re-state the desired result for
each operation, but with a junction you've encapsulated it in.
HTH.
-- Rod Adams
Thanks for taking the time to produce your good example and so carrying me
along.
njs.
--020209010404060902000407--
Examine what is said, not who speaks.
Re: Junction Values
Rod Adams [EMAIL PROTECTED] writes:
$re1 = /^ -[x]* x -[x]* $/; # match a string with exactly one
'x' in it.
$re2 = /^ -[y]* y -[y]* $/; # ditto 'y'
$re3 = /^ -[z]* z -[z]* $/; # ditto 'z'
$re7 = none($re1, $re2, $re3); # matches if there are 0 or 2+ of
each of x,y,z.
#7 I have no idea how to attack as a single RE in anything close to
approaching elegance.
Depending on your idea of elegance ... anchored zero-width negative
lookahead:
$re7 = qr/^ (?!= $re1 | $re2 | $re3 ) /x;
Oh right. Perl6. Well, if I understand $re1 correctly, I think
this is what it will look like:
$re7 = /^ !before $re1 | $re2 | $re3 /;
I still want junctions, but I also still am not quite sure how they
will behave. For instance, I wonder how this would autothread or not:
my sub f (Int $x) {
if $x {
return 0, 1, $x;
}
else {
return 0, 1;
}
}
my $j = 0 | 7;
my @a = (1, f($j), 0);
- How many elements are there in @a? 3? 5? 4|5?
- What is @a[-1]? 0? any(0)? 0|undef?
- What is @a[4]? undef? 0|undef? 0?
Naïvely, I would expect that setting of @a be equivalent to this:
my @a = (1, ([0,1]|[0,1,7]), 0);
And so from the callers perspective, f, which usually returns two
or three values, suddenly returns a single (junctive) value. New
semantics for f, courtesy of autothreading. I expect this is too
naïve. But what am I missing?
Eirik
--
All bridge hands are equally likely, but some are more equally likely
than others.
-- Alan Truscott
Re: Junction Values
On Sun, Feb 20, 2005 at 07:41:16PM +1100, Damian Conway wrote: Given this: my $x = set(1..3); my $y = set(1,3,5,7,9); my $n = 2; $x | $y # set(1,2,3,5,7,9) $x $y # set(1,3) $x - $y # set(2) !$x # set(none(2));-) I don't understand this last line, even given the context of the preceding three. Why is it none of 2, rather than none of something else? Nicholas Clark
Re: Junction Values
Rod Adams [EMAIL PROTECTED] writes: Eirik Berg Hanssen wrote: Rod Adams [EMAIL PROTECTED] writes: $re1 = /^ -[x]* x -[x]* $/; # match a string with exactly one 'x' in it. $re2 = /^ -[y]* y -[y]* $/; # ditto 'y' $re3 = /^ -[z]* z -[z]* $/; # ditto 'z' $re7 = none($re1, $re2, $re3); # matches if there are 0 or 2+ of each of x,y,z. #7 I have no idea how to attack as a single RE in anything close to approaching elegance. Depending on your idea of elegance ... anchored zero-width negative lookahead: $re7 = qr/^ (?!= $re1 | $re2 | $re3 ) /x; Whoops. For ?!=, read ?!. Now imagine the quality of my Perl6 code ... Oh right. Perl6. Well, if I understand $re1 correctly, I think this is what it will look like: $re7 = /^ !before $re1 | $re2 | $re3 /; That doesn't quite do it, but something along those lines is possible. You'd have to make sure the look ahead/behinds match to the end of the string, not just some substring. And then you'd have to put in something to actually match the string. So possible, but not straightforward in the least. $re1, $re2, and $re3 are already anchored: Covered. And it will match the empty string at pos()==0, given that the assertion is satisfied. This of course differs from a junction of three match objects, each matching the whole string at pos()=0, but that difference is in part to be expected (the point of the exercise was to avoid a junction), and in part trivial to fix: just add .*. In the general case, it will be more complex, yes, but so will the match object returned by the junctive rule. Well, enough pattern matching. Junctions on the agenda, now! ;-) Eirik -- So this is the Sword of Immortality? Huh? What's it doin' in a CRYPT?! --- John S. Novak, III, quoting an unnamed player
Re: Junction Values
NC == Nicholas Clark [EMAIL PROTECTED] writes: NC On Sun, Feb 20, 2005 at 07:41:16PM +1100, Damian Conway wrote: NC Given this: my $x = set(1..3); my $y = set(1,3,5,7,9); my $n = 2; $x | $y # set(1,2,3,5,7,9) $x $y # set(1,3) $x - $y # set(2) !$x # set(none(2));-) NC I don't understand this last line, even given the context of the NC preceding three. Why is it none of 2, rather than none of NC something else? my guess is a typo and $x should be $n. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Junction Values
Nicholas Clark wrote: On Sun, Feb 20, 2005 at 07:41:16PM +1100, Damian Conway wrote: Given this: my $x = set(1..3); my $y = set(1,3,5,7,9); my $n = 2; $x | $y # set(1,2,3,5,7,9) $x $y # set(1,3) $x - $y # set(2) !$x # set(none(2));-) I don't understand this last line, even given the context of the preceding three. Why is it none of 2, rather than none of something else? ESTUPIDDAMIAN. Should, of course be: !$x # set(none(1..3));-) Damian PS: This is also a demonstration of the awesome power of junctions: that we can specify the complement of a set without knowing its universal set!
Re: Junction Values
Eirik Berg Hanssen [EMAIL PROTECTED] writes: Rod Adams [EMAIL PROTECTED] writes: Eirik Berg Hanssen wrote: Rod Adams [EMAIL PROTECTED] writes: $re1 = /^ -[x]* x -[x]* $/; # match a string with exactly one 'x' in it. $re2 = /^ -[y]* y -[y]* $/; # ditto 'y' $re3 = /^ -[z]* z -[z]* $/; # ditto 'z' $re7 = none($re1, $re2, $re3); # matches if there are 0 or 2+ of each of x,y,z. $re7 = /^ !before $re1 | $re2 | $re3 /; That doesn't quite do it, but something along those lines is possible. You'd have to make sure the look ahead/behinds match to the end of the string, not just some substring. And then you'd have to put in something to actually match the string. So possible, but not straightforward in the least. $re1, $re2, and $re3 are already anchored: Covered. And it will match the empty string at pos()==0, given that the assertion is satisfied. This of course differs from a junction of three match objects, each matching the whole string at pos()=0, Whoops again: That would be a junction of three match objects, _none_ of which are successful. When the assertion is not satisfied, however, you will be able to inspect the match object junction's states to see how many of the $re\d matched, and in the general case, how they matched. But on the whole, I now get the impression that these match object junctions (or at least match object injunctions) would rarely be used outside boolean context. Eirik -- For every complex problem, there is a solution that is simple, neat, and wrong. -- H. L. Mencken A good plan today is better than a perfect plan tomorrow. -- Patton
Re: Junction Values
On Sun, Feb 20, 2005 at 10:46:15PM +0100, Eirik Berg Hanssen wrote: Eirik Berg Hanssen [EMAIL PROTECTED] writes: Rod Adams [EMAIL PROTECTED] writes: $re1 = /^ -[x]* x -[x]* $/; # match a string with exactly one 'x' $re2 = /^ -[y]* y -[y]* $/; # ditto 'y' $re3 = /^ -[z]* z -[z]* $/; # ditto 'z' $re7 = none($re1, $re2, $re3); # matches if there are 0 or 2+ of each of x,y,z. $re7 = /^ !before $re1 | $re2 | $re3 /; [...lots of discussion about whether the above works or not...] I think it may be even simpler than the above, no lookaheads required: $re7 = / !$re1 !$re2 !$re3 /; Pm
Re: Junction Values
Damian~ On Mon, 21 Feb 2005 08:29:40 +1100, Damian Conway [EMAIL PROTECTED] wrote: Nicholas Clark wrote: On Sun, Feb 20, 2005 at 07:41:16PM +1100, Damian Conway wrote: Given this: my $x = set(1..3); my $y = set(1,3,5,7,9); my $n = 2; $x | $y # set(1,2,3,5,7,9) $x $y # set(1,3) $x - $y # set(2) !$x # set(none(2));-) I don't understand this last line, even given the context of the preceding three. Why is it none of 2, rather than none of something else? ESTUPIDDAMIAN. Should, of course be: !$x # set(none(1..3));-) Damian PS: This is also a demonstration of the awesome power of junctions: that we can specify the complement of a set without knowing its universal set! Or one more thing to drive the mathematicians into a rage... Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Re: Junction Values
Hmm. On rereading my last message, I feel that it comes across as angry, and critical of this entire discussion or perhaps of particular participants. That was certainly not my intent and I apologize if that's how it appeared. I genuinely respect the contributions of every person on this list, and even when (as now) I strenuously disagree with the ideas expressed, I know that those contributions are sincere and offered with the best interests of Perl at heart. I still stand by every point I made in that last message, but I'm sorry that I let my frustrations leak into the discussion. Damian
Re: Junction Values
On Fri, Feb 18, 2005 at 11:31:54PM -0800, Brent 'Dax' Royal-Gordon wrote: Junctions are intended to ultimately be used in boolean tests. That's why the values of the junction have an any/all/one/none relationship. The proper data structure here is an array. (Actually, ironically enough, it's probably a set, not an array.) It's one set for any()/all()/one() and two sets for none(). Of course, if something (eg. functions) cannot be tested for equality, then we'll have to assume them to be unique from each other anyway, in which case junctions do act as arrays. [1] Note, however, that this needs to be done carefully. For example, while it doesn't really make sense for the string arguments of a call to Cprint to be junctions, the object argument is another matter entirely: #!/usr/bin/perl6 # naive tee $OUT=$OUT open( $_) for @ARGS; print or die Can't write to $!.filename: $! for *$IN;# Or however it's done this week I think it's an unary = this week, according to S04: print for =*$IN; Thanks, /Autrijus/ pgpK2a19S3Fk6.pgp Description: PGP signature
