Re: UNIX commands: chmod
Jonathan Lang wrote:
How important is it that perl 6 maintains the notion that $foo and
@foo are entirely different things?
Very.
Also, there's the matter of "unneccessary paperwork": if the only
thing that I use the return value for is a boolean test, then all of
the effort involved in loading the filenames into a list was wasted
effort. Is there a way that the "lazy evaluation" concept could be
extended to function return values? Something like:
Partial Perl 5 implementation:
sub chmod {
my ($mode, @files) = @_;
$mode = _normalize_mode($mode);
my @failed;
FILE:
for my $file (@files) {
next FILE if chmod $mode, $file;
push @failed, $file;
}
use Contextual::Return;
# at this point, have the sub temporarily suspend operation.
return
BOOL { [EMAIL PROTECTED] }
SCALAR { [EMAIL PROTECTED] }
LIST { @failed }
}
You haven't studied the Contextual::Return module closely enough. Lazy
evaluation of the different return contexts is precisely what it already does. :-)
Damian
Re: UNIX commands: chmod
Larry wrote:
On Sun, Mar 26, 2006 at 02:40:03PM -0800, Larry Wall wrote:
: On the original question, I see it more as a junctional issue.
: Assuming we have only chmod($,$), this sould autothread:
:
: unless chmod MODE, all(@files) -> $oops {
: ???;
: profit();
: }
Except that junctional logic is allowed to fail as soon as it can be
falsified, so if some set of file is not chmodable, you'd randomly
get an error message for one of them. You really need something that
drives it to completion, like hyperop, or a pipe, or a list operator.
(Which is sort of what we already have, but the return status of such a
list operator should probably be a list, or something that does list.)
On the other hand, if it's only the boolean context that wants
to short-circuit a junction, maybe binding to $oops drives the
autothreading to completion somehow. (Or asking for a list value
from $oops, more likely).
H. I'm not sure I want to extend the QM metaphor to quite that much
magical action at a distance. ;-)
Especially since, if the boolean context doesn't itself drive the distributed
chmod() to completion, then something like:
die unless chmod $MODE, all(@files);
is potentially going to leave your filesystem in an unpredictable state. :-(
In other words, this is another example of "Don't use junctions in actions
with side-effects".
What we have here is a close analogy to the reporting requirements of pattern
matching. We have an operation that we want to have return several (possibly
lazily computed) pieces of outcome status. That's why we use an Match object
for the outcomes of pattern matches, and that's why I suggested a similarly
structured Outcome object for chmod (and other built-ins). It feels like
there's a more universal "status reporting from list-op" mechanism here, just
waiting to be generalized out.
Damian
[svn:perl6-synopsis] r8438 - doc/trunk/design/syn
Author: larry
Date: Mon Mar 27 04:37:45 2006
New Revision: 8438
Modified:
doc/trunk/design/syn/S06.pod
Log:
s/::/!!/
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podMon Mar 27 04:37:45 2006
@@ -269,7 +269,7 @@
sub infix:<(c)> ($text, $owner) { return $text but Copyright($owner) }
method prefix:<±> (Num $x) returns Num { return +$x | -$x }
-multi sub postfix: (Int $n) { $n < 2 ?? 1 :: $n*($n-1)! }
+multi sub postfix: (Int $n) { $n < 2 ?? 1 !! $n*($n-1)! }
macro circumfix:«» ($text) is parsed / .*? / { "" }
my $document = $text (c) $me;
Re: UNIX commands: chmod
Damian Conway wrote: > In other words, this is another example of "Don't use junctions in actions > with side-effects". Why not tag functions with side-effects as such (using a trait to that effect), and then say that short-circuit operators don't short-circuit when side-effects are involved? Or provide adverbs for the junctive functions that can be used to change their short-circuiting behavior. Or both. -- Jonathan Lang
'temp $x;' with no assignment
Hi,
my $x = 5;
{
temp $x;
# is $x 5 or undef?
}
# $x is definately 10
I think it should be 5 inside, because it makes it easy to write
things like:
my $x = 5;
{
temp $x++;
# $x is 6
}
# $x is 5 again
and otherwise pretty much DWIMs, except from a historical
perspective.
--
Yuval Kogman <[EMAIL PROTECTED]>
http://nothingmuch.woobling.org 0xEBD27418
pgpqVi7l1FtDo.pgp
Description: PGP signature
Re: 'temp $x;' with no assignment
On Mon, Mar 27, 2006 at 05:26:48PM +0200, Yuval Kogman wrote:
> Hi,
>
> my $x = 5;
> {
> temp $x;
> # is $x 5 or undef?
> }
> # $x is definately 10
How did $x become 10?!?!? :-)
> I think it should be 5 inside, because it makes it easy to write
> things like:
I think that if C is the new C, then immediately after the
C line, $x should hold whatever flavor of undef is appropriate.
>
> my $x = 5;
> {
> temp $x++;
> # $x is 6
> }
> # $x is 5 again
>
> and otherwise pretty much DWIMs, except from a historical
> perspective.
Is there some reason we're huffmannizing
my $x = 5;
{
temp $x = $MY::x + 1;# or whatever the proper syntax is
# $x is 6
}
$x = 5;
??
Can you elaborate an example that would show this to be a boon?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: 'temp $x;' with no assignment
On Mon, Mar 27, 2006 at 14:35:52 -0600, Jonathan Scott Duff wrote: > On Mon, Mar 27, 2006 at 05:26:48PM +0200, Yuval Kogman wrote: > How did $x become 10?!?!? :-) GHC has this lovely error: "my brain just exploded" I think Perl 6 should have a similar runtime warning about how it's usiong my short term memory for storage ;-) > I think that if C is the new C, then immediately after the > C line, $x should hold whatever flavor of undef is appropriate. > > Is there some reason we're huffmannizing Because 90% of the code that people use local for in perl 5 is for counting levels and automatically unwrapping them. The other 10% are for more complex values. -- Yuval Kogman <[EMAIL PROTECTED]> http://nothingmuch.woobling.org 0xEBD27418 pgpuO2LOJefPG.pgp Description: PGP signature
Re: 'temp $x;' with no assignment
On Mon, Mar 27, 2006 at 10:46:02PM +0200, Yuval Kogman wrote: > On Mon, Mar 27, 2006 at 14:35:52 -0600, Jonathan Scott Duff wrote: > > I think that if C is the new C, then immediately after the > > C line, $x should hold whatever flavor of undef is appropriate. > > > > Is there some reason we're huffmannizing > > > Because 90% of the code that people use local for in perl 5 is for > counting levels and automatically unwrapping them. The other 10% are > for more complex values. Make me believe your 90/10 numbers. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: 'temp $x;' with no assignment
On Mon, Mar 27, 2006 at 14:54:05 -0600, Jonathan Scott Duff wrote: > Make me believe your 90/10 numbers. http://cpansearch.bulknews.net/ is broken right now... =( -- Yuval Kogman <[EMAIL PROTECTED]> http://nothingmuch.woobling.org 0xEBD27418 pgpCMeQfldQFY.pgp Description: PGP signature
[svn:perl6-synopsis] r8451 - doc/trunk/design/syn
Author: larry Date: Mon Mar 27 14:57:02 2006 New Revision: 8451 Modified: doc/trunk/design/syn/S06.pod Log: Added def of prototypes from audreyt++ (with clarification of scoping). Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podMon Mar 27 14:57:02 2006 @@ -37,6 +37,10 @@ B (keyword: C) are routines that transcend class boundaries, and can have one or more invocants. +B (keyword: C) specify the commonalities (such +as parameter names, fixity and associativity) shared by all multis +of that name in the scope of the C declaration. + B (keyword: C) are methods (of a grammar) that perform pattern matching. Their associated block has a special syntax (see Synopsis 5).
[svn:perl6-synopsis] r8453 - doc/trunk/design/syn
Author: larry Date: Mon Mar 27 15:40:15 2006 New Revision: 8453 Modified: doc/trunk/design/syn/S10.pod doc/trunk/design/syn/S12.pod doc/trunk/design/syn/S13.pod Log: Finally checking in the autoloading changes despite uncertainty about AUTODEF. Modified: doc/trunk/design/syn/S10.pod == --- doc/trunk/design/syn/S10.pod(original) +++ doc/trunk/design/syn/S10.podMon Mar 27 15:40:15 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 27 Oct 2004 - Last Modified: 22 Feb 2006 + Last Modified: 28 Mar 2006 Number: 10 - Version: 4 + Version: 5 =head1 Overview @@ -36,7 +36,7 @@ named subroutine declarations. As a special exception, if a braceless C declaration occurs -as the first thing in a file, then it's taken to mean that the rest of +as the first executable statement in a file, then it's taken to mean that the rest of the file is Perl 5 code. package Foo; # the entire file is Perl 5 @@ -83,46 +83,105 @@ =head1 Autoloading -The package is the namespace that controls autoloading. There is still -an C hook that behaves as in Perl 5. However, that is being -replaced by various autoload hooks that distinguish declaration from -definition, and various types from one another. In particular: - -AUTOSCALAR -AUTOARRAY -AUTOHASH -AUTOSUB -AUTOMETH - -stand in for the declaration of objects; they are called when anyone -is searching for a name in the package (or module, or class), and the -name doesn't already exist in the package. (In particular, C<.can> -calls C when trying to determine if a class supports a -particular method.) The routines are expected to return a reference to -an object of the proper sort (i.e. a variable, subroutine, or method -reference), or undef if that name is not to be considered declared. -That object need not be defined yet, though the routine is allowed -to define it, and even install it into the symbol table if it likes. +A package (or any other similar namespace) can control autoloading. +However, Perl 5's C is being superseded by MMD autoloaders +that distinguish declaration from definition, but are not restricted +to declaring subs. A run-time declarator multisub is declared as: + +multi CANDO ( MyPackage, $type, $name: *%args --> Container) + +which stands in for the declaration of a container object within +another container object; it is called when anyone is searching for +a name in the package (or module, or class), and the name doesn't +already exist in the package. (In particular, C<.can> calls C +when trying to determine if a class supports a particular method.) +The arguments to C include type information on what kind +of object is expected in context, or this may be intuited from the +name requested. In any case, there may be multiple C routines +that are dispatched via MMD: + +multi CANDO ( MyPackage, Item, $name: *%args --> Container) +multi CANDO ( MyPackage, Array, $name: *%args --> Container) +multi CANDO ( MyPackage, Hash, $name: *%args --> Container) +multi CANDO ( MyPackage, Code, $name: *%args --> Container) + +The package itself is just passed as the +first argument, since it's the container object. Subsequent arguments +identify the desired type of the inner container and the "name" or +"key" by which the object is to be looked up in the outer container. +Such a name does not include its container name, unlike Perl 5's magical +C<$AUTOLOAD> variable. + +The C is expected to return a reference to an inner +container object of the proper sort (i.e. a variable, subroutine, +or method reference), or to a proxy object that can "autovivify" +lazily, or undef if that name is not to be considered declared in the +namespace in question. The declaration merely defines the interface +to the new object. That object need not be completely defined yet, +though the C routine is certainly I to define it +eagerly, and even install the inner object into the outer container +(the symbol table) if it wants to cache the declaration. + +At declaration time it might not yet be known whether the inner +container object will be used in lvalue or rvalue context; the use +of a proxy object can supply either readonly or rw semantics later. + +When the package in question is a class, it is also possible to declare +real methods or submethods: + +multi method CANDO ($self: Code, $name: *%args --> Container) + +multi submethod CANDO ($self: Item, $name: *%args --> Container) + +The method form is inherited by subclasses. Submethods are never +inherited but may still do MMD within the class. (Ordinary multisubs +are inherited only to the extent allowed by the MMD mechanism.) + +=for DISCUSSION +The following should really be in S12 if really works this way, but +I'm not sure it does. Seems like something is wrong, but I can't +quite put my finger on it. Something like,
[svn:perl6-synopsis] r8454 - doc/trunk/design/syn
Author: larry Date: Mon Mar 27 15:45:03 2006 New Revision: 8454 Modified: doc/trunk/design/syn/S04.pod Log: Changed temp (and let) to not default to undefine() any more. Modified: doc/trunk/design/syn/S04.pod == --- doc/trunk/design/syn/S04.pod(original) +++ doc/trunk/design/syn/S04.podMon Mar 27 15:45:03 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 19 Aug 2004 - Last Modified: 25 Feb 2006 + Last Modified: 28 Mar 2006 Number: 4 - Version: 10 + Version: 11 This document summarizes Apocalypse 4, which covers the block and statement syntax of Perl. @@ -90,7 +90,16 @@ value will be restored only if the current block exits unsuccessfully. (See Definition of Success below for more.) C and C temporize or hypotheticalize the value or the variable depending on whether you -do assignment or binding. +do assignment or binding. One other difference from Perl 5 is that +the default is not to undefine a variable. So + +temp $x; + +causes C<$x> to start with its current value. Use + +temp undefine $x; + +to get the Perl 5 behavior. =head1 Statement-ending blocks
Re: 'temp $x;' with no assignment
On Mon, Mar 27, 2006 at 02:54:05PM -0600, Jonathan Scott Duff wrote: : On Mon, Mar 27, 2006 at 10:46:02PM +0200, Yuval Kogman wrote: : > On Mon, Mar 27, 2006 at 14:35:52 -0600, Jonathan Scott Duff wrote: : > > I think that if C is the new C, then immediately after the : > > C line, $x should hold whatever flavor of undef is appropriate. : > > : > > Is there some reason we're huffmannizing : > : > : > Because 90% of the code that people use local for in perl 5 is for : > counting levels and automatically unwrapping them. The other 10% are : > for more complex values. : : Make me believe your 90/10 numbers. Doesn't matter what the numbers are, it's the right thing to do. The default undef hack stems from the days when local() was trying to fill the role of my() as well. Nowadays temp() should just mean: "Please arrange to restore yourself to your current value" and nothing more. (Well, plus the notion that, when applied to a mutator, the save/restore instruction is passed on to the mutatee to save itself before the mutation, not after.) The p5-to-p6 translator will turn local $x; into temp undefine $x; Larry
[svn:perl6-synopsis] r8457 - doc/trunk/design/syn
Author: larry
Date: Mon Mar 27 19:28:57 2006
New Revision: 8457
Modified:
doc/trunk/design/syn/S12.pod
Log:
s/undef/undefine/
Modified: doc/trunk/design/syn/S12.pod
==
--- doc/trunk/design/syn/S12.pod(original)
+++ doc/trunk/design/syn/S12.podMon Mar 27 19:28:57 2006
@@ -762,7 +762,7 @@
role Pet {
has $.collar = { Collar.new(Tag.new) };
method id () { return $.collar.tag }
- method lose_collar () { undef $.collar }
+ method lose_collar () { undefine $.collar }
}
If you want to parameterize the initial value of a role attribute,
