-bits.pod
Log Message:
---
[S02] added non-junction :exists example
Also un-forgot bumping the version.
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
)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
,
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
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
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
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
; ([+] @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
= 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
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
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
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
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
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
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
...@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
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
/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
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
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
On Thu, Nov 13, 2008 at 2:24 PM, TSa [EMAIL PROTECTED] wrote:
Do I understand your question right, that you want the return
of == to be false because there is a one(1,0,1) junction? As
Duncan points out junctions are immutable values and as such
the % autothreads but the resulting values
HaloO,
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
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
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
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
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
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
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
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
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
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
- 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
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
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
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
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,
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
: - ...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 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
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
) : ||
:/ \__ __|_
|: | |\ / || | | |
.Method : Sub Block | | Inf Undef Match Junction
/|: |\ | |
/ |: | \Ref[Code]|
Rule |: | Macro
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
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
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
- 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
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
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
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
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
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
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
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
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.
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)
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
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
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
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
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
(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
) 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
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
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
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
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
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
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
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
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
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
, 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
: 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
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
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
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.
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 #
()==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
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
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
. 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
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]*
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
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
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
1 - 100 of 166 matches
Mail list logo
