junctions and conditionals
In Junction Algebra, Martin Kealey wrote:
On Mon, 30 Mar 2009, Mark J. Reed wrote:
( $a = any(-1,+1) = $b ) == ( $a = any(-1,+1) any(-1,+1) =
$b )
Clearly, the RHS is true for $a == $b == 0, but I'm not sure the LHS
shouldn't also be. Isn't it just syntactic sugar for the RHS?
I suspect not. Rather I think that
$a = any(-1,+1) = $b
corresponds to
$tmp = any(-1,+1);
$a = $tmp = $b
and thence to
$tmp = any(-1,+1);
$a = $tmp $tmp = $b
The more I think about this, the more I come to the conclusion that a
junction should appear to have a uniform (single) value in each
eigenthread.
Ugh. Let me float another problem, and a possible solution to both,
that doesn't require persistent threading environments:
$x = -1 | +1;
if $x 0 { say $x }
As I understand junctions right now, the result of this code is identical to:
say -1 | +1;
In both cases, the problem arises when you apply a predicate to a
junction, and then use the junction within code that only gets
executed according to the truth of the predicate.
The possible solution to both of these: junctions collapse when they
hit conditional statements - but only within the conditioned scope.
So: within the code block for the if $x 0 statement above, $x only
equals +1, since -1 didn't pass the test. Thus, say $x is the same
as say 1. In the case of the range test, the code on the RHS of the
only executes if the code on the LHS evaluated to true; therefore,
when evaluating the RHS, $tmp doesn't include any of the
possibilities that would have failed on the LHS. That means that:
0 = -1 | +1 = 0
...becomes:
0 = -1 | +1 +1 = 0
...which, obviously, is false.
Extending this further:
$x = +1 | -1;
if $x 0 { say $x is positive. }
else { say $x is negative. }
I suspect that both codeblocks would be executed; but within the first
block, $x == +1, and within the second codeblock, $x == -1.
$x = +1 | -1;
say $x 0 ?? $x + 2 :: $x * 2;
In this case, $x is +1 when evaluating $x + 2, and it is -1 when
evaluating $x * 2. After this expression is fully evaluated, they
get recombined into a single junction: +3 | -2.
This last one might be easier to manage simply by having $x autothread
through the ?? :: operator, since you need to be able to reassemble
a junction on the other end.
--
Jonathan Dataweaver Lang
Re: Logo considerations
--- On Tue, 3/24/09, jason switzer jswit...@gmail.com wrote: Basically, the perl community has largely adopted TIMTOWTDI So how about a Tim the Toady? :) === Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a thumb.
Re: junctions and conditionals
I've been having some second thoughts concerning this. Here's where I
stand on it now:
In Perl 6, you have the following decision points, where code may or
may not be executed depending on a condition:
if/unless/while/until/loop/when statements; if/unless/while/until
statement modifiers; short-circuit operators; the trinary conditional
operator. When you apply a junction to a decision point, only one of
the possible paths will be taken; and the any/all/one/none nature of
the junction will determine which one. (Without this, there would be
no reason to have a distinction between any/all/one/none.) However, I
stand by my proposal that after passing one of these decision points,
and until you get back to code that would have been reached regardless
of the decision point, every junction that was involved in the
decision point should be limited such that it acts as if only those
possibilities within it that would have passed the decision point
exist.
With unless, while, until, and loop, the associated block is
the conditional block where the junction gets filtered. With if,
the main block likewise filters the junctions; but the else block
also provides junction filtering, but in a way that's complementary to
what the main block does.
With short-circuit operators, the RHS counts as a block that
provides junction filtering based on what it would take for the LHS to
avoid tripping the short-circuit behavior. Similarly, ?? :: treats
the expression following the ?? as a junction-filtering block and
the expression following the :: as a complementary junction-filtering
block, in direct analogy to if/else, above.
Finally, there's the when statement: as with if, etc., the block
that follows the when statement filters junctions according to the
match criterion. However, when is a bit more complicated in terms
of getting it to DWIM w.r.t. junctions. Because of the way that
when works conceptually, I'd recommend that for the rest of the
block containing the when statement, it should provide the same sort
of complementary filtering that an else block does for an if
statement. That is:
given $x {
when $a { ... }
when $b { ... }
when *
}
...should not be thought of as being equivalent to:
given $x {
if $_ ~~ $a { ...; break }
if $_ ~~ $b { ...; break }
if $_ ~~ * {...; break }
}
...but rather:
given $x {
if $_ ~~ $a { ... }
else {
if $_ ~~ $b { ... }
else {
if $_ ~~ * { ... }
}
}
}
--
Another issue: what happens if conditional code mutates a junction
that it filtered? For example:
$x = any (-5 .. 5);
if $x 0 { $x++ };
At this point, which of the following does $x equal?
any(-4 .. 6) # the original junction gets mutated
any(-5 .. 0, 2 .. 6) # the filtered part of the original junction
gets mutated; the rest is untouched
any(2 .. 6) # the filtered part of the original junction gets
mutated; the rest is lost
--
Jonathan Dataweaver Lang
--
Jonathan Dataweaver Lang
Re: Getting rid of want()
On 2009 Mar 31, at 17:04, Moritz Lenz wrote: We had a discussion on #perl6 tonight about how to implement want(), and basically came to no conclusion. Then I came up with the idea that any lazy implementor will come up with: drop it from the language. Hm, I was under the impression that want() had already been dropped, and subs return captures. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part
Re: Getting rid of want()
Brandon S. Allbery KF8NH wrote: On 2009 Mar 31, at 17:04, Moritz Lenz wrote: We had a discussion on #perl6 tonight about how to implement want(), and basically came to no conclusion. Then I came up with the idea that any lazy implementor will come up with: drop it from the language. Hm, I was under the impression that want() had already been dropped, and subs return captures. S06 still has a chapter =head2 The Cwant function Cheers, Moritz
Re: Getting rid of want()
Moritz Lenz wrote:
Instead we should provide a very DWIMmy way to (lazily) create objects
that behave differently in different contexts.
That's precisely what the Contextual::Return module does for Perl 5.
It's less than perfect in Perl 5, because it has to be implemented via
runtime trickery, and hence is too slow. But that problem will disappear
in Perl 6 (and perhaps eventually in Perl 5 too) as I'll be able to use
macros to remove the runtime overheads.
Patrick pointed out that it can currently be done with
return $value but role { method Bool {
$code_for_boolean_context_here } };
This is essentially what Contextual::Return does, only with a
dwimmier syntax.
And if you propose to keep want(), how would you think it could work?
The only thing C::R doesn't handle that want() does is determining the
arity of a list context (i.e. how many elements are expected back).
That information can be very handy for optimization. And, yes, C::R
would already
handle it if I could think of a clean interface that was implementable
in Perl 5 without source filters.
Damian
S08 Draft questions (Captures and Signatures)
Yes, I know that there is no S08. I'm working on writing one, and I'd like some feedback to help me do so. My draft is going to be about Signatures and Captures. Thus, my questions: Invocants: * Is it illegal to specify an invocant in a sub, or is it merely nonsensical? That is, should the compiler complain, or should it silently treat the invocant as the first positional parameter? (The latter has the advantage that you don't have to worry about what the signature is being used for; it has the disadvantage of being, well, nonsensical: invocants are meaningless without the context of a method - and /maybe/ a role - to provide them meaning.) * Likewise, if I interpolate a signature with an invocant into another signature (somewhere other than at the start), is this an error, or will the invocant be silently converted into an ordinary positional parameter? * What types are you allowed to assign to an invocant? * Does anyone object to roles having an invocant, and that invocant referring to the class that is doing the role? Longnames: * Why are we using ;; to denote the end of a multi function's longname? I'm thinking that doubling up on the normal delimiter may make more sense - which would normally mean ,,, but would mean ;; if you're using a multidimensional argument list and the longname ends where a semicolon would normally go. * Can any required parameter be part of the longname, or are only positional parameters allowed? (I'm expecting the latter; but I'd like confirmation.) * Are placeholder parameters ever considered to be part of a function's longname? (I'm expecting that they aren't: if you want a longname, you ought to specify it in a formal signature.) Starting and Ending delimiters: * Why are pointy blocks forbidden from enclosing their signatures in parentheses, or from using the :( ... ) notation? Is this a holdover from the early days, when parentheses denoted a list? Or is there still a good reason not to allow such notation? * Why do parameterized roles use [ ... ] for their signatures instead of :( ... ) or ( ... )? Named parameters: * Must required named parameters be defined before optional named parameters are, or are we allowed to interleave the two? Placeholder parameters: * does the use of placeholder parameters interfere with the use of the slurpy parameters normally provided by the default signature (i.e., *...@_ and *%_)? I'm guessing not. -- Jonathan Dataweaver Lang
