Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
On Tue, 8 Feb 2005, Matt Fowles wrote: pipe dreams Juerd wondered if he could mix = and ==> in a sane way. The answer appears to be no. Once you bring in ==> you should stick with it. Huh?!? It doesn't seem to me that the answer is 'no'. In fact C<< ==> >> is supposed to be yet another operator, albeit somewhat a special one. If I got it right the answer is actually 'yes': what Larry suggested is that it would be _stylistically_ better to stick with it once it is used in the first place. Michele -- Ah, but the REAL myster is -- did Pythagoras really discourage eating beans because they resembled human testicles? Or is that another myth? I always thought it was because of their musical qualities. - Robert Israel in sci.math (slightly edited)
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
Michele Dondi wrote: On Tue, 8 Feb 2005, Matt Fowles wrote: pipe dreams Juerd wondered if he could mix = and ==> in a sane way. The answer appears to be no. Once you bring in ==> you should stick with it. Huh?!? It doesn't seem to me that the answer is 'no'. In fact C<< ==> >> is supposed to be yet another operator, albeit somewhat a special one. If I got it right the answer is actually 'yes': what Larry suggested is that it would be _stylistically_ better to stick with it once it is used in the first place. It was also a matter of precedence, as = binds more tightly than ==> so extra brackets would be required, leading to ==> being neater if you only use it in conjunction with other ==>. Which I rather liked.
= vs <== [was: Perl 6 Summary for 2005-01-31 through 2004-02-8]
On Wed, Feb 09, 2005 at 10:04:48AM +0100, Michele Dondi wrote: : On Tue, 8 Feb 2005, Matt Fowles wrote: : : > pipe dreams : > Juerd wondered if he could mix = and ==> in a sane way. The answer : > appears to be no. Once you bring in ==> you should stick with it. : : Huh?!? It doesn't seem to me that the answer is 'no'. In fact C<< ==> >> : is supposed to be yet another operator, albeit somewhat a special one. If : I got it right the answer is actually 'yes': what Larry suggested is that : it would be _stylistically_ better to stick with it once it is used in the : first place. Yes, you can certainly intermix them as long as you keep your precedence straight with parentheses. Though I suppose we could go as far as to say that = is only scalar assignment, and you have to use <== or ==> for list assignment. That would be...interesting...to say the least. For instance, it would eliminate the guessing games about whether the syntactic form of the left side indicates a list. Doubtless there would be some downsides too... Larry
Re: = vs <== [was: Perl 6 Summary for 2005-01-31 through 2004-02-8]
On Wed, 9 Feb 2005, Larry Wall wrote: Yes, you can certainly intermix them as long as you keep your precedence straight with parentheses. Though I suppose we could go as far as to say that = is only scalar assignment, and you have to use <== or ==> for list assignment. That would be...interesting...to Yes, it would indeed be interesing, but... it would also be really kinda too much! Michele -- I agree with Tore; it's sort of a Zen question. If you have to ask, it means you won't understand the answer. If you know enough to understand the answer, you won't need the question. - Joe Smith in clpmisc, "Re: Perl neq Python"
Re: = vs <== [was: Perl 6 Summary for 2005-01-31 through 2004-02-8]
Larry Wall wrote: On Wed, Feb 09, 2005 at 10:04:48AM +0100, Michele Dondi wrote: : On Tue, 8 Feb 2005, Matt Fowles wrote: : : > pipe dreams : > Juerd wondered if he could mix = and ==> in a sane way. The answer : > appears to be no. Once you bring in ==> you should stick with it. : : Huh?!? It doesn't seem to me that the answer is 'no'. In fact C<< ==> >> : is supposed to be yet another operator, albeit somewhat a special one. If : I got it right the answer is actually 'yes': what Larry suggested is that : it would be _stylistically_ better to stick with it once it is used in the : first place. Yes, you can certainly intermix them as long as you keep your precedence straight with parentheses. Though I suppose we could go as far as to say that = is only scalar assignment, and you have to use <== or ==> for list assignment. That would be...interesting...to say the least. For instance, it would eliminate the guessing games about whether the syntactic form of the left side indicates a list. Doubtless there would be some downsides too... Larry I have to say that my initial reaction to this was one of disgust, but the more I think about it, the more I am warming to the idea of having a more robust method of declaring list context vs scalar context. Issues that arise (my mind has yet to settle enough to label them "downsides"): - List assignment is way too common to inflict a three char operator on, especially one that really likes having \S around it. (But don't ask me what else to use, not much is left available.) At least, it's way too common for me. - orthogonality says that we would then need a left scalar assignment operator to mimic ==>. Linguistically, this is "Calculate all this, then stuff the result into $x". This would be very nifty when building long self-referring assignments, because the assignment appears after the expression which used the previous value, which just "flows" better. . - Would C<< @x = @y; >> then mean C<< @x := @y; >>? - Somehow, C<< %x <== %y; >> feels very, very wrong. Pluses: - I've often considered list assignment to be one of the most useful and subtle things that makes Perl Perl, especially when combined with hash/array slices. However, attempting to bring less monkish fellows up to enlightenment often encounters mental blocks. This might help, having a different syntax makes it significantly less 'magical'. (even though Magic is Good, imho) I should probably stop rambling now and get some sleep. -- Rod Adams
Pop a Hash?
Does
($k, $v) <== pop %hash;
or
($k, $v) <== %hash.pop;
make sense to anyone except me?
Since we now have an explicit concept of pairs, one could consider a
hash to be nothing but an unordered (but well indexed) list of pairs.
So, C<< pop %hash >> would be a lot like C<< each >>, except, of course,
that it deletes the pair at the same time.
If we do that, I'd also want to be able to
push %x, %y;
which would mean something like:
%x{%y.keys} <== %y{%y.keys};
but be much easier to read.
-- Rod Adams.
(And now I'm really off to bed.)
Re: Pop a Hash?
Rod Adams wrote:
Does
($k, $v) <== pop %hash;
or
($k, $v) <== %hash.pop;
make sense to anyone except me?
Makes sense to me. Although I would be more inclined to think of pop as
returning a pair - but does a pair in list context turn into a list of
key, value? If so then the above makes lots of sense.
Since we now have an explicit concept of pairs, one could consider a
hash to be nothing but an unordered (but well indexed) list of pairs.
So, C<< pop %hash >> would be a lot like C<< each >>, except, of course,
that it deletes the pair at the same time.
The only thing people might not be too pleased about is that the order
is entirely at the whim of the internal implementation of hashes. I
suppose you could say %hash.sort.pop(), but that would probably re-sort
every time and that's clearly not desirable. Working on a sorted copy is
also not particularly pleasant as memory could be a considerable problem.
If we do that, I'd also want to be able to
push %x, %y;
which would mean something like:
%x{%y.keys} <== %y{%y.keys};
but be much easier to read.
Yes, I'd like that. I find myself wanting to do things like that quite a
lot in Perl 5.
Re: Pop a Hash?
Matthew Walton <[EMAIL PROTECTED]> writes:
> Rod Adams wrote:
>> Does
>> ($k, $v) <== pop %hash;
>> or
>> ($k, $v) <== %hash.pop;
>> make sense to anyone except me?
>
> Makes sense to me. Although I would be more inclined to think of pop
> as returning a pair - but does a pair in list context turn into a list
> of key, value? If so then the above makes lots of sense.
Seeing the above, I first thought up a "pair context":
($k => $v) = %hash.pop;
However ... IIRC, in list assignment, lvalue pairs are treated as
name/value pairs, so there would be a list assignment of just one
element here. And this is still list assignment ...
Better to be explicit, I suppose:
($k, $v) = %hash.pop.kv;
>> If we do that, I'd also want to be able to
>> push %x, %y;
>> which would mean something like:
>> %x{%y.keys} <== %y{%y.keys};
>> but be much easier to read.
>
> Yes, I'd like that. I find myself wanting to do things like that quite
> a lot in Perl 5.
%x.push(%y);
If no one else writes it, I will. ;-)
Eirik
--
A free society is one where it is safe to be unpopular.
-- Adlai Stevenson
Re: = vs <== [was: Perl 6 Summary for 2005-01-31 through 2004-02-8]
On Wed, 2005-02-09 at 06:04, Rod Adams wrote: > Larry Wall wrote: > >Yes, you can certainly intermix them as long as you keep your > >precedence straight with parentheses. Though I suppose we could go > >as far as to say that = is only scalar assignment, and you have to > >use <== or ==> for list assignment. That would be...interesting...to > >say the least. For instance, it would eliminate the guessing games > >about whether the syntactic form of the left side indicates a list. > >Doubtless there would be some downsides too... > Issues that arise (my mind has yet to settle enough to label them > "downsides"): > > - List assignment is way too common to inflict a three char operator on, > especially one that really likes having \S around it. (But don't ask me > what else to use, not much is left available.) At least, it's way too > common for me. Yeah, well I always thought []= made more sense anyway :) DISCLAIMER: I've been off perl6-* for a bit, and might not have my syntax right here. Sorry. There are a few ways to short-cut that. First off, you could (either in-core, or in a module) set this up: @x.(@y); This is legit syntax today AFAIK, but has no plausible meaning that I can figure out. It's still 3 characters, but eliminates any whitespace ambiguity. Ok, so the next method would be: [EMAIL PROTECTED] = [EMAIL PROTECTED]; What does that do today? Is it legit? Again, 3 chars, but no ambiguity So hold on to your socks... what about: @x @y; Hey, if you're going to Huffman the syntax... But stay with me. This is simply a matter of verbing the @x, which would have the same effect as: @x.(@y); and we discussed what that would mean, above. This has some nice ramifications: my @x 1, 2, 3; # Initialize @x with list of numbers my @x foo(); # enforce scalar context on foo() and store @x @y @z; # Chaining -- â 781-324-3772 â [EMAIL PROTECTED] â http://www.ajs.com/~ajs
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
--- Matt Fowles <[EMAIL PROTECTED]> wrote: >Logic Programming in Perl 6 > Ovid asked what logic programming in perl 6 would look like. No > answer > yet, but I suppose I can pick the low hanging fruit: as a > limiting case > you could always back out the entire perl 6 grammar and insert > that of > prolog. I dunno about that. The predicate calculus doesn't exactly translate well to the sort of programming that Perl 6 is geared for. I don't think it's a matter of redefining a grammar. Maybe unification can be handled with junctions, but backtracking? I am thinking that some serious work down at the Parrot level would be necessary, but I would be quite happy to be corrected :) Cheers, Ovid = If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Logic programming in Perl 6
On Wed, 2005-02-09 at 14:57, Ovid wrote: > --- Matt Fowles <[EMAIL PROTECTED]> wrote: > > >Logic Programming in Perl 6 > > Ovid asked what logic programming in perl 6 would look like. No > > answer yet, but I suppose I can pick the low hanging fruit: as a > > limiting case > > you could always back out the entire perl 6 grammar and insert > > that of prolog. > > I dunno about that. The predicate calculus doesn't exactly translate > well to the sort of programming that Perl 6 is geared for. I don't > think it's a matter of redefining a grammar. Maybe unification can be > handled with junctions, but backtracking? The grammar is easy (well, as easy as any high-level programming language grammar, and easier than some), and the rest could be implemented in one of two ways: write a Prolog::Engine module with the whole thing from scratch or linked in from some existing Prolog interpreter; or layer it all on top of the Perl 6 rules engine. The latter would be possible, but indescribably gross. -- â 781-324-3772 â [EMAIL PROTECTED] â http://www.ajs.com/~ajs
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
On Wed, Feb 09, 2005 at 11:57:17AM -0800, Ovid wrote: : --- Matt Fowles <[EMAIL PROTECTED]> wrote: : : >Logic Programming in Perl 6 : > Ovid asked what logic programming in perl 6 would look like. No : > answer : > yet, but I suppose I can pick the low hanging fruit: as a : > limiting case : > you could always back out the entire perl 6 grammar and insert : > that of : > prolog. : : I dunno about that. The predicate calculus doesn't exactly translate : well to the sort of programming that Perl 6 is geared for. I don't : think it's a matter of redefining a grammar. Maybe unification can be : handled with junctions, but backtracking? I am thinking that some : serious work down at the Parrot level would be necessary, but I would : be quite happy to be corrected :) Depending on what level you write your engine, the backtracking can be handled either with exceptions or, more generally, with continuations. I personally think that unification is the hard part, but then it's possible I'm just not in the right brainstate yet with regard to junctions. I tend to see junctions as sets of scalar values rather than sets of list values, but maybe that's just the Pooh coming out in me. I was, in fact, thinking about Prolog unification just a bit when I cargo-culted in the [$head, [EMAIL PROTECTED] form of parameter parsing, but I don't profess to understand all of the implications. Basically, logic programming is one of those things I'm not trying to solve directly in Perl 6--I'm just trying to get Perl 6 close enough that the real experts can have a go at it without having too many roadblocks thrown in their way. That's true not only for LP, but also for FP, MP, XP, AOP, DBC, and hopefully several other varieties of alphabet soup yet to be invented. Larry
Re: [rbw3@cse.nau.edu: Re: Junctive puzzles.]
On 2005.02.08.19.07, Matt Fowles wrote: | Brock~ | | | On Tue, 8 Feb 2005 12:08:45 -0700, Brock <[EMAIL PROTECTED]> wrote: | > | > Hm. I take that back... it was a silly comment to make and not very | > mathematically sound. Sorry. | > | > --Brock | > | > - Forwarded message from Brock <[EMAIL PROTECTED]> - | > | > (a < b < c) ==> (a < b) and (b < c) and (a < c) | > | | I disagree, I think that that is both mathematically sounds and | perfectly logical. Yes... but perhaps instead of the above transform we should just make sure that < is transitive in the first place... so that no matter what if a
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
On Wed, Feb 09, 2005 at 11:57:17AM -0800, Ovid wrote: > --- Matt Fowles <[EMAIL PROTECTED]> wrote: > > >Logic Programming in Perl 6 > > Ovid asked what logic programming in perl 6 would look like. No > > answer > > yet, but I suppose I can pick the low hanging fruit: as a > > limiting case > > you could always back out the entire perl 6 grammar and insert > > that of > > prolog. > > I dunno about that. The predicate calculus doesn't exactly translate > well to the sort of programming that Perl 6 is geared for. I don't > think it's a matter of redefining a grammar. Maybe unification can be > handled with junctions, but backtracking? I am thinking that some > serious work down at the Parrot level would be necessary, but I would > be quite happy to be corrected :) > > Cheers, > Ovid This kind of ties in to the 4 < $x < 2 issue with junctions. As long as junctions retain state to determine such relations correctly, they should be able to be used for logic programming too. I'd kind of like there to be a version of junctions that acted as a Quantum Superposition. So: $x = ( 1|3|5 ); 4 < $x < 2; would keep track of both the truth values and the the corresponding subsets of the junction. So, as the interpretor evaluated 4 < $x it would give a result of (true=>(5),false=>(1|3)); then the evaluation of $x < 2 would modify that to (true=>(),false=>(1|3|5)). That type of junction would have the same result of false even if the statement was written as: 4 < $x and $x < 2; That would be a good thing, because I don't think that the chain comparisons are the only place where juctions will give ridiculous answers because multually exclusive subsets of the junction value are found to fulfil different conditions in a sequence of steps. Unfortunately, doing this "properly" would lead to having the program form into multiple processes and would lead to problems with irreversible actions that occur while the superposition is still multi-determinate. The basic problem is that a junction does not work well with boolean operations, because the answer is usually "sometimes yes and sometimes no" and until you resolve which of those is the one you want, you have to proceed with both conditions. The all/any/none/one (but we're missing not-all and all-but-one from a full list of operators) give a local scale resolution to this discrepancy, but sometimes you want a larger scale selection. If code is being evaluated tentatively (we don't know whether the current member of the junction will be considered a true element of the result) you really need to limt your actions to side-effect-free operations. I'm afraid that I have too much fluff in my very little brain to have a good solution to this. --
Re: Junctive puzzles.
Matt Fowles wrote:
All~
On Tue, 08 Feb 2005 17:51:24 +0100, Miroslav Silovic <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
Well, we see the same kind of thing with standard interval arithmetic:
(-1, 1) * (-1, 1) = (-1, 1)
(-1, 1) ** 2 = [0, 1)
The reason that junctions behave this way is because they don't
collapse. You'll note the same semantics don't arise in
Quantum::Entanglement (when you set the "try to be true" option).
But you can force a collapse like this:
my $x = 4 < $j;
if $j < 2 { say "never executed" }
By which I mean:
my $x = 4 < $j;
if $x < 2 { say "never executed" }
Uh, I'm not sure this does what I think you wanted to say it does. ;) $x
is a boolean, unless < returns a magical object... in which case, the
magical part of $x ought to be a reference to the original $j, no?
I'm wonding if we should allow a method that returns a junction that is
allowed to collapse the original:
if 4 < $j.collapse and $j.collapse < 2 {
say "never executed";
}
But that's probably not a good idea, just by looking at the
implementation complexity of Quantum::Entanglement. People will just
have to learn that junctions don't obey ordering laws.
Well, I suspect that junctions will have to be references and just
collapse every time. Observe:
my $x = any(1, 2, 3, 4, 5);
print "SHOULD NOT RUN" if (is_prime($x) && is_even($x) && $x > 2);
This only works if $x collapses. Same for matching junctioned strings:
my $a = any ();
print "Boo!" if $a ~ /a/ and $a ~ /b/ and $a ~ /c/;
(perhaps I meant to use ~~, I don't quite remember :) )
Either way, autocollapsing juntions is a Good Thing IMHO, and the only
remaining confusion (to go back to my initial post) is that the only
case that doesn't work is when you instance a junction twice as a pair
of same literals:
print "SUCCESS, unfortunately" if (is_prime(any(1, 2, 3, 4, 5)) &&
is_even(any(1, 2, 3, 4, 5)) && any(1, 2, 3, 4, 5) > 2);
Hope I'm making sense. Been a hard day at work. ;)
What if junctions collapsed into junctions of the valid options under
some circumstances, so
my $x = any(1,2,3,4,5,6,7);
if(is_prime($x) # $x = any(2,3,5,7)
and is_even($x) # $x = any(2)
and $x > 2) # $x = any()
This is Just Wrong, IMO. How confusing is it going to be to find that
calling is_prime($x) modifies the value of $x despite it being a very
simple test operation which appears to have no side effects?
As far as I can see it, in the example, it's perfectly logical for
is_prime($x), is_even($x) and $x > 2 to all be true, because an any()
junction was used. If an all() junction was used it would be quite a
different matter of course, but I would see is_prime() called on an
any() junction as returning true the moment it finds a value inside that
junction which is prime. It doesn't need to change $x at all.
In a way, you're sort of asking 'has $x got something that has the
characteristics of a prime number?' and of course, $x has - several of
them, in fact (but the count is not important).
Re: Junctive puzzles.
All~
On Wed, 09 Feb 2005 22:48:00 +, Matthew Walton
<[EMAIL PROTECTED]> wrote:
> Matt Fowles wrote:
> > All~
> >
> > On Tue, 08 Feb 2005 17:51:24 +0100, Miroslav Silovic <[EMAIL PROTECTED]>
> > wrote:
> >
> >>[EMAIL PROTECTED] wrote:
> >>
> >>
> Well, we see the same kind of thing with standard interval arithmetic:
>
> (-1, 1) * (-1, 1) = (-1, 1)
> (-1, 1) ** 2 = [0, 1)
>
> The reason that junctions behave this way is because they don't
> collapse. You'll note the same semantics don't arise in
> Quantum::Entanglement (when you set the "try to be true" option).
>
> But you can force a collapse like this:
>
> my $x = 4 < $j;
> if $j < 2 { say "never executed" }
>
>
> >>>
> >>>By which I mean:
> >>>
> >>> my $x = 4 < $j;
> >>> if $x < 2 { say "never executed" }
> >>>
> >>>
> >>>
> >>
> >>Uh, I'm not sure this does what I think you wanted to say it does. ;) $x
> >>is a boolean, unless < returns a magical object... in which case, the
> >>magical part of $x ought to be a reference to the original $j, no?
> >>
> >>
> I'm wonding if we should allow a method that returns a junction that is
> allowed to collapse the original:
>
> if 4 < $j.collapse and $j.collapse < 2 {
> say "never executed";
> }
>
> But that's probably not a good idea, just by looking at the
> implementation complexity of Quantum::Entanglement. People will just
> have to learn that junctions don't obey ordering laws.
>
>
> >>
> >>Well, I suspect that junctions will have to be references and just
> >>collapse every time. Observe:
> >>
> >>my $x = any(1, 2, 3, 4, 5);
> >>print "SHOULD NOT RUN" if (is_prime($x) && is_even($x) && $x > 2);
> >>
> >>This only works if $x collapses. Same for matching junctioned strings:
> >>
> >>my $a = any ();
> >>print "Boo!" if $a ~ /a/ and $a ~ /b/ and $a ~ /c/;
> >>
> >>(perhaps I meant to use ~~, I don't quite remember :) )
> >>
> >>Either way, autocollapsing juntions is a Good Thing IMHO, and the only
> >>remaining confusion (to go back to my initial post) is that the only
> >>case that doesn't work is when you instance a junction twice as a pair
> >>of same literals:
> >>
> >>print "SUCCESS, unfortunately" if (is_prime(any(1, 2, 3, 4, 5)) &&
> >>is_even(any(1, 2, 3, 4, 5)) && any(1, 2, 3, 4, 5) > 2);
> >>
> >>Hope I'm making sense. Been a hard day at work. ;)
> >
> >
> > What if junctions collapsed into junctions of the valid options under
> > some circumstances, so
> >
> > my $x = any(1,2,3,4,5,6,7);
> > if(is_prime($x) # $x = any(2,3,5,7)
> > and is_even($x) # $x = any(2)
> > and $x > 2) # $x = any()
>
> This is Just Wrong, IMO. How confusing is it going to be to find that
> calling is_prime($x) modifies the value of $x despite it being a very
> simple test operation which appears to have no side effects?
>
> As far as I can see it, in the example, it's perfectly logical for
> is_prime($x), is_even($x) and $x > 2 to all be true, because an any()
> junction was used. If an all() junction was used it would be quite a
> different matter of course, but I would see is_prime() called on an
> any() junction as returning true the moment it finds a value inside that
> junction which is prime. It doesn't need to change $x at all.
>
> In a way, you're sort of asking 'has $x got something that has the
> characteristics of a prime number?' and of course, $x has - several of
> them, in fact (but the count is not important).
Soemtimes, although frequently I will check for preconditions at the
begining of a function. After I finished checking for them, I expect
to be able to do stuff assuming them without anyworry of exceptions or
anything else. In these cases I am using conditionals to filter
input, which I imagine is a fairly common case...
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-???
Re: Junctive puzzles.
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Luke
Palmer) wrote:
>Well, we see the same kind of thing with standard interval arithmetic:
>[...]
It didn't bother me that junctions weren't ordered transitively.
(Ordering had better work transitively for ordinary numbers, but
junctions aren't numbers.) Yes, the 4<(0|6)<2 thing doesn't quite
DWIM, but maybe I should just mean something else.
Except then I started thinking about why, and I decided that it
*should* DWEveryoneM. Funny things that aren't numbers can still be
ordered intransitively, but the reason that this doesn't work the way
we want is not so much because junctions are something funny, but
because < is something funny.
That is, xhttp://groups-beta.google.com/group/perl.perl6.language/browse_thread/th
read/41b18e5920ab2d78/4b24a002ab4ff9c9>
Quoting from the first message in that thread:
>If a boolean operation is applied in non-boolean context to a
>junction, it will return a junction of only the values for which the
>condition evaluated true. [...]
>
>* Junctions discard Cs on-sight (i.e. C can never be a
> member of a junction).
>* Comparison operators return C if they fail, and their
> left-hand side "C" if they succeed.
>* Comparison operators are right-associative.
Oops, my example above assumed < was left-associative and returned
its right-hand side. But doesn't flipping it around that way solve
this:
>Unfortunately, the last change clobbers the left-short-circuiting
>behavior of comparison operators.
or are there funny edge cases or something that I'm not seeing?
Anyway, the above-cited thread presents two versions of junctions and
comparative operators, and I prefer the Lucian interpretation to the
Damianian. It seems a bit more mathematical and a bit less
specially-cased; both good things in my book.
>But you can force a collapse like this:
>my $x = 4 < $j;
>if $x < 2 { say "never executed" }
Because then we're explicitly taking the result of the first
comparison and applying it to the second. Which is what 4<$j<2 ought
to mean anyway. I think Autrijus's solution for Pugs is to treat <
as list-associative (with a between[-like] function as the list op),
but I'm not sure how that works when you try to mix different
comparative operators.
If every boolean function returns the junctive elements that make it
true, then they can be chained indiscriminately:
is_even(is_prime(1|2|3|4|5))>2
means is_even(2|3|5)>2
means (2)>2
means false.
Incidentally, is there a way to decompose a junction? Something like
a .conjunctions method that returns a list of all the conjunctive
elements (if it isn't a conjunction, then it would return a single
element which is the whole thing).
$petticoat=(1 | 2 | 3 | (4&5));
$petticoat.conjunctions; # list containing (1|2|3|(4&5))
$petticoat.disjunctions; # list containing 1, 2, 3, (4&5)
($petticoat.disjunctions)[-1].conjunctions;# list 4, 5
- David "guilty by list association" Green
