On 4/4/06, Larry Wall [EMAIL PROTECTED] wrote:
On Tue, Apr 04, 2006 at 09:16:23AM -0400, Joshua Gatcomb wrote:
Junctions are not intended for that use. We have Sets for that now.
Ok. So this will work out of the box if you use the right tool. Cool.
The cabal already decided once
On Tue, Apr 04, 2006 at 11:02:55AM -0700, Jonathan Lang wrote:
: Will perl6 Sets include set negation and/or a universal set? In
: effect, an internal flag that says, this set contains every possible
: element _except_ the ones listed?
Arguably, that's what none() is. And all() is the only
Larry Wall wrote:
On Tue, Apr 04, 2006 at 11:02:55AM -0700, Jonathan Lang wrote:
: Will perl6 Sets include set negation and/or a universal set? In
: effect, an internal flag that says, this set contains every possible
: element _except_ the ones listed?
Arguably, that's what none() is.
. We're trying to decide
*how* Junctions are like Sets, not defining them into two different
universes. I'm saying that all() is the Junction tha is most like
a Set. A none() Junction can be viewed as the specification for an
infinite set of sets that do not intersect with the corresponding all
2006/4/4, Larry Wall [EMAIL PROTECTED]:
But this is all based on enumerated sets. Oddly missing are any
Sets that are defined by rule. That would presumably take closures,
though I suppose one can attempt to enumerate the closures that have
to hold true and autothread through the calls to
Larry Wall wrote:
You're confusing the map with the territory. We're trying to decide
*how* Junctions are like Sets, not defining them into two different
universes. I'm saying that all() is the Junction tha is most like
a Set. A none() Junction can be viewed as the specification
On 4/4/06, Larry Wall [EMAIL PROTECTED] wrote:
On the other hand, if junctions really are sets of sets, then maybe it's
a mistake to autocoerce junctions to sets by swiping their internal set
of values. Arguably any(1,2,3) should coerce not to
(1,2,3)
but to
(
(1
On 4/4/06, Jonathan Lang [EMAIL PROTECTED] wrote:
OK, then; what would be the specification for a _single_ set that
contains everything that doesn't intersect with a corresponding all()
Junction (the sort of thing that I'd use if I wanted to find the
largest subset of A that doesn't intersect
2006/4/4, Luke Palmer [EMAIL PROTECTED]:
I don't follow. Why is that the representation of any(1,2,3)? Is
this a disjunctive normal form; i.e. is 2 any(1,2,3) equivalent to
the test:
2 1
|| 2 2
|| 2 3
|| 2 1 2 2
|| ...
2 1
| 2 2
| 2 3
which ends up being the
On 1/5/06, TSa [EMAIL PROTECTED] wrote:
Jonathan Lang wrote:
Therefore,
$x = 3;
if $x = 1 5 {say 'smaller'}
if $x 1 5 {say 'larger'}
should produce exactly the same output as
$x = 3;
if $x = 1 $x = 5 {say 'smaller'}
This is slightly untrue. because if the
Rob Kinyon wrote:
To me, this implies that junctions don't have a complete definition.
Either they're ordered or they're not. Either I can put them in a =
expression and it makes sense or I can't. If it makes sense, then that
implies that if $x = $y is true, then $x $y is false. Otherwise
working properly if I changed *that* information.
(Assuming well-typed refers to the former, but not the latter --
hope I've got that straight.)
In that vein, I think of junctions as a sort of implicit
polymorphism: I define sub foo(Int $a) and also get sub
foo(Junction of Ints $j) for free. Which
HaloO,
Jonathan Lang wrote:
Rob Kinyon wrote:
To me, this implies that junctions don't have a complete definition.
Either they're ordered or they're not.
So, is there a number between 0 and 1? Shades between black and white?
When is a 360 degree turn not returning a system into its initial
Me no follow. Please use smaller words?
--
Jonathan Dataweaver Lang
HaloO,
Luke Palmer wrote:
Junctions are frightfully more abstract than that. They only take on
meaning when you evaluate them in boolean context. Before that, they
represent only a potential to become a boolean test.
This is very well spoken err written---except that I would use
beautifully
of my quibbles with junctions, too.
You mean the fact that after $junc = any(1,2,3) there is
no syntactical indication of non-scalar magic in subsequent
uses of $junc e.g. when subs are auto-threaded? I strongly
agree. But I'm striving for a definition where the predicate
nature
of my quibbles with junctions, too.
I'm confused at the confusion. To me, junctions are just magical
values, not magical scalars. In theory, one should be able to create
junctions of arrays, hashes, or subs just as easily.
This really has nothing to do with what I was talking about. Here's
what
HaloO,
Rob Kinyon wrote:
I'm confused at the confusion. To me, junctions are just magical
values, not magical scalars. In theory, one should be able to create
junctions of arrays, hashes, or subs just as easily.
my @junc = any( @a, @b, @c );
my %junc = any( %a, %b, %c );
Hmm
HaloO,
Luke Palmer wrote:
Which reads nicely, but it is quite opaque to the naive user.
I guess many things are opaque to naive users ;)
Whatever solution we end up with for Junctions, Larry wants it to
support this:
if $x == 1 | 2 | 3 {...}
And I'm almost sure that I agree with him
Luke Palmer wrote:
Whatever solution we end up with for Junctions, Larry wants it to
support this:
if $x == 1 | 2 | 3 {...}
And I'm almost sure that I agree with him. It's too bad, because
except for that little detail, fmap was looking pretty darn nice for
junctions.
Not really
On 1/4/06, Jonathan Lang [EMAIL PROTECTED] wrote:
And I'm almost sure that I agree with him. It's too bad, because
except for that little detail, fmap was looking pretty darn nice for
junctions.
Not really. If I read the fmap proposal correctly,
You didn't :-)
if any($x, $y, $z
HaloO,
Luke Palmer wrote:
The point was that you should know when you're passing a named
argument, always. Objects that behave specially when passed to a
function prevent the ability to abstract uniformly using functions.[1]
...
[1] This is one of my quibbles with junctions, too.
You mean
.
Whatever solution we end up with for Junctions, Larry wants it to
support this:
if $x == 1 | 2 | 3 {...}
And I'm almost sure that I agree with him. It's too bad, because
except for that little detail, fmap was looking pretty darn nice for
junctions.
There is a conflict of design interest
On 20/09/05, Luke Palmer [EMAIL PROTECTED] wrote:
The basic idea is that, alongside Functor, you have a Zippable theory
which defines:
theory Zippable[::T] {
multi zip (T[::A], T[::B] -- T[:(::A, ::B)]) {...}
}
Where that last coloney madness is a yet-to-be-proposed tuple
.)
Part 2: Junctions
So my proposal is to make a Junction into a plain old Functor. So
what used to be:
if any(@values) == 4 {...}
Is now:
if any(@values) »== 4 {...}
And the only thing that makes junctions different from Sets (which are
also Functors) is their behavior
), :(4,d)]]
In order to be consistent with the specced semantics. In order to
keep with the specced semantics of junctions, you'll probably see:
zip(1|2, 34)
Give:
(:(1,3) :(1,4)) | (:(2,3) :(2,4))
So it's really up to the zippable functor itself to figure out the
best way to zip
On 9/19/05, Luke Palmer [EMAIL PROTECTED] wrote
Well, I've written up the details in a 40 line Haskell program to make
sure it worked. I think I deleted the program, though.
Nope. Here it is. And it was 22 lines. :-)
http://svn.luqui.org/svn/misc/luke/work/code/haskell/hyper.hs
Luke
Okay, due to some discussion on #perl6, I'll assume that the reason my
fmap proposal was Warnocked is because a fair number of people didn't
understand it. Also, for the people who did understand, this message
includes a complete proposal for the workings of Junctions that will
fluster Damian
On Thu, 26 May 2005, Patrick R. Michaud wrote:
The continuing exchanges regarding junctions, and the ongoing tendency
by newcomers to think of them and try to use them as sets, makes
me feel that it might be worthwhile to define and publish a standard
CSet class and operations sooner rather
are 1, for these purposes.
I proposed the following:
# Fifteens
$score += 2 * all( 15 == [EMAIL PROTECTED] any( 0 .. 4 ) } );
* Is this syntax legal?
I think so.
* Does it do what I want it to do?
Definitely not. It looks like you are thinking of junctions in terms of
arrays, instead
Assuming you write the subset coroutine above, how about
$score +=
( subsets(0..4) == map { 2 * (15 == [+] @[EMAIL PROTECTED]) } == [+] )
Working on it last night and this morning, I ended up with the
following, very similar rewrite.
sub gen_idx_powerset (Int $size is copy) returns
in advance for what I'm about to write: I'm going
to express some thoughts/ideas below and then pretty much leave it
to others to decide what (if anything) should be done with it.
The continuing exchanges regarding junctions, and the ongoing tendency
by newcomers to think of them and try to use them
(This post references the discussion at
http://www.perlmonks.org/?node_id=458728, particularly dragonchild's
response at the bottom.)
For those who don't know, cribbage is a game where each player has
access to 4 cards, plus a community card. Various card combinations
score points. The one in
On 5/14/05, Damian Conway [EMAIL PROTECTED] wrote:
Larry wrote:
I don't think we can allow this situation to stand. Either we have
to make != and !~ and ne transform themselves via not raising, or
we have to disallow negative comparisons on junctions entirely.
Opinions?
Making
On 5/15/05, Luke Palmer [EMAIL PROTECTED] wrote:
multi sub infix:!= (Any|Junction $a, Any|Junction $b) {
!($a == $b);
}
Then it Just Works.
Also, that's the right way to provide a working != for any object
which defines ==. We all want that, right?
Ashley Winters
, and it's easy to explain that the magic of
the C!= is being applied before the magic of junctions.
Damian
version if that is the underlying rule, since
: then the behaviour isn't a special case, and it's easy to explain that the
: magic of the C!= is being applied before the magic of junctions.
Heh, I knew if I waited long enough I'd see arguments for both sides.
Okay, let's go with the not raising
We have a bit of a problem with negative operators applied to junctions,
as illustrated recently on PerlMonks. To wit, when a native English
speaker writes
if $a != 1 | 2 | 3 {...}
they really mean one of:
if not $a == 1 | 2 | 3 {...}
if $a == none(1, 2, 3) {...}
or, expressed
On Sat, May 14, 2005 at 09:31:29AM -0700, Larry Wall wrote:
I don't think we can allow this situation to stand. Either we have
to make != and !~ and ne transform themselves via not raising, or
we have to disallow negative comparisons on junctions entirely.
I'm of the opinion that disallowing
Larry Wall wrote:
We have a bit of a problem with negative operators applied to junctions,
as illustrated recently on PerlMonks. To wit, when a native English
speaker writes
if $a != 1 | 2 | 3 {...}
they really mean one of:
if not $a == 1 | 2 | 3 {...}
if $a == none(1, 2, 3
Larry wrote:
I don't think we can allow this situation to stand. Either we have
to make != and !~ and ne transform themselves via not raising, or
we have to disallow negative comparisons on junctions entirely.
Opinions?
Making them DWIM here would be a mistake, since the dwimmery would disappear
Abhijit Mahabal wrote:
When you dispatch, what happens would depend upon WALKMETH (according to
the pseudocode for CALLONE in A12). Usually the first inherited method
would get called.
Ohh, yes, that thing. I forget about it. And actually I hope that
there's a version among the standard pragmas
David Storrs wrote:
Let's move this away from simple types like Str and Int for a moment.
If you consider them simple...
Tell me what this does:
class Tree {
method bark() { die Cannot instantiate a Tree--it is abstract! }
}
class Birch {
method bark() { return White, papery }
}
On Mon, 2 May 2005, [ISO-8859-1] Thomas Sandlaß wrote:
David Storrs wrote:
Tell me what this does:
class Tree { method bark() { die Cannot instantiate a Tree--it is
abstract! }
}
class Birch { method bark() { return White, papery }
}
class Oak { method bark() { return Dark,
On Mon, May 02, 2005 at 06:49:10PM +0200, Thomas Sandlaß wrote:
David Storrs wrote:
Let's move this away from simple types like Str and Int for a moment.
If you consider them simple...
When compared to
arbitrary-class-that-was-defined-by-
arbitrary-programmer-of-
David Storrs writes:
On Mon, May 02, 2005 at 06:49:10PM +0200, Thomas Sandla wrote:
David Storrs wrote:
class Tree {
method bark() { die Cannot instantiate a Tree--it is abstract! }
}
class Birch {
method bark() { return White, papery }
}
class Oak {
method
On Sat, 2005-04-30 at 16:55 -0700, Brent 'Dax' Royal-Gordon wrote:
Aaron Sherman [EMAIL PROTECTED] wrote:
On Sat, 2005-04-30 at 22:24 +0800, Autrijus Tang wrote:
That would be absolutely horrible.
Str|Int is simply the type of Yes|1, isn't it? That would certainly
make signature
On Sun, May 01, 2005 at 10:59:59AM -0400, Aaron Sherman wrote:
On Sat, 2005-04-30 at 16:55 -0700, Brent 'Dax' Royal-Gordon wrote:
Aaron Sherman [EMAIL PROTECTED] wrote:
On Sat, 2005-04-30 at 22:24 +0800, Autrijus Tang wrote:
That would be absolutely horrible.
You all seem to have
On Sat, Apr 30, 2005 at 09:13:26AM -0500, Abhijit Mahabal wrote:
On Fri, 29 Apr 2005, Brent 'Dax' Royal-Gordon wrote:
David Storrs [EMAIL PROTECTED] wrote:
Could we see some code that shows why this is a good idea? My initial
reaction is horror; I can very easily see huge numbers of subtle,
On Fri, 29 Apr 2005, Brent 'Dax' Royal-Gordon wrote:
David Storrs [EMAIL PROTECTED] wrote:
On Thu, Apr 28, 2005 at 03:28:41PM +0200, Ingo Blechschmidt wrote:
so we had junctions of Code references some days ago, what's with
junctions of Class and Role objects? :)
Could we see some code that shows
On Sat, 2005-04-30 at 22:24 +0800, Autrijus Tang wrote:
On Sat, Apr 30, 2005 at 09:13:26AM -0500, Abhijit Mahabal wrote:
I do not see how any auto-threading occurs in that code. It is completely
innocuous in that sense, and I don't think that is what horrified David.
What was troublesome
On Sat, 30 Apr 2005, Aaron Sherman wrote:
On Sat, 2005-04-30 at 22:24 +0800, Autrijus Tang wrote:
On Sat, Apr 30, 2005 at 09:13:26AM -0500, Abhijit Mahabal wrote:
I do not see how any auto-threading occurs in that code. It is completely
innocuous in that sense, and I don't think that is what
junctions.) When you see a declaration like:
my Foo $bar;
Think of it as being like:
my $bar where { $_ ~~ Foo };
If the latter, then what is the type of Yes|1?
I suspect it's `Disjunction of Str | Int`.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have
On Thu, Apr 28, 2005 at 03:28:41PM +0200, Ingo Blechschmidt wrote:
so we had junctions of Code references some days ago, what's with
junctions of Class and Role objects? :)
Could we see some code that shows why this is a good idea? My initial
reaction is horror; I can very easily see huge
David Storrs [EMAIL PROTECTED] wrote:
On Thu, Apr 28, 2005 at 03:28:41PM +0200, Ingo Blechschmidt wrote:
so we had junctions of Code references some days ago, what's with
junctions of Class and Role objects? :)
Could we see some code that shows why this is a good idea? My initial
Ingo Blechschmidt iblech at web.de writes:
then it has a better chance of working, presuming someone has the
gumption to write .pick on hashes, which doesn't look entirely trivial
to do right.
thinking out loudI'm sure I overlooked something, but the following
seems to be correct
Hi,
so we had junctions of Code references some days ago, what's with
junctions of Class and Role objects? :)
role A { method foo() { 42 } }
role B { method foo() { 23 } }
class Test does A|B {}
my Test $test .= new;
my $ret = $test.foo; # 42|23?
role A {}
role B { method foo
Ingo Blechschmidt wrote:
Hi,
so we had junctions of Code references some days ago, what's with
junctions of Class and Role objects? :)
I like them! In the type lattice A|B is the lub (lowest upper bound)
of A and B. And AB is the glb (greatest lower bound) of A and B.
Both are cases of multiple
On Thu, 2005-04-28 at 09:51, Thomas Sandlaß wrote:
Ingo Blechschmidt wrote:
Hi,
so we had junctions of Code references some days ago, what's with
junctions of Class and Role objects? :)
I like them! In the type lattice A|B is the lub (lowest upper bound)
of A and B. And AB is the glb
Aaron Sherman wrote:
Now, I'm not saying that that's the way it MUST be, just that that seems
to be the way that junctions would work in that situation.
I know, and I'm very confused about all these pseudo procedural uses
of junctions. And others seem to share my state of affairs.
If we decide
be recreated, so e.g. $result == eval( $result.perl ). This forces
a once through evaluation of the junction. So, yes I think your result
is one of the possible 4. The other three are the two numbers in the any()
swapped and the number and the any() of the one() swapped.
OTOH, the junctions
Hi,
Assuming this is allowed, what will the .() calls below return?
Does the result depend on the calling context?
use junctions; # still required?
my @subs = ( sub { return 1 } ,
sub { return 2 } );
# call the closures in the junction
any(@subs).();
all(@subs).();
one
Brad Bowman wrote:
Assuming this is allowed, what will the .() calls below return?
Does the result depend on the calling context?
...
one(any(@subs),sub { ... }).();
Starting to argument from the statement that junctions are values
the above plays in the league of 3.() which might not have
I'm looking in S09, and reading about junctions. It seems to me that
if we have a junction $j which we use to index into an array or a hash,
it should DWIM and return a junction of the corresponding values.
@ar=[1..10];
%hash=(a=1,b=4,c=7);
$j=1|2|3;
$k=a|c;
$u = @ar[$j]; # 2|3|4
$v
David Christensen writes:
I'm looking in S09, and reading about junctions. It seems to me that
if we have a junction $j which we use to index into an array or a hash,
it should DWIM and return a junction of the corresponding values.
@ar=[1..10];
%hash=(a=1,b=4,c=7);
$j=1|2|3;
$k=a|c
--- David Christensen [EMAIL PROTECTED] wrote:
I'm looking in S09, and reading about junctions. It seems to me
that if we have a junction $j which we use to index into an array
or a hash, it should DWIM and return a junction of the corresponding
values.
@ar=[1..10];
%hash=(a=1,b=4,c=7
;
@k = a c;
@u = @ar[$j];# (b..d)
@u = @[EMAIL PROTECTED];
etc.
Perl can indeed slice using ordinary lists. Another problem with using
junctions for this is that they're unordered, and you're expecting
ordered results back.
Luke
Paul Hodges wrote:
--- David Christensen [EMAIL PROTECTED] wrote:
I'm looking in S09, and reading about junctions. It seems to me
that if we have a junction $j which we use to index into an array
or a hash, it should DWIM and return a junction of the corresponding
values.
@ar=[1..10];
%hash
Hi all,
S03 gives infix + a higher precedence than junctive
operators in the listed table, but that seems to contradict
the examples under Junctive operators.
The relevant parts of S03 are:
Junctive operators
1|2|3 + 4; # 5|6|7
1|2 + 34; # (4|5) (5|6)
time discussing this very topic in one of our
design meetings. The intent of junctions is primarily to produce
superposed data values, not to make it possible to write impenetrable
code, so the question boils down to whether operators like + are
used more often to build the sorts of data values you'd
On Sun, Apr 17, 2005 at 07:29:33AM -0700, Larry Wall wrote:
On Sun, Apr 17, 2005 at 08:56:46PM +1000, Brad Bowman wrote:
:
: Hi all,
:
: S03 gives infix + a higher precedence than junctive
: operators in the listed table, but that seems to contradict
: the examples under Junctive
Hi,
Trey Harris wrote:
In a message dated Mon, 4 Apr 2005, Ingo Blechschmidt writes:
What does pick return on hashes? Does it return a random value or a
random pair? (I suppose returning a pair is more useful.)
I'd assume in all cases that pick returns an *alias*, and in the case
of
On Tue, Apr 05, 2005 at 02:38:05PM +0200, Ingo Blechschmidt wrote:
: Hi,
:
: Trey Harris wrote:
: In a message dated Mon, 4 Apr 2005, Ingo Blechschmidt writes:
: What does pick return on hashes? Does it return a random value or a
: random pair? (I suppose returning a pair is more useful.)
:
Hi,
Larry Wall wrote:
: Same for hashes:
[...]
: my %hash = (a = 1, b = 2),
: my $pair := %hash.pick;
: $pair = ...; # %hash changed
I'm not sure that works. We don't quite have pairs as first class
containers. Binding would try to use a pair as a named argument, and
would fail
Hi,
I remembered Damian saying that pick does not only work on junctions,
but on arrays and hashes, too (and I even found his posting :):
http://groups.google.com/groups?selm=420DB295.3000902%40conway.org).
Are the following assumptions correct?
my $junc = 1|2|3;
print $junc.pick; # 1, 2
Ingo Blechschmidt wrote:
I remembered Damian saying that pick does not only work on junctions,
but on arrays and hashes, too (and I even found his posting :):
http://groups.google.com/groups?selm=420DB295.3000902%40conway.org).
Are the following assumptions correct?
my $junc = 1|2|3;
print
In a message dated Mon, 4 Apr 2005, Ingo Blechschmidt writes:
What does pick return on hashes? Does it return a random value or a
random pair? (I suppose returning a pair is more useful.)
I'd assume in all cases that pick returns an *alias*, and in the case of
hashes, an alias to the pair:
#
on junctions,
but on arrays and hashes, too (and I even found his posting :):
http://groups.google.com/groups?selm=420DB295.3000902%40conway.org).
Are the following assumptions correct?
my $junc = 1|2|3;
print $junc.pick; # 1, 2, or 3
print pick $junc; # same
my @array = a b c;
print
In a message dated Mon, 4 Apr 2005, Ingo Blechschmidt writes:
What does pick return on hashes? Does it return a random value or a
random pair? (I suppose returning a pair is more useful.)
I'd assume in all cases that pick returns an *alias*, and in the case of
hashes, an alias to the pair:
#
Yikes. Sorry about the ressends... my email client kept dying and I
thought the mail was lost. Guess not. :-)
Trey
In a message dated Mon, 4 Apr 2005, Trey Harris writes:
In a message dated Mon, 4 Apr 2005, Ingo Blechschmidt writes:
What does pick return on hashes? Does it return a random
Stevan Little writes:
my $a = 'a';
my $b = '';
my $c = '';
my $any_of_them = $b | $c | $a;
# this test passes
ok('a' eq $any_of_them, '($b | $c | $a) matches at least one a');
$b = 'b';
$c = 'c';
# this test passes ...
ok('a' eq $any_of_them, '($b | $c | $a) matches at least one
Rod Adams wrote:
I have the philosophical problem with your use of junctions in this
context due to the fact that you are completely ignoring the predicate
of the junction. The C all(...) == one(...) is an excellent use of
YES, and much clearer than when this test is buried under code
that has
Rod Adams [EMAIL PROTECTED] wrote:
Well
if 10 $j 1 { ... }
if 10 $j { if $j 1 { ... }}
Could easily wind up with the same opcodes.
No. In the first case $j is evaluated just once. In the second case it's
evaluated twice.
leo
Leopold Toetsch wrote:
Rod Adams [EMAIL PROTECTED] wrote:
Well
if 10 $j 1 { ... }
if 10 $j { if $j 1 { ... }}
Could easily wind up with the same opcodes.
No. In the first case $j is evaluated just once. In the second case it's
evaluated twice.
You're right. I just dived
than comparisons. That's why junctions can't
be passed into a function unless the function specifically allows it,
for instance. (Then there's the matter of sneaky return values.)
The only alternative is to autothread every conditional, and I don't
think we'd survive the lynch mobs if we did
entanglement further out than comparisons. That's why junctions can't
be passed into a function unless the function specifically allows it,
for instance. (Then there's the matter of sneaky return values.)
The only alternative is to autothread every conditional, and I don't
think we'd survive
Sam Vilain wrote:
I've changed examples/sendmoremoney.p6 in the pugs distribution to use
junctions correctly to demonstrate that they *can* be used to solve these
sorts of problems, and that it is just a matter of semantics and writing
code correctly.
However, poor semantics can make the task
I gave a talk on Perl 6 Junctions at the Thousand Oaks Perl Mongers
meeting last night
http://www.hcoop.net/~terry/perl/talks/p6-junctions/index.html
and two questions/desires came out of it:
1: will it be possible to know which element of a junction is
currently being used? E.g
Terrence Brannon wrote:
I gave a talk on Perl 6 Junctions at the Thousand Oaks Perl Mongers
meeting last night
http://www.hcoop.net/~terry/perl/talks/p6-junctions/index.html
and two questions/desires came out of it:
1: will it be possible to know which element of a junction is
currently
Rod Adams wrote:
I do not believe that is possible.
This is the filtering or unification behavior that people keep
wanting junctions to have, which they do not.
Aww! But what about all the great problems that could be expressed
with them? I know of two languages that consider this to be a core
Rod Adams wrote:
I do not believe that you can create a 'lazy junction'. But I don't
recall the topic coming up before, so we'll have to wait for Damian to
come back unless someone else knows for certain.
My understanding is that all lists are conceptually lazy. any(2..Inf)
is perfectly valid.
Sam Vilain wrote:
Rod Adams wrote:
I do not believe that is possible.
This is the filtering or unification behavior that people keep
wanting junctions to have, which they do not.
Aww! But what about all the great problems that could be expressed
with them? I know of two languages that consider
of a junction, the values
that junction has are set in stone. Allowing some form of lazy list to
add values at will seems a bit counter to me. But if @Cabal think it's
okay to have lazy junctions, I won't argue with them.
-- Rod Adams
junction, so C any(2..Inf) is valid, but melts your processor
RA similar to C sort 2..Inf .
i was under the impression that junctions could be smart about ranges
like that and do it correctly. sort can't possibly handle that but some
junctions and ranges would work fine. it isn't hard to convert
{...}
We could make junctions smart about ranges, so that the latter can just
fail, but I argue that we can only do it well in the simplest of cases.
It's probably better not to allow infinite ranges in junctions.
On the other hand, if we give junctions well-defined semantics in terms
Rod Adams wrote:
And as one who recently proposed a way of getting Prolog like features
in Perl (through Rules, not Junctions), I understand the appeal
completely. Junctions are not the way to that goal. They are something
different.
Taking multiple values at once is what junctions are all
I have two questions about this example code
(taken from http://svn.openfoundry.org/pugs/examples/sendmoremoney.p6)
(btw, a really nice example of how to use junctions - just try to write
this in perl5 :)
#!perl6
use v6;
my $s;
my $e;
my $n;
my $d;
my $m;
my $o;
my $r;
my $y;
$s = any(0
by 9 money lines.
Junctions are _not_ the same as unbound variables in Prolog. They do not
widdle away inconsistent values as those inconsistencies are found.
Most of them (all except all()) do not have to use the same value each
time they are evaluated.
If I'm wrong about this interpretation
Jonathan Lang [EMAIL PROTECTED] wrote:
There are a couple of problems: first, a hash's keys are limited to
strings; a set ought to be able to handle a wider range of data types.
Last time I checked, there was going to be a way to declare a
different data type for the key (which could easily be
On Mon, Feb 21, 2005 at 10:32:15PM -0800, Jonathan Lang wrote:
: ...then you've got the notion of Fuzzy Logic Sets, where the key would be
: the prospective element and the value would be the degree of membership.
: For fuzzy sets, hashes seem to be a better fit than junctions, which have
101 - 200 of 297 matches
Mail list logo
