Re: XOR does not work that way.
On Thu, 2 Jul 2009, TSa wrote: Martin D Kealey wrote: This solves both the human expectation (Would you like wine or beer or juice? Beer and juice please Sorry...) and the associativity problem: (a ^^ b) ^^ (c ^^ d) == a ^^ (b ^^ (c ^^ d)). I don't understand how the associativity problem is solved when we use unthrown exceptions to implement the one of n xor. The expression True True True is False without parens but (True True) True evaluates to True Assuming you meant ^^ rather than , then under my proposal, that's not the case. In particular, True ^^ True evaluates to TooManyException. If that exception is implicitly thrown, then that's what you get from the whole expression. If not, TooManyException ^^ Anything doesn't evaluate the right operand at all, and returns the value of the left operand. So you'd get the same answer regardless of whether you put brackets in or not. -Martin
Re: XOR does not work that way.
HaloO,
Martin D Kealey wrote:
Assuming you meant ^^ rather than , then under my proposal, that's not
the case.
Of course! Silly me, sorry.
In particular, True ^^ True evaluates to TooManyException. If that exception
is implicitly thrown, then that's what you get from the whole expression.
If not, TooManyException ^^ Anything doesn't evaluate the right operand at
all, and returns the value of the left operand.
So you'd get the same answer regardless of whether you put brackets in or
not.
I see. But I wouldn't make that an exception but ^^ returns a tristate
value instead of boolean. The third state besides True and False is
TooMany that evaluates to False in boolean context. But ^^ can react
to it as you describe. That solves the associativity problem, indeed.
Hmm, perhaps a TooFew value is nice as well. Then one can use that to
switch over the xor:
given $x ^^ $y ^^ $z
{
when TooMany {...}
when TooFew {...}
when True {...}
}
A nicer set of return values would be Many, One and Zero. Numeric values
could be Many = -1, One = 1 and Zero = 0, so that they numerify nicely.
So can we write that into the spec?
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: XOR does not work that way.
On Fri, Jul 03, 2009 at 09:40:12AM +0200, TSa wrote:
I see. But I wouldn't make that an exception but ^^ returns a tristate
value instead of boolean. The third state besides True and False is
TooMany that evaluates to False in boolean context. But ^^ can react
to it as you describe. That solves the associativity problem, indeed.
Hmm, perhaps a TooFew value is nice as well. Then one can use that to
switch over the xor:
given $x ^^ $y ^^ $z
{
when TooMany {...}
when TooFew {...}
when True {...}
}
A nicer set of return values would be Many, One and Zero. Numeric values
could be Many = -1, One = 1 and Zero = 0, so that they numerify nicely.
So can we write that into the spec?
I suspect that boolean operators should stay boolean operators,
and counting should usually be done with normal integers. In
other words, this is too much mechanism for too little payback.
Larry
Re: r27312 - docs/Perl6/Spec
On Mon, Jun 29, 2009 at 09:14:10PM -0700, Darren Duncan wrote: pugs-comm...@feather.perl6.nl wrote: +When it happens that the same module is available from more than one +authority, and the desired authority is not specified by the Cuse, +the version lineage that was created first wins, unless overridden by +local policy or by official abandonment by the original authority (as +determined either by the author or by community consensus in case the +author is no longer available or widely regarded as uncooperative). +An officially abandoned lineage will be selected only if it is the +only available lineage of locally installed modules. + +Once the authority is selected, then and only then is any version +selection done; the version specification is ignored until the +authority is selected. This implies that all official modules record +permanently when they were first installed in the official library, +and this creation date is considered immutable. + For wildcards any valid smartmatch selector works: use Dog:ver(v1.2.1 | v1.3.4):auth(/:i jrandom/); So now you've explicitly stated what I implicitly (or maybe explicitly) thought before, in that version numbers are always subordinate to authorities, and only make sense in the context of an authority, though an explicit authority doesn't have to be declared in user code. I propose that the canonical order of entity long names be altered so that the :auth always comes first, and :ver second, when both are used. For example: use Dog:auth(/:i jrandom/):ver(v1.2.1 | v1.3.4); The documentation should be in that order, not the other order. Then I think the syntax better corresponds to the actual interpretation, conceptually where each new trait (or trait-looking thing) is interpreted in the context of those before it. And I don't just mean example code, but explanation order too. I agree, and since you've got a pugs commit bit, feel free to fix it if I don't get to it. I've got about three other fundamental design issues distracting me at the moment, alas... Larry
r27385 - docs/Perl6/Spec
Author: moritz Date: 2009-07-03 18:48:33 +0200 (Fri, 03 Jul 2009) New Revision: 27385 Modified: docs/Perl6/Spec/S04-control.pod Log: [S04] 'constant' now scopes like 'our' TimToday++ changed that in S03 a while back, and forgot to update it here too. Modified: docs/Perl6/Spec/S04-control.pod === --- docs/Perl6/Spec/S04-control.pod 2009-07-03 15:09:52 UTC (rev 27384) +++ docs/Perl6/Spec/S04-control.pod 2009-07-03 16:48:33 UTC (rev 27385) @@ -94,7 +94,7 @@ As in Perl 5, Cour $foo introduces a lexically scoped alias for a variable in the current package. -The new Cconstant declarator introduces a lexically scoped name +The new Cconstant declarator introduces an our-scoped name for a compile-time constant, either a variable or named value, which may be initialized with a pseudo-assignment:
r27399 - docs/Perl6/Spec
Author: lwall
Date: 2009-07-04 05:34:15 +0200 (Sat, 04 Jul 2009)
New Revision: 27399
Modified:
docs/Perl6/Spec/S04-control.pod
Log:
[S04] allow certain value-producing blocks as statement prefixes
Modified: docs/Perl6/Spec/S04-control.pod
===
--- docs/Perl6/Spec/S04-control.pod 2009-07-04 02:39:55 UTC (rev 27398)
+++ docs/Perl6/Spec/S04-control.pod 2009-07-04 03:34:15 UTC (rev 27399)
@@ -12,8 +12,8 @@
Created: 19 Aug 2004
-Last Modified: 16 Jun 2009
-Version: 80
+Last Modified: 3 Jul 2009
+Version: 81
This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
@@ -1135,6 +1135,23 @@
my $compiletime = BEGIN { localtime };
our $temphandle = START { maketemp() };
+As with other statement prefixes, these value-producing constructs
+may be placed in front of either a block or a statement:
+
+my $compiletime = BEGIN localtime;
+our $temphandle = START maketemp();
+
+This can be particularly useful to expose a lexically scoped
+declaration to the surrounding context. Hence these declare the same
+variables with the same scope as the preceding example, but run the
+statements as a whole at the indicated time:
+
+BEGIN my $compiletime = localtime;
+START our $temphandle = maketemp();
+
+(Note, however, that the value of a variable calculated at compile
+time may not persist under run-time cloning of any surrounding closure.)
+
Code that is generated at run time can still fire off CCHECK
and CINIT blocks, though of course those blocks can't do things that
would require travel back in time.
