On 10/22/2010 06:16 AM, Damian Conway wrote:
That is, a C$value is an eigenstate of a C$junction if-and-only-if:
$value !~~ Junction$value ~~ $junction
In general this definition makes it impossible to return a list of
eigenstates from the junction. Just think of junctions containing
Moritz wrote:
$value !~~ Junction $value ~~ $junction
In general this definition makes it impossible to return a list of
eigenstates from the junction. Just think of junctions containing Code
objects.
Well, that's a deficiency in smartmatching: that Callable ~~ Code doesn't
check for
On 11/01/2010 12:41 PM, Damian Conway wrote:
Moritz wrote:
$value !~~ Junction$value ~~ $junction
In general this definition makes it impossible to return a list of
eigenstates from the junction. Just think of junctions containing Code
objects.
Well, that's a deficiency in
Food for thought, a few non-junction solutions:
On 10/22/2010 06:16 AM, Damian Conway wrote:
# Find the list of common elements in two lists...
sub intersection (@list1, @list2) {
(any(@list1) any(@list2).eigenstates;
}
sub intersection(@list1, @list2) {
uniq gather
On Mon, Nov 1, 2010 at 7:24 AM, Moritz Lenz mor...@faui2k3.org wrote:
On 10/22/2010 06:16 AM, Damian Conway wrote:
That is, a C$value is an eigenstate of a C$junction if-and-only-if:
$value !~~ Junction $value ~~ $junction
In general this definition makes it impossible to return a
Buddha Buck wrote:
Is it too late in this discussion to point out that, in non-perl
usage, eigenstates are associated with the operator, not with the
value fed into the operator?
[cut]
So asking for the eigenstates of a quantum superposition is asking the
wrong object for the property.
On Thu, 28 Oct 2010, Damian Conway wrote:
The apparent paradox ... is due to the assumption (employed in the
second interpretation) that is identical to !=. Certainly that is
true for simple scalar numbers, but not always for vector types such
as tuples, sets, bags, complex numbers...or
Martin D Kealey suggested:
Well, I think returning or throwing an Unordered exception would be
the appropriate way to handle those, both for complex numbers and for
junctions.
For complex numbers that might be true, because the order relationship
between two complex numbers isn't expressible
Martin D Kealey asked:
Or do we not invert junctions, and run the risk of unexpected
action-at-a-distance instead?
I think our current approach is correct. That is: we invert
junctions on operators that are themselves intrinsically inverted
(such as !=, !~~, !), but do not invert on those that
Damian Conway wrote:
If it's about parallel data handling, then we have to be prepared to
(notionally) fork the entire rest of the runtime, even as far as
having a definition of what return value the parent process sees (from
exit) when those threads are implicitly collapsed at termination.
I have to admit to feeling uneasy about the whole action-at-a-distance
effect that junctions are capable of producing. They sit around pretending
to be a scalar, only to pop up and wreak havoc with ones expectations of
linearity when you're not expecting it.
That unexpected-action-at-a-distance
Jon Lang wrote:
Personally, I don't think that it should be a public method: one thing
about junctions is that you can use them interchangeably with ordinary
scalars; giving them a public method breaks that. In particular, code
that makes use of a Junction public method would break if you
On 2010-Oct-25, at 15:14, Damian Conway wrote:
Yes, Ted Z. pointed out to me that, as the name of this construct,
every has ambiguity and synonym issues. Other possibilities are:
select(@values) one(3..7)
those(@values) one(3..7)
whichever(@values) one(3..7)
On Oct 22, 6:41 pm, dam...@conway.org (Damian Conway) wrote:
Dave Whipp wrote:
When this issue has been raised in the past, the response has been that
junctions are not really intended to be useful outside of the narrow purpose
for which they were introduced.
Hmm. There are
Ben Goldberg asked:
I'm probably missing something, but wouldn't it have been easier to
write that module by using eval STRING to create all of those infix
operators?
Sure. But the module is already slow to start up. I was concerned
that it would get even slower with an embedded eval. But, in
Damian Conway wrote:
So I'm going to go on to propose that we create a fifth class of
Junction: the transjunction, with corresponding keyword Cevery.
[...]
say (^10 G[] one(3,7));
3 4 5 6
which could also be:
say every(^10) one(3,7);
# Every value up to 10 that's greater than 3
Dave Whipp noted:
I think that the two proposals are equivalent, in the sense that either can
be trivially implemented using the other.
Agreed.
However, I am a little concerned that the transjunction magically changes
an operator that returns a Boolean value into one that returns a list.
Damian Conway wrote:
Yes, Ted Z. pointed out to me that, as the name of this construct,
every has ambiguity and synonym issues. Other possibilities are:
select(@values) one(3..7)
those(@values) one(3..7)
whichever(@values) one(3..7)
itemize(@values) one(3..7)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/22/10 13:00 , Dave Whipp wrote:
Damian Conway wrote:
I've been thinking about junctions, and I believe we may need a small
tweak to (at least) the jargon in one part of the specification.
When this issue has been raised in the past, the
Brandon mused:
It occurs to me: If their purpose is that narrow, why are they wasting
conceptual space in the core language?
Well, mainly because their purpose isn't narrow at all: it's parallelized data
comparisons (all(@values) $threshold), and multiway comparisons
(all(@values) ~~
In general I like where this is going but need a little hand holding
here- I'm not an expert on junctions or anything perl6-
So I'm going to go on to propose that we create a fifth class of
Junction: the transjunction, with corresponding keyword Cevery.
It seems that by these definitions every
In general I like where this is going but need a little hand holding
here- I'm not an expert on junctions or anything perl6-
So I'm going to go on to propose that we create a fifth class of
Junction: the transjunction, with corresponding keyword Cevery.
It seems that by these definitions
Damian Conway wrote:
I've been thinking about junctions, and I believe we may need a small
tweak to (at least) the jargon in one part of the specification.
When this issue has been raised in the past, the response has been that
junctions are not really intended to be useful outside of the
Dave Whipp wrote:
When this issue has been raised in the past, the response has been that
junctions are not really intended to be useful outside of the narrow purpose
for which they were introduced.
Hmm. There are intentions, and then there are intentions. I know
what I intended when I
24 matches
Mail list logo
