On Junctions
The following arose out of a discussion on #perl6. Junctions are new and
different from anything I have encountered, but I cant get rid of the
feeling that there needs to be some more flexibility in their use to
make them a common programming tool.
Background: Imagine a hand of cards. Cards may be Ace, Two, Three. Ace
having either the values 1 or 11, depending on context, the other cards
their face value. Sums of a hand over 21 are invalid.
Hands with multiple junctions become interesting, eg.,
p: Ace, Two, Ace
d: Ace, Three, Ace
Given that Ace has a value of 1 or 11 depending on context, it would
seem natural to use a junction. Hence the two hands can be expressed as:
@p = 1|11, 2, 1|11;
@d = 1|11, 3, 1|11;
If we use [+] to add these, we get
$p = [+] @p; say $p.perl; # any(any(4,14),any(14,24))
$d = [+] @d; say $d.perl; #any(any(5,15),any(15,25))
Since the values of 24 & 25 are greater than 21, they must be eliminated
from consideration.
What we want is for hand @d to beat hand @p because 15 > 14
On #perl6, rouso, masak and moritz_ explained that I am incorrectly
thinking about junctions as sets and that for this task I should be
using another perl idiom, namely lists. Something like:
moritz_ rakudo: ([1,11], 3, [1,11]).reduce({@($^a) X+ @($^b)})
p6eval rakudo bb22e0: RESULT«[5, 15, 15, 25]»
Then the out-of-limit values (in the above case 25) can be stripped off
using grep, viz.,
# here we have ([1,11],3,[1,11]) instead of (1|11, 3, 1|11)
my @dlist = grep { $_ < 21 } ([1,11], 3, [1,11]).reduce({@($^a) X+ @($^b)});
Then the two lists (do the same for @p) can be compared by a junction
comparison of the form
if any(@plist) > all(@dlist) { say 'p wins' };
The problem is not just that [+] @p produces a junction with undesired
(>21) eigenstates, but that the [+] @d produces a junction of the form
any(any(5,15),any(15,25)) which should collapse to any(5,15,25)
whereas we want a junction of the form
all(5,15,25)
After the #perl6 conversation, I thought some more. A junction is a neat
way of expressing the hand, but the junction needs to be converted to a
list to do some processing, and then the lists are compared using junctions.
I think (I might be wrong) that the conversion from a junction to a list
is specified by the .eigenstates method, but it doesn't seem to
completely flatten a junction yet - it produces the
any(any(4,14),any(14,24)) output shown above.
So my questions to the language list are:
a) Am I trying to fit a square peg in a round hole by applying junctions
to this sort of problem? If so, would it be possible to explain what the
limits are to the junction approach, or another way of expressing this
question: what sort of problems should junctions be applied to?
b) Why would it be "wrong" to have a method for eliminating eigenstates
from a junction? (The answer to this might naturally arise out of the
answer to a). However, ...
In a wider context, I would conjecture that some algorithms to which
junctions could be applied would be optimised if some states could be
eliminated, a bit like tree-pruning optimisations that eliminate paths
which can never produce a correct answer. Consequently, providing a
filtering method would increase the usefulness of the junction as a
programming tool. Perhaps
$new-junction = $old-junction.grep({ $_ <= 21 }); # not sure if the
parens are needed here
c) On junction algebra, am I wrong or is always true that a junction of
the form
any('x','y','z', any('foo','bar'), 1, 2, 3) should collapse to
any('x','y','z','foo','bar',1,2,3)
In other words, if an 'any' junction is contained in an outer 'any', the
inner 'any' can be factored out?
This would eliminate the nested junctions produced by .eigenstates
d) Am I right in thinking this is also true for nested 'all' junctions? viz.
all(1,2,3,all('foo', 'bar')) collapses to all(1,2,3,'foo','bar')
e) Conjecture: This true of all junction types, eg.,
junc(..., junc(...)) == junc(..., ...)
f) Would it be possible to have a means to coerce an 'any' junction into
an 'all' junction or vice versa? eg.
my $old-junction = 1|2|3; my $new-junction = all{$old-junction}; say
$old-junction.perl
# all(1,2,3)
Using () creates a new junction all(any(1,2,3))
{} are undefined for junctions.
If my suggestions prove acceptable, then for my problem I would have:
# @p & @d get defined as arrays of junctions, eg.
my @p=1|11,2,1|11;
my @d=1|11,3,1|11;
#later
my $p = ([+] @p).grep { $_ < 21 };
my $d = ([+] @d).grep { $_ < 21 };
if $p > all{$d} { say 'p wins' } else { say 'd wins' };
Richard (finanalyst)
On Sets (Was: Re: On Junctions)
Em Sex, 2009-03-27 às 13:36 +0300, Richard Hainsworth escreveu: > On #perl6, rouso, masak and moritz_ explained that I am incorrectly > thinking about junctions as sets and that for this task I should be > using another perl idiom, namely lists. Sorry for not taking each individual point on your mail, but I think this basically narrows down to the fact that we need some more definitions of what kinds of things we would do with sets. The thing is that junctions are so cool that people like to use it for more things than it's really usefull (overseeing that junctions are too much powerfull for that uses, meaning it will lead to unexpected behaviors at some point). So I get that we do need some cool support for sets as well, I mean... no collapsing, no autothreading... but maybe some specific behaviors... taking the blackjack example... # using the set function as illustration only... my @hand = set(1,11),3,set(1,11); my $sum = [+] @hand; This operation could use some magic so $sum could become set(5,15,25) Where it doesn't autothread, nor collapses... but it still provides the DWIMmery people like so much in junctions... So... which magic happened here? 1 - multi infix:<+>(Set $set, Num $a) This would return another set, with each value of $set summed with $a. 2 - multi infix:<+>(Set $a, Set $b) This would return another set, with $a.values X+ $b.values, already removing duplicated values, as expected from a set. So... what do you think? daniel
Re: On Sets (Was: Re: On Junctions)
Em Sex, 2009-03-27 às 08:57 -0300, Daniel Ruoso escreveu:
> So I get that we do need some cool support for sets as well, I mean...
> no collapsing, no autothreading... but maybe some specific behaviors...
As an aditional idea...
multi infix:<⋃>(Set $a, Set $b) {...}
multi infix:<⋂>(Set $a, Set $b) {...}
...as well as the rest of the set theory...
daniel
Re: On Sets (Was: Re: On Junctions)
>From a high-level perspective, the blackjack example seems perfect for
junctions. An Ace isn't a set of values - its one or the other at a
time. It seems to me if you can't make it work with junctions - f you
have to use sets instead - then there's something wrong with the
implementation of junctions.
On 3/27/09, Daniel Ruoso wrote:
> Em Sex, 2009-03-27 às 08:57 -0300, Daniel Ruoso escreveu:
>> So I get that we do need some cool support for sets as well, I mean...
>> no collapsing, no autothreading... but maybe some specific behaviors...
>
> As an aditional idea...
>
> multi infix:<⋃>(Set $a, Set $b) {...}
> multi infix:<⋂>(Set $a, Set $b) {...}
> ...as well as the rest of the set theory...
>
> daniel
>
>
--
Sent from my mobile device
Mark J. Reed
Re: On Sets (Was: Re: On Junctions)
Em Sex, 2009-03-27 às 09:17 -0400, Mark J. Reed escreveu: > From a high-level perspective, the blackjack example seems perfect for > junctions. An Ace isn't a set of values - its one or the other at a > time. It seems to me if you can't make it work with junctions - f you > have to use sets instead - then there's something wrong with the > implementation of junctions. It would be a junction if the only question was "is it bigger than 21?"... but that is not the case, it looks more like... Given S as the set of possible sums, Given V as a subset of S where < 21 Given I as a subset of S where > 21 If V is empty, Define X as the minimum value of I Else, Define X as the maximum value in V Which really looks like set operations... daniel
Re: On Sets (Was: Re: On Junctions)
Mark J. Reed wrote: > From a high-level perspective, the blackjack example seems perfect for > junctions. An Ace isn't a set of values - its one or the other at a > time. It seems to me if you can't make it work with junctions - f you > have to use sets instead - then there's something wrong with the > implementation of junctions. That seems as naiive as saying "regular expressions are for parsing text, and if you can't parse XML with regular expressions, there's something wrong with them" . Leaving aside that Perl 6 regexes do parse XML ;-), we could ask ourselves why junctions aren't suited. The answer is that an any() junction represents just what it says - a conjunction of *any* values, not some of the any values. The example would perfectly work if there was nothing to filter out. You'd need 'some-of-any' junction here, which we don't support. Cheers, Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: On Sets (Was: Re: On Junctions)
On Fri, Mar 27, 2009 at 10:27 AM, Moritz Lenz
wrote:
> Mark J. Reed wrote:
>> From a high-level perspective, the blackjack example seems perfect for
>> junctions. An Ace isn't a set of values - its one or the other at a
>> time. It seems to me if you can't make it work with junctions - f you
>> have to use sets instead - then there's something wrong with the
>> implementation of junctions.
>
> That seems as naiive as saying "regular expressions are for parsing
> text, and if you can't parse XML with regular expressions, there's
> something wrong with them" .
Well, I was being intentionally "naive". As I said, looking down from
above. In thinking about examples for explaining junctions, this one
seems a natural fit.
> Leaving aside that Perl 6 regexes do parse XML ;-)
So do Perl 5 ones - since they're not true formal regexes, but have
more power to e.g. match balanced tags. Plus of course you wouldn't
normally try to write one regex to match an XML document; there'd be
wrapper logic.
Now if you actually parse XML that way, you're being quite silly.
It's far from the best approach. But while maybe junctions aren't
the best approach to the Blackjack problem, either, it seems less
clear to me. Maybe that's just because I have less experience with
junctions.
> The answer is that an any() junction represents just what it says - a
> conjunction of *any*
> values,not some of the any values. The example would perfectly work if there
> was nothing to filter out. You'd need 'some-of-any' junction here, which
> we don't support.
So at the moment you have to explicitly extract the eigenstates you're
interested in, and then construct new junctions from them. Something
like this:
some($d) < 21 && some($p) < 21 && any(grep { $_ < 21 }
$d.eigenstates}) > all(grep { $_ < 21 } $p.eigenstates)
But it still seems that junctions let you do this more cleanly than
sets. Or maybe P6 Sets are more powerful than I think? Given two
junctions $d and $p, just adding $d + $p gives you all the possible
sums of the eigenstates. Given two sets D and P, is there an equally
simple op to generate { d + p : d ∈ D, p ∈ } ?
--
Mark J. Reed
Re: On Sets (Was: Re: On Junctions)
On Fri, Mar 27, 2009 at 11:45 AM, Mark J. Reed wrote:
> Given two
> junctions $d and $p, just adding $d + $p gives you all the possible
> sums of the eigenstates. Given two sets D and P, is there an equally
> simple op to generate { d + p : d ∈ D, p ∈ } ?
Dropped a P there - should be { d + p : d ∈ D, p ∈ P }
--
Mark J. Reed
Re: deciphering infix:
On 2009-Mar-26, at 10:50 pm, Patrick R. Michaud wrote:
But what to do with something like C< 3 cmp '3' >, or any
infix: where the operands are of differing types? Do we
constrain C to only work on similarly-typed operands (in which
case my sort above would fail), or am I overlooking something obvious?
Failing makes sense to me (you can't compare apples to oranges, at
least not without explicitly saying you want compare them only as
coerced to general Fruit types). The other way I can think of that
might be useful practically is to compare first by type, then by
value; but that should probably be a different operation.
say sort { $^a.WHAT leg $^b.WHAT || $^a cmp $^b }, "a", 1, "b",
2 , "c", 3, "d", 4;
-David
Re: On Junctions
Richard Hainsworth wrote:
The following arose out of a discussion on #perl6. Junctions are new and
different from anything I have encountered, but I cant get rid of the
feeling that there needs to be some more flexibility in their use to
make them a common programming tool.
I strongly agree with you, but Larry has repeatedly said that he wants
to view Junctions as lexical sugar rather than as a powerful programming
tool. So I'm thinking that we'll need to experiment with modules before
anything gets admitted to the core language.
If my suggestions prove acceptable, then for my problem I would have:
# @p & @d get defined as arrays of junctions, eg.
my @p=1|11,2,1|11;
my @d=1|11,3,1|11;
#later
my $p = ([+] @p).grep { $_ < 21 };
my $d = ([+] @d).grep { $_ < 21 };
if $p > all{$d} { say 'p wins' } else { say 'd wins' };
I think that the all{..} notation is a little too subtle, and somewhat
clumsy (what if there are "one" or "none" junctions in $d? do you want
to splat them all?).
The way I'd view this (before optimization) is:
my $p = (reverse 1..21).first: { $_ == [+] @p };
my $d = (reverse 1..21).first: { $_ == [+] @d };
if! $p{ say "player bust" }
elsif ! $d{ say "dealer bust" }
elsif $p > $d { say "player wins" }
else { say "dealer wins" }
If this is the structure of the problem, the question then becomes how
to move from this brute force implementation to something more elegant
(analytical).
I discuss this on http://dave.whipp.name/sw/perl6/perl6_xmas_2008.html.
I've revised my ideas a little since then (by proposing a more general
grep metaoperator "G[op]" that has applicability beyond junctions) but
the basic concepts mesh with yours, I think.
Re: deciphering infix:
In the case of strings and numbers, I'd recommend using leg instead of cmp - that is, coerce both items to strings, then compare the strings. But as far as cmp goes, "3 cmp '3'" should fail because a number isn't a string. -- Jonathan "Dataweaver" Lang
r26016 - docs/Perl6/Spec
Author: pmichaud Date: 2009-03-27 20:45:51 +0100 (Fri, 27 Mar 2009) New Revision: 26016 Modified: docs/Perl6/Spec/S05-regex.pod Log: [S05]: Correct typo "by use if" ==> "by use of" Modified: docs/Perl6/Spec/S05-regex.pod === --- docs/Perl6/Spec/S05-regex.pod 2009-03-27 18:04:06 UTC (rev 26015) +++ docs/Perl6/Spec/S05-regex.pod 2009-03-27 19:45:51 UTC (rev 26016) @@ -785,7 +785,7 @@ returned as part of the C object but is not returned as part of the abstract object. Since the abstract object usually represents the top node of an abstract syntax tree, the abstract object -may be extracted from the C object by use if the C<.ast> method. +may be extracted from the C object by use of the C<.ast> method. A second call to C overrides any previous call to C.
Re: On Junctions
On Fri, Mar 27, 2009 at 10:39 AM, Dave Whipp wrote:
> Richard Hainsworth wrote:
>>
>> The following arose out of a discussion on #perl6. Junctions are new and
>> different from anything I have encountered, but I cant get rid of the
>> feeling that there needs to be some more flexibility in their use to make
>> them a common programming tool.
>
> I strongly agree with you, but Larry has repeatedly said that he wants to
> view Junctions as lexical sugar rather than as a powerful programming tool.
> So I'm thinking that we'll need to experiment with modules before anything
> gets admitted to the core language.
Maybe you could have something like a filter function that takes a
junction and a test condition and returns a junction of those
eigenstates from the original one that passed the test. You could
then handle the Blackjack problem by saying something to the effect
of:
$p = [+] @p;
$d = [+] @d;
if $p <= 21 { # Could the total be 21 or less?
$p where= { $_ <= 21 } #[ infix: filters the junction
according to the given criteria. ]
if $p > $d { say "you won!" }
} else { say "you went over." }
--
Jonathan "Dataweaver" Lang
Re: On Junctions
Richard Hainsworth wrote:
The following arose out of a discussion on #perl6. Junctions are new
and different from anything I have encountered, but I cant get rid of
the feeling that there needs to be some more flexibility in their use
to make them a common programming tool.
Background: Imagine a hand of cards. Cards may be Ace, Two, Three. Ace
having either the values 1 or 11, depending on context, the other
cards their face value. Sums of a hand over 21 are invalid.
Hands with multiple junctions become interesting, eg.,
p: Ace, Two, Ace
d: Ace, Three, Ace
Given that Ace has a value of 1 or 11 depending on context, it would
seem natural to use a junction. Hence the two hands can be expressed as:
@p = 1|11, 2, 1|11;
@d = 1|11, 3, 1|11;
If we use [+] to add these, we get
$p = [+] @p; say $p.perl; # any(any(4,14),any(14,24))
$d = [+] @d; say $d.perl; #any(any(5,15),any(15,25))
Since the values of 24 & 25 are greater than 21, they must be
eliminated from consideration.
What we want is for hand @d to beat hand @p because 15 > 14
On #perl6, rouso, masak and moritz_ explained that I am incorrectly
thinking about junctions as sets and that for this task I should be
using another perl idiom, namely lists. Something like:
moritz_ rakudo: ([1,11], 3, [1,11]).reduce({@($^a) X+ @($^b)})
p6eval rakudo bb22e0: RESULT«[5, 15, 15, 25]»
Then the out-of-limit values (in the above case 25) can be stripped
off using grep, viz.,
# here we have ([1,11],3,[1,11]) instead of (1|11, 3, 1|11)
my @dlist = grep { $_ < 21 } ([1,11], 3, [1,11]).reduce({@($^a) X+
@($^b)});
Then the two lists (do the same for @p) can be compared by a junction
comparison of the form
if any(@plist) > all(@dlist) { say 'p wins' };
The problem is not just that [+] @p produces a junction with undesired
(>21) eigenstates, but that the [+] @d produces a junction of the form
any(any(5,15),any(15,25)) which should collapse to any(5,15,25)
whereas we want a junction of the form
all(5,15,25)
After the #perl6 conversation, I thought some more. A junction is a
neat way of expressing the hand, but the junction needs to be
converted to a list to do some processing, and then the lists are
compared using junctions.
I think (I might be wrong) that the conversion from a junction to a
list is specified by the .eigenstates method, but it doesn't seem to
completely flatten a junction yet - it produces the
any(any(4,14),any(14,24)) output shown above.
So my questions to the language list are:
a) Am I trying to fit a square peg in a round hole by applying
junctions to this sort of problem? If so, would it be possible to
explain what the limits are to the junction approach, or another way
of expressing this question: what sort of problems should junctions be
applied to?
b) Why would it be "wrong" to have a method for eliminating
eigenstates from a junction? (The answer to this might naturally arise
out of the answer to a). However, ...
In a wider context, I would conjecture that some algorithms to which
junctions could be applied would be optimised if some states could be
eliminated, a bit like tree-pruning optimisations that eliminate paths
which can never produce a correct answer. Consequently, providing a
filtering method would increase the usefulness of the junction as a
programming tool. Perhaps
$new-junction = $old-junction.grep({ $_ <= 21 }); # not sure if the
parens are needed here
c) On junction algebra, am I wrong or is always true that a junction
of the form
any('x','y','z', any('foo','bar'), 1, 2, 3) should collapse to
any('x','y','z','foo','bar',1,2,3)
In other words, if an 'any' junction is contained in an outer 'any',
the inner 'any' can be factored out?
This would eliminate the nested junctions produced by .eigenstates
d) Am I right in thinking this is also true for nested 'all'
junctions? viz.
all(1,2,3,all('foo', 'bar')) collapses to all(1,2,3,'foo','bar')
e) Conjecture: This true of all junction types, eg.,
junc(..., junc(...)) == junc(..., ...)
f) Would it be possible to have a means to coerce an 'any' junction
into an 'all' junction or vice versa? eg.
my $old-junction = 1|2|3; my $new-junction = all{$old-junction}; say
$old-junction.perl
# all(1,2,3)
Using () creates a new junction all(any(1,2,3))
{} are undefined for junctions.
If my suggestions prove acceptable, then for my problem I would have:
# @p & @d get defined as arrays of junctions, eg.
my @p=1|11,2,1|11;
my @d=1|11,3,1|11;
#later
my $p = ([+] @p).grep { $_ < 21 };
my $d = ([+] @d).grep { $_ < 21 };
if $p > all{$d} { say 'p wins' } else { say 'd wins' };
I believe that there are hands where $p = 15|26 which would not beat a
hand where $d = 17.
I believe that the correct way to calculate the "value of the hand" is:
my $p = ([+] @p).map{.eigenstates}.grep{$_ < 21}.max;
which is exactly how I do it when I am playing Blackjack.
Put another way, the value of a blackjack hand is deterministic and
"sane", and you
Re: On Junctions
[I’d been planning to put this suggestion on hold until the spec is
sufficiently complete for me to attempt to implement it as a module. But
people are discussing this again, so maybe it's not just me. I apologize
if I appear to be beating a dead horse...]
Jon Lang wrote:
Maybe you could have something like a filter function
yes, but
that takes a
junction and a test condition and returns a junction of those
eigenstates from the original one that passed the test.
But why is this a useful thing to do? I think that you're proposing, for
compound junctions:
ok any( 1|2, 1&2, 5|15, 5&15 ) where { $_ < 10 }
=== any( 1|2, 1&2, 5|15 )
To me, it still feels like you're thinking of a junction as a set of
values, and inventing an operator specifically for the purpose of
messing with those values. I do not see "values of a junction" as a
meaningful user-level concept. I prefer to turn the problem around, and
suggest a different operator, motivated by a different issue, and then
apply that operator to junctions.
Consider this statement:
say (0..Inf).grep: { $_ < 10 };
I would expect it to take infinite time to complete (or else fail
quickly). It would be wrong to expect perl to figure out the correct
answer analytically, because that is impossible in the general case of
an arbitrary code block. So I instead propose an operator-based grep:
say 0..inf G[<] 10;
>>> [0..9]
This “grep metaoperator” can be expected to analytically determine the
result (of grepping an infinite list) in finite time. It might also be
used to avoid curlies for simple greps:
say @lines G~~ /foo/;
The operator exists to filter infinite lists in finite time. But it also
solves the junction problem:
say (-Inf .. Inf) G== 3|4;
>>> [3,4]
say ^Int G== 3|4; ## assuming ^Int means “any Int value”
>>> [3,4]
$score = [+] 1|11, 1|11, 1+11, 1+11, 4;
say max( 1..21 G== $score ) // "bust";
>>> 18
Re: On Junctions
Dave Whipp wrote:
> [I’d been planning to put this suggestion on hold until the spec is
> sufficiently complete for me to attempt to implement it as a module. But
> people are discussing this again, so maybe it's not just me. I apologize if
> I appear to be beating a dead horse...]
>
> Jon Lang wrote:
>
>> Maybe you could have something like a filter function
>
> yes, but
>
>> that takes a
>> junction and a test condition and returns a junction of those
>> eigenstates from the original one that passed the test.
>
> But why is this a useful thing to do? I think that you're proposing, for
> compound junctions:
>
> ok any( 1|2, 1&2, 5|15, 5&15 ) where { $_ < 10 }
> === any( 1|2, 1&2, 5|15 )
...not really, no. The way I was looking at it, the above expression
is ultimately a junction of the values 1, 2, 5, and 15; no matter how
compounded the junction is, these would be its eigenstates. Since 15
would fail the test, anything having to do with it would be filtered
out. Exactly how that would work with a compound junction, I'm not
sure; as I said, I was thinking of the eigenstates as ordinary items,
not "nested junctions". But yes, I _was_ suggesting something that
transforms one junction into another.
That said, I'm also leery of compound junctions. Please tell me the
difference between:
any( 1|2 )
...and:
any( 1, 2 )
If there is no difference, then:
any( 1|2, 1&2, 5|15, 5&15 ) eqv any( 1, 2, 1&2, 5, 15, 5&15 )
For that matter, I'm not seeing a difference between:
any( 1&2 ) # any of all of (1, 2)
...and:
any( 1, 2 ) # any of (1, 2)
If I'm not mistaken on these matters, that means that:
any( 1|2, 1&2, 5|15, 5&15 ) eqv any(1, 2, 5, 15)
And I expect that similar rules hold for other compound junctions. In
short, I won't be surprised if all compound junctions can flatten into
equivalent simple junctions.
> To me, it still feels like you're thinking of a junction as a set of values,
> and inventing an operator specifically for the purpose of messing with those
> values. I do not see "values of a junction" as a meaningful user-level
> concept.
I'm pretty sure that Larry agrees with you here, seeing as how his
latest revision concerning junctions makes direct access to a
junction's eigenstates very difficult to arrange.
> I prefer to turn the problem around, and suggest a different
> operator, motivated by a different issue, and then apply that operator to
> junctions.
> Consider this statement:
>
> say (0..Inf).grep: { $_ < 10 };
>
> I would expect it to take infinite time to complete (or else fail quickly).
> It would be wrong to expect perl to figure out the correct answer
> analytically, because that is impossible in the general case of an arbitrary
> code block. So I instead propose an operator-based grep:
>
> say 0..inf G[<] 10;
> >>> [0..9]
>
> This “grep metaoperator” can be expected to analytically determine the
> result (of grepping an infinite list) in finite time.
>
> It might also be used
> to avoid curlies for simple greps:
>
> say @lines G~~ /foo/;
>
> The operator exists to filter infinite lists in finite time. But it also
> solves the junction problem:
>
> say (-Inf .. Inf) G== 3|4;
> >>> [3,4]
And how would it handle a compound junction (assuming they exist)? That is:
say (-Inf .. Inf) G== any(1|2, 1&2, 5|15, 5&15);
>>> ???
> $score = [+] 1|11, 1|11, 1+11, 1+11, 4;
I assume you meant:
$score = [+] 1|11, 1|11, 4;
> say max( 1..21 G== $score ) // "bust";
> >>> 18
...and the answer to that would be 16, right?
--
Jonathan "Dataweaver" Lang
Re: On Junctions
Jon Lang wrote: > For that matter, I'm not seeing a difference between: > >any( 1&2 ) # any of all of (1, 2) > > ...and: > >any( 1, 2 ) # any of (1, 2) Those two are very different. any(1,2) == 2 is true any(1&2) == 2 is false Nested heterogeneous junctions are extremely useful. For example, the common factors of two numbers ($x and $y) are the eigenstates of: all( any( factors($x) ), any( factors($y) ) ) > If I'm not mistaken on these matters, that means that: > >any( 1|2, 1&2, 5|15, 5&15 ) eqv any(1, 2, 5, 15) No. They have equivalent eigenstates, but they are not themselves equivalent. For example, any( 1|2, 1&2, 5|15, 5&15 ) compares == to 1&2; whereas any(1, 2, 5, 15) doesn't. > And I expect that similar rules hold for other compound junctions. In > short, I won't be surprised if all compound junctions can flatten into > equivalent simple junctions. In general, they can't; not without changing their meaning. Damian
Re: On Junctions
Damian Conway wrote: > Jon Lang wrote: > >> For that matter, I'm not seeing a difference between: >> >> any( 1&2 ) # any of all of (1, 2) >> >> ...and: >> >> any( 1, 2 ) # any of (1, 2) > > Those two are very different. > > any(1,2) == 2 is true > > any(1&2) == 2 is false > > > Nested heterogeneous junctions are extremely useful. For example, the > common factors of two numbers ($x and $y) are the eigenstates of: > > all( any( factors($x) ), any( factors($y) ) ) I stand corrected. That said: with the eigenstates method now private, it is now quite difficult to get a list of the eigenstates of the above expression. -- Jonathan "Dataweaver" Lang
Grammars that generate stuff
Hi all. I've been thinking about stringification, forms, and things
like that.
As exegesis 7 points out, sprintf, pack, and the forms language all
essentially take data and specifies how to turn it into a "string" (I'm using
"string" loosely here). Likewise with .perl -- it takes some data, and turns
it into a string formatted in a particular way.
Perl 6 has a general language (grammars) for taking some input and a
grammar, and separating the data from the formatting, as it were.
What's made Perl 6 so much more powerful in this area is the grouping
of regexen into grammars.
I'm wondering if we can't come up with a language that does for output
formatting what grammars do for input formatting.
For example, say we could create something called an
outputgrammar. We could do something like this:
grammar XMLIn {...}
outputgrammar XMLout {...}
My thought is that you would then be able to read an XML document
using the XMLin grammar, do a transform or two, and then rewrite it almost
identically (except the changes) with the outputgrammar.
Ideally, it'd be possible to specify one grammar that would act both
for parsing output and formatting input. This may not be possible, but I like
the idea.
It may already be possible to mock up some of these things (a hash
array of sprintf formats?), but I'd be interested in seeing some discussion on
what's possible.
Of course, if this has already been discussed, I'd love to read about
it -- please send links.
:)
-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am |
-
BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-
-END GEEK CODE BLOCK-
