Re: [svn:perl6-synopsis] r8504 - doc/trunk/design/syn
On Sat, Apr 01, 2006 at 11:32:20AM +1100, Amos Robinson wrote: Sorry, I missed the boat. Everything seems to be moving at Pugs-speed these days :-) But what you thought was correct. Nicholas Clark
Re: Module requirements (was: Module::Build and installing in non-standard locations)
A. Pagaltzis wrote: * Adam Kennedy [EMAIL PROTECTED] [2006-04-01 04:10]: I guess the problem is that in Makefile.PL strictly speaking you're not _really_ meant to be doing any building of stuff. That's supposed to be what you do in make. So one solution to your problem might be to add something that defers that part until make. Of course, the problem is hacking EU::MM etc such that it actually works, which is a lot more effort than cheating and doing it in `Makefile.PL`. For example...erm... take a --make flag in the Makefile.PL that tells it to go off and do the generation of things, and then if not passed --make, run the normal stuff, but add an entry into the appropriate place so that a Makefile rule is added to trigger that callback. Or port to M::B and quit worrying… *cringe* Except that brings other problems... Adam K
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
On 4/1/06, Adam Kennedy [EMAIL PROTECTED] wrote: Similarly if somebody has an error in their Build.PL or Makefile.PL are you going to say that the installer doesnt work? Yes, absolutely. So you would file a bug with ExtUtils::MakeMaker or Module::Build when the pre-build script that accompanies a script has a syntax error in it? Lets hope you wouldnt be surprised when they file said bug report in /dev/nul Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
On 4/1/06, demerphq [EMAIL PROTECTED] wrote: On 4/1/06, Adam Kennedy [EMAIL PROTECTED] wrote: Similarly if somebody has an error in their Build.PL or Makefile.PL are you going to say that the installer doesnt work? Yes, absolutely. So you would file a bug with ExtUtils::MakeMaker or Module::Build when the pre-build script that accompanies a script has a syntax error in it? Lets hope you wouldnt be surprised when they file said bug report in /dev/nul That was meant to have a smiley face after it. :-) Seriously tho, how can such a situation be the installers fault? Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
Moin, On Saturday 01 April 2006 14:13, demerphq wrote: On 4/1/06, demerphq [EMAIL PROTECTED] wrote: On 4/1/06, Adam Kennedy [EMAIL PROTECTED] wrote: Similarly if somebody has an error in their Build.PL or Makefile.PL are you going to say that the installer doesnt work? Yes, absolutely. So you would file a bug with ExtUtils::MakeMaker or Module::Build when the pre-build script that accompanies a script has a syntax error in it? Lets hope you wouldnt be surprised when they file said bug report in /dev/nul That was meant to have a smiley face after it. :-) Seriously tho, how can such a situation be the installers fault? Easy, Makefile.PL, M::B or whatever are all parts of the install process. It's just that different parties are responsibe for different parts. (Just think how my Makefile.PLs broke because there was a change in YAML.) You just complain to the person most likely to fix the problem. Best wishes, Tels -- Signed on Sat Apr 1 18:28:01 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. A bus station is where a bus stops. A train station is where a train stops. On my desk I have a work station. -- Unknown pgpNZOQIQtzaH.pgp Description: PGP signature
[svn:perl6-synopsis] r8520 - doc/trunk/design/syn
Author: autrijus Date: Sat Apr 1 10:32:53 2006 New Revision: 8520 Modified: doc/trunk/design/syn/S02.pod Log: * S02: destill the compoments of an Arguments object, and specify the $() @() %() () casting forms for them. Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podSat Apr 1 10:32:53 2006 @@ -14,7 +14,7 @@ Date: 10 Aug 2004 Last Modified: 1 Apr 2006 Number: 2 - Version: 18 + Version: 19 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -393,6 +393,17 @@ bound to. Some bindings are sensitive to multiple dimensions while others are not. +You may cast CArguments to other types with a prefix sigil operator: + +$args = \3; # same as $args = \(3) +$$args; # same as $args as Scalar or Scalar($args) +@$args; # same as '$args as Array or Array($args) +%$args; # same as '$args as Hash or Hash($args) +$args; # same as '$args as Code or Hash($args) + +Casted as an array, you can access to all positionals. Casted as a hash, all +nameds. As a scalar, the invocant. As a code, the slurpy nameless block. + =item * A signature object (CSignature) may be created with coloned parens: @@ -430,7 +441,7 @@ foo:(Int,Num) It still just returns a function reference. A call may also be partially -applied by using a tuple literal as a postfix operator: +applied by using an argument list literal as a postfix operator: foo\(1,2,3,:miceblind)
[svn:perl6-synopsis] r8521 - doc/trunk/design/syn
Author: autrijus Date: Sat Apr 1 10:34:41 2006 New Revision: 8521 Modified: doc/trunk/design/syn/S03.pod Log: * S03: Value-type semantics; $obj.id.true disambiguates between prototypes and instances; user-defined value objects has to return some builtin values as their .id. Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podSat Apr 1 10:34:41 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 8 Mar 2004 - Last Modified: 25 Feb 2006 + Last Modified: 1 Apr 2006 Number: 3 - Version: 13 + Version: 14 =head1 Operator renaming @@ -84,14 +84,22 @@ types, checks whether they have the same identity value. For reference types that do not define an identity, the reference itself is used (eg. it is not true that C[1,2] === [1,2], but it is true that C[EMAIL PROTECTED] === [EMAIL PROTECTED]). -Any reference type may pretend to be a value type by defining a C.id method. -(It may also overload C infix:=== for more efficient comparison of -any two objects of that type, but it had better return the same result as if -the two identity values had been generated and compared.) Two values are -never equivalent unless they are of exactly the same type. By contrast, -Ceq always coerces to string, while C== always coerces to numeric. -In fact, C$a eq $b really means C~$a === ~$b and C$a == $b means -C+$a === +$b. + +Any reference type may pretend to be a value type by defining a C.id method +which returns a built-in value, i.e. an immutable object or a native value, +as specified in S06. + +Because Perl 6 uses a false C.id to signify a non-instantiated prototype, +all instances should arrange to return a C.id that boolifies to true. + +A class may also overload C infix:=== for more efficient comparison of +any two objects of that type, but it must return the same result as if +the two identity values had been generated and compared. + +Two values are never equivalent unless they are of exactly the same type. By +contrast, Ceq always coerces to string, while C== always coerces to +numeric. In fact, C$a eq $b really means C~$a === ~$b and C$a == $b +means C+$a === +$b. Note also that, while string hashes use Ceq semantics by default, object hashes use C=== semantics.
[svn:perl6-synopsis] r8522 - doc/trunk/design/syn
Author: autrijus Date: Sat Apr 1 10:35:35 2006 New Revision: 8522 Modified: doc/trunk/design/syn/S04.pod Log: * S04: Specify fail semantics in detail, and the relationship to the environmental $! variable. Handling and propagation of unthrown exceptions clarified. Modified: doc/trunk/design/syn/S04.pod == --- doc/trunk/design/syn/S04.pod(original) +++ doc/trunk/design/syn/S04.podSat Apr 1 10:35:35 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 19 Aug 2004 - Last Modified: 28 Mar 2006 + Last Modified: 1 Apr 2006 Number: 4 - Version: 11 + Version: 12 This document summarizes Apocalypse 4, which covers the block and statement syntax of Perl. @@ -464,38 +464,34 @@ =head1 Exceptions As in Perl 5, many built-in functions simply return undef when you ask -for a value out of range, or the function fails somehow. Unlike in -Perl 5, these may be interesting values of undef that contain -information about the error. If you try to use an undefined value, -that information can then be conveyed to the user. In essence, undef -can be an unthrown exception object that just happens to return 0 when -you ask it whether it's defined or it's true. Since C$! contains the -current error code, saying Cdie $! will turn an unthrown exception -into a thrown exception. (A bare Cdie does the same.) +for a value out of range, or the function fails somehow. Perl 6 has +CFailure objects, which refers to an unthrown CException object in +C$! and knows whether it has been handled or not. + +If you test a CFailure for C.id, C.defined or C.true, it causes +C$! to mark the exception as Ihandled, and acts as a harmless CUndef +value thereafter. Any other use of the CFailure will throw its associated +exception immediately. + +Because the Cenv variable C$! contains all exceptions collected in the +current lexical scope, saying Cdie $! will throw all exceptions, +whether they were handled or not. A bare Cdie/Cfail takes C$! as the +default argument. + +At scope exit, C$! discards all handled exceptions from itself, then performs +a GC check for all remaining (unhandled) exceptions. If all of them are still +alive (e.g. by becoming part of the return value), then they are appended to +C CALLER::$! . Otherwise, it calls Cdie to throw those exceptions +as a single new exception, which may then be caught with a CCATCH block in +the current (or caller's) scope. You can cause built-ins to automatically throw exceptions on failure using use fatal; -The Cfail function responds to the caller's use fatal state. It +The Cfail function responds to the caller's Cuse fatal state. It either returns an unthrown exception, or throws the exception. -If an exception is raised while C$! already contains an exception -that is active and unhandled, no information is discarded. The old -exception is pushed onto the exception stack within the new exception, -which is then bound to C$! and, hopefully, propagated. The default -printout for the new exception should include the old exception -information so that the user can trace back to the original error. -(Likewise, rethrown exceptions add information about how the exception -is propagated.) The exception stack within C$! is available as -C$![]. - -Exception objects are born unhandled. The C$! object keeps track of -whether it's currently handled or unhandled. The exception in C$! still -exists after it has been caught, but catching it marks it as handled -if any of the cases in the switch matched. Handled exceptions don't -require their information to be preserved if another exception occurs. - =head1 Closure traits A CCATCH block is just a trait of the closure containing it. Other
[svn:perl6-synopsis] r8523 - doc/trunk/design/syn
Author: autrijus
Date: Sat Apr 1 10:36:25 2006
New Revision: 8523
Modified:
doc/trunk/design/syn/S05.pod
Log:
* S05: $/.() is now $$/. $() still works as $$/, and we
have @() %() forms that maps to @$/ and %$/.
Modified: doc/trunk/design/syn/S05.pod
==
--- doc/trunk/design/syn/S05.pod(original)
+++ doc/trunk/design/syn/S05.podSat Apr 1 10:36:25 2006
@@ -13,9 +13,9 @@
Maintainer: Patrick Michaud [EMAIL PROTECTED]
Date: 24 Jun 2002
- Last Modified: 25 Feb 2006
+ Last Modified: 1 Apr 2006
Number: 5
- Version: 12
+ Version: 13
This document summarizes Apocalypse 5, which is about the new regex
syntax. We now try to call them rules because they haven't been
@@ -1120,18 +1120,18 @@
=item *
-When called as a closure, a Match object evaluates to its underlying
+When used as a scalar, a Match object evaluates to its underlying
result object. Usually this is just the entire match string, but
you can override that by calling Creturn inside a rule:
-my $moose = m:{
+my $moose = $(m:{
antler body
{ return Moose.new( body = $body().attach($antler) ) }
# match succeeds -- ignore the rest of the rule
-}.();
+});
-C$() is a shorthand for C$/.() or C$/(). The result object
-may be of any type, not just a string.
+C$() is a shorthand for C$($/). The result object may be of any type,
+not just a string.
You may also capture a subset of the match as the result object using
the C (...) construct:
@@ -1149,8 +1149,8 @@
This means that these two work the same:
-/ moose { $moose.() as Moose } /
-/ moose { $mooseas Moose } /
+/ moose { return $$moose as Moose } /
+/ moose { return $moose as Moose } /
=item *
@@ -1172,8 +1172,13 @@
$mystring = { m:w/ (\S+) = (\S+)/[] };
+Or cast it into an array:
+
+ $mystring = @( m:w/ (\S+) = (\S+)/ );
+
Note that, as a scalar variable, C$/ doesn't automatically flatten
-in list context. Use C@$/ or C$/[] to flatten as an array.
+in list context. Use C@() as a shorthand for C@($/) to flatten
+the positional captures under list context.
=item *
@@ -1185,8 +1190,8 @@
capture datatypes.)
Note that, as a scalar variable, C$/ doesn't automatically flatten
-in list context. Use C%$/ or C$/{} to flatten as a hash, or bind
-it to a variable of the appropriate type.
+in list context. Use C%() as a shorthand for C%($/) to flatten as a
+hash, or bind it to a variable of the appropriate type.
=item *
[svn:perl6-synopsis] r8524 - doc/trunk/design/syn
Author: autrijus
Date: Sat Apr 1 10:43:08 2006
New Revision: 8524
Modified:
doc/trunk/design/syn/S06.pod
Log:
* S06: De-mystifying the logic for named arguments.
*$x is now just casting $x as an Arguments object.
Differ between foo; and foo(); via zero-dimensional slices.
Split the semantic of Undef and Failure types.
Add a more comprehensive list of builtin classes.
Allow named returns via the return function.
Routine's .wrap semantic is now much clarified.
?SUB is renamed to ?ROUTINE; remove the $?BLOCKLABEL
and $?SUBNAME magicals (they are now just methods);
clarify the ?BLOCK means the immediate block, even
if it's part of a routine.
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podSat Apr 1 10:43:08 2006
@@ -15,7 +15,7 @@
Date: 21 Mar 2003
Last Modified: 1 Apr 2006
Number: 6
- Version: 20
+ Version: 21
This document summarizes Apocalypse 6, which covers subroutines and the
@@ -370,7 +370,6 @@
subscript instead of the sigil. The C: is not functioning as an
operator here, but as a modifier of the following token:
-
doit %hash:a,1,2,3;
doit %hash:{'b'},1,2,3;
@@ -390,15 +389,15 @@
C:p adverb may be placed on any hash reference to make it mean
pairs instead of values.)
-Pairs are recognized syntactically at the call level and mystically
-transformed into special CNamed objects that may be bound to
-positionals only by name, not as ordinary positional CPair objects.
-Leftover special CNamed objects can be slurped into a slurpy hash.
+Pair constructors are recognized syntactically at the call level and
+put into the named slot of the CArguments structure. Hence they may be
+bound to positionals only by name, not as ordinary positional CPair
+objects. Leftover named arguments can be slurped into a slurpy hash.
After the positional and named arguments, all the rest of the arguments
are taken to be list arguments. Any pairs within the list are taken
-to be list elements rather than named arguments, and mystically show
-up as CPair arguments even if the compiler marked them as CNamed.
+to be list elements rather than named arguments, and show up as CPair
+arguments even if the compiler marked them as named.
It is possible that named pairs are not really a separate type; it
would be sufficient to have a bit somewhere in the Pair that can be
@@ -498,7 +497,7 @@
$comparison = numcmp(:y(7), :x(2));
Passing the wrong number of required arguments to a normal subroutine
-is a fatal error. Passing a NamedArg that cannot be bound to a normal
+is a fatal error. Passing a named argument that cannot be bound to a normal
subroutine is also a fatal error. (Methods are different.)
The number of required parameters a subroutine has can be determined by
@@ -664,11 +663,14 @@
=head2 Argument list binding
-The underlying argument list (List) object may be bound to a single
-scalar parameter marked with a C\:
+The underlying CArguments object may be bound to a single scalar
+parameter marked with a C\.
-sub foo (\$args) { say $args.perl; bar.call(*$args); }
sub bar ($a,$b,$c,:$mice) { say $mice }
+sub foo (\$args) { say $args.perl; bar.call($args); }
+
+The C.call method of CCode objects accepts a single CArguments
+object, and calls it without introducing a CCALLER frame.
foo 1,2,3,:miceblind;# says \(1,2,3,:miceblind) then blind
@@ -685,16 +687,27 @@
=head2 Flattening argument lists
-The unary prefix operator C* dereferences its operand (which allows
-the elements of an array or iterator or List or Tuple to be used as
-part of an argument list). The C* operator also causes its operand --
-and any subsequent arguments in the argument list -- to be evaluated in
-list context. It also turns off syntactic recognition of named pairs.
-The eventual argument list will be parsed at call time for named pairs.
-All contiguous pairs are treated as named arguments until the first
-non-Pair, and the rest of the arguments are considered slurpy args.
-[XXX still underspecified...]
+The unary prefix operator C* casts a value to an CArguments
+object, then splices it into the argument list it occurs in.
+
+Casting CArguments to CArguments is a no-op:
+
+*(\(1, x=2));# Arguments, becomes \(1, x=2)
+
+CPair and CHash become named arguments:
+
+*(x=1); # Pair, becomes \(x=1)
+*{x=1, y=2};# Hash, becomes \(x=1, y=2)
+
+CList (also CTuple, CRange, etc.) are simply turned into
+positional arguments:
+*(1,2,3); # Tuple, becomes \(1,2,3)
+*(1..3); # Range, becomes \(1,2,3)
+*(1..2, 3); # List, becomes \(1,2,3)
+*([x=1, x=2]); # List (from an Array), becomes \((x=1), (x=2))
+
+For example:
sub foo($x, $y, $z) {...}# expects three
[svn:perl6-synopsis] r8525 - doc/trunk/design/syn
Author: autrijus Date: Sat Apr 1 10:43:58 2006 New Revision: 8525 Modified: doc/trunk/design/syn/S11.pod Log: * S11: Allow user-defined dynamic exportation with EXPORT routines, which assume the semantic from Damian's Perl6::Export::Attrs. The magical export dispatcher is now EXPORTALL. Modified: doc/trunk/design/syn/S11.pod == --- doc/trunk/design/syn/S11.pod(original) +++ doc/trunk/design/syn/S11.podSat Apr 1 10:43:58 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 27 Oct 2004 - Last Modified: 17 Mar 2006 + Last Modified: 1 Apr 2006 Number: 11 - Version: 10 + Version: 11 =head1 Overview @@ -105,7 +105,18 @@ } The CFoo module will export Cfoo, Cbar and Cbaz by default; -calling CFoo::Bar.import will import Cbar and Cbaz at runtime. +calling CFoo::Bar.EXPORTALL will export Cbar and Cbaz at runtime +to the caller's package. + +=head1 Dynamic exportation + +The default CEXPORTALL handles symbol exports by removing recognized +export items and tagsets from the argument list, then calls the CEXPORT +subroutine in that module (if there is one), passing in the remaining +arguments. + +If the exporting module is actually a class, CEXPORTALL will invoke its +CEXPORT method with the class itself as the invocant. =head1 Compile-time Importation @@ -155,7 +166,7 @@ at runtime cannot import into the lexical scope: require Sense; -Sense.import; # goes to the OUR scope by default, not MY +Sense.EXPORTALL; # goes to the OUR scope by default, not MY =head1 Importing from a pseudo-package
[svn:perl6-synopsis] r8526 - doc/trunk/design/syn
Author: autrijus
Date: Sat Apr 1 10:44:53 2006
New Revision: 8526
Modified:
doc/trunk/design/syn/S12.pod
Log:
* S12: The call form can now be used to call the next
MMD or SMD candidate.
A proto declaration needs to happen before multis.
Fix a misuse of .call method.
Modified: doc/trunk/design/syn/S12.pod
==
--- doc/trunk/design/syn/S12.pod(original)
+++ doc/trunk/design/syn/S12.podSat Apr 1 10:44:53 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 27 Oct 2004
- Last Modified: 23 Feb 2006
+ Last Modified: 1 Apr 2006
Number: 12
- Version: 10
+ Version: 11
=head1 Overview
@@ -542,6 +542,13 @@
:omit(Selector) # only classes that don't match selector
:include(Selector) # only classes that match selector
+In addition to Cnext METHOD, the special function Ccall dispatches
+to the next candidate, possibly with a new argument list:
+
+call; # calls with the original arguments
+call(); # calls with no arguments
+call(1,2,3);# calls with a different set of arguments
+
=head1 Parallel dispatch
Any of the method call forms may be turned into a hyperoperator by
@@ -681,6 +688,8 @@
The Csub keyword is optional after either Cmulti or Cproto.
+A Cproto declaration must come before any matching multis, if at all.
+
=head1 Roles
Classes are primarily in charge of object management, and only
@@ -704,7 +713,7 @@
method feed ($food) {
$food.open_can;
$food.put_in_bowl;
- self.call;
+ self.some_other_method;
}
}
RE: [svn:perl6-synopsis] r8520 - doc/trunk/design/syn
-Original Message- +You may cast CArguments to other types with a prefix sigil operator: + +$args = \3; # same as $args = \(3) +$$args; # same as $args as Scalar or Scalar($args) +@$args; # same as '$args as Array or Array($args) +%$args; # same as '$args as Hash or Hash($args) +$args; # same as '$args as Code or Hash($args) Shouldn't this last one be +$args; # same as '$args as Code or Code($args) Joe Gottman
[svn:perl6-synopsis] r8527 - doc/trunk/design/syn
Author: autrijus Date: Sat Apr 1 11:56:07 2006 New Revision: 8527 Modified: doc/trunk/design/syn/S02.pod Log: * Fix typo as reported by Joe Gottman. Explicitly specify the rvalue-ness, interpolated-ness, and default-to-match-object-ness of prefix sigil operators. Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podSat Apr 1 11:56:07 2006 @@ -399,11 +399,16 @@ $$args; # same as $args as Scalar or Scalar($args) @$args; # same as '$args as Array or Array($args) %$args; # same as '$args as Hash or Hash($args) -$args; # same as '$args as Code or Hash($args) +$args; # same as '$args as Code or Code($args) Casted as an array, you can access to all positionals. Casted as a hash, all nameds. As a scalar, the invocant. As a code, the slurpy nameless block. +All prefix sigil operators accept one positional argument, evaluated in +scalar context as a rvalue. They can interpolate in strings if called with +parentheses. The C$(), C@() and C%() forms defaults to C$/ as the +implicit argument. + =item * A signature object (CSignature) may be created with coloned parens:
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
On Saturday 01 April 2006 03:41, demerphq wrote: So you would file a bug with ExtUtils::MakeMaker or Module::Build when the pre-build script that accompanies a script has a syntax error in it? Don't forget with every distribution that marked that distribution as a dependency. -- c
[svn:perl6-synopsis] r8528 - doc/trunk/design/syn
Author: autrijus
Date: Sat Apr 1 14:01:16 2006
New Revision: 8528
Modified:
doc/trunk/design/syn/S06.pod
doc/trunk/design/syn/S12.pod
doc/trunk/design/syn/S13.pod
Log:
* S06+S12: Split the old multiple-dispatch into two distinct ideas:
- Method call vs Subroutine call
- Multiple dispatch vs Single dispatch
A multi-method or multi-sub is simply a method/sub that has variants,
and has nothing to do with transcending class boundaries.
TimToady With a multi-sub, it's the sub-ness that transcends class
boundaries, not the multi-ness.
Consequently, $x.foo(3) still falls back to foo($x, 3) if there is
not such method, but foo($x, 3) won't magically call the foo method
even if it's declared as a multi-method. To get the old magical dual
behaviour, use multi submethod.
multi foo within a class/role now means multi method foo.
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podSat Apr 1 14:01:16 2006
@@ -34,13 +34,6 @@
subroutines masquerading as methods. They have an invocant and belong to
a particular kind or class.
-BMultimethods (keyword: Cmulti) are routines that transcend class
-boundaries, and can have one or more invocants.
-
-BPrototypes (keyword: Cproto) specify the commonalities (such
-as parameter names, fixity and associativity) shared by all multis
-of that name in the scope of the Cproto declaration.
-
BRules (keyword: Crule) are methods (of a grammar) that perform
pattern matching. Their associated block has a special syntax (see
Synopsis 5).
@@ -52,6 +45,32 @@
as they are parsed (i.e. at compile-time). Macros may return another
source code string or a parse-tree.
+=head1 Routine modifiers
+
+BMultimethods (keyword: Cmulti) are routines that can have multiple
+variants that shares the same name, selected by arity, types, or some
+other constraints. They may have multliple invocants.
+
+BPrototypes (keyword: Cproto) specify the commonalities (such
+as parameter names, fixity and associativity) shared by all multis
+of that name in the scope of the Cproto declaration.
+
+A modifier keyword may occur before the routine keyword in a named routine:
+
+proto sub foo {...}
+multi sub foo {...}
+proto method bar {...}
+multi method bar {...}
+
+If the routine keyword is omitted, it defaults to Cmethod inside a
+class or role, and Csub inside a module or package.
+
+class C {
+multi foo {...} # multi method foo
+}
+module M {
+multi bar {...} # multi sub bar
+}
=head2 Named subroutines
@@ -427,7 +446,7 @@
=head2 Invocant parameters
-A method invocant is specified as the first parameter in the parameter
+A method invocant may be specified as the first parameter in the parameter
list, with a colon (rather than a comma) immediately after it:
method get_name ($self:) {...}
@@ -442,31 +461,36 @@
Multimethod and multisub invocants are specified at the start of the parameter
list, with a colon terminating the list of invocants:
-multi sub handle_event ($window, $event: $mode) {...}# two invocants
+multi sub handle_event ($window, $event: $mode) {...} # two invocants
+multi method set_name ($self, $name: $nick) {...} # two invocants
-Multi invocant arguments are passed positionally, though the first
-invocant can be passed via the method call syntax if the multi happens
-to be defined as a multi method within the class of the first invocant.
-
-# Multimethod calls...
-handle_event($w, $e, $m);
-$w.handle_event($e, $m);
+If the parameter list for a Cmulti contains no colon to delimit
+the list of invocant parameters, then all positional parameters are
+considered invocants. If it's a Cmulti method and Cmulti submethod,
+an additional implicit unamed Cself invocant is prepended to the
+signature list.
+
+For the purpose of matching positional arguments against invocant parameters,
+the invocant argument passed via the method call syntax is considered the
+first positional argument:
+
+handle_event($w, $e, $m); # calls the multi sub
+$w.handle_event($e, $m);# ditto, but only if there is no
+# suitable $w.handle_event method
Invocants may also be passed using the indirect object syntax, with a colon
after them. The colon is just a special form of the comma, and has the
same precedence:
-# Indirect method call...
-set_name $obj: Sam;
-
-# Indirect multimethod call...
-handle_event $w, $e: $m;
+set_name $obj: Sam; # try $obj.set_name(Sam) first, then
+# fall-back to set_name($obj, Sam)
+$obj.set_name(Sam); # same as the above
Passing too many or too few invocants is a fatal error if no matching
definition can be found.
An invocant is the topic of the corresponding method or
[svn:perl6-synopsis] r8529 - doc/trunk/design/syn
Author: autrijus Date: Sat Apr 1 14:07:20 2006 New Revision: 8529 Modified: doc/trunk/design/syn/S06.pod doc/trunk/design/syn/S12.pod doc/trunk/design/syn/S13.pod Log: * Bump version for the affected S06, S12 and S13. Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podSat Apr 1 14:07:20 2006 @@ -15,7 +15,7 @@ Date: 21 Mar 2003 Last Modified: 1 Apr 2006 Number: 6 - Version: 21 + Version: 22 This document summarizes Apocalypse 6, which covers subroutines and the Modified: doc/trunk/design/syn/S12.pod == --- doc/trunk/design/syn/S12.pod(original) +++ doc/trunk/design/syn/S12.podSat Apr 1 14:07:20 2006 @@ -14,7 +14,7 @@ Date: 27 Oct 2004 Last Modified: 1 Apr 2006 Number: 12 - Version: 11 + Version: 12 =head1 Overview Modified: doc/trunk/design/syn/S13.pod == --- doc/trunk/design/syn/S13.pod(original) +++ doc/trunk/design/syn/S13.podSat Apr 1 14:07:20 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 2 Nov 2004 - Last Modified: 21 Aug 2005 + Last Modified: 1 Apr 2006 Number: 13 - Version: 3 + Version: 4 =head1 Overview
replacement of $
Recently I had time to think about the $ symbol we use in Perl. I think Perl has been using the USD symbol for too long, and I'm now sure that it's time to replace it. After some research I came to the conclusion that the best fit is the euro symbol (€). So, spread the word, Perl 6 will require you to replace all the $ in your scripts with €. That's just a regex after all...
Re: replacement of $
At 15:04 -0800 1/4/06, Larry Wall wrote: Recently I had time to think about the $ symbol we use in Perl. I think Perl has been using the USD symbol for too long, and I'm now sure that it's time to replace it. After some research I came to the conclusion that the best fit is the euro symbol (¤). So, spread the word, Perl 6 will require you to replace all the $ in your scripts with ¤. That's just a regex after all... But $ isn't specifically a USD symbol. Its used by Canada and Australia too, if not more places. Its multi-country like the Euro is. Perhaps what we need is a more universal currency. I suggest gold. So every relevant symbol name could start with 'Au' instead of '$', and an advantage of this is that it is still easy to type on any keyboard. -- Darren Duncan
Re: replacement of $
On Sat, Apr 01, 2006 at 03:11:27PM -0800, Larry Wall wrote: : : : Recently I had time to think about the $ symbol we use in Perl. : : I think Perl has been using the USD symbol for too long, and I'm now sure : that it's time to replace it. After some research I came to the conclusion : that the best fit is the euro symbol (€). : : So, spread the word, Perl 6 will require you to replace all the $ in your : scripts with €. That's just a regex after all... Hmm, like anyone's going to believe you... Anyone can forge Larry-like email. Look how easy it is for *me* to forge email from Larry even though I'm in Japan right now. All you have to do is end most of your paragraphs with ... and throw in a few Hmms here and there And then there's all these checkins I've been forging from Audrey. Piece o' cake... Now, gettin' myself made up to look like Larry for the Bugs Manifesto, that was a wee bit more challenging, but I think most people were fooled... TomTiady, AKA 落第の駱駝, AKA Larry Boy (the tsukemono, not the pickle)
Re: replacement of $
On Sat, Apr 01, 2006 at 03:42:11PM -0800, Darren Duncan wrote: : Perhaps what we need is a more universal currency. I suggest gold. : : So every relevant symbol name could start with : 'Au' instead of '$', and an advantage of this is : that it is still easy to type on any keyboard. For those of us without ASCII keyboards, it'd be a lot easier to type ⾦. Larry (the real one (really! (heh, heh)))
[OT] TDD + Pair Programming
I have never actually had an opportunity to practice this, but I've always felt that the most obvious way to combine test-driven development with pair programming was to have one person write test code while the other person writes application code. Presumably they might change roles periodically, but I'm not sure if they would actually work at the same terimnal. However, I've never heard anyone excplicitly advocate for this approach. Is this actually happening and I'm just not aware of it? Or is there some obstacle to this approach that I haven't considered? -Jeff __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [svn:perl6-synopsis] r8520 - doc/trunk/design/syn
a == autrijus [EMAIL PROTECTED] writes: a +You may cast CArguments to other types with a prefix sigil operator: a + a +$args = \3; # same as $args = \(3) a +$$args; # same as $args as Scalar or Scalar($args) a +@$args; # same as '$args as Array or Array($args) a +%$args; # same as '$args as Hash or Hash($args) a +$args; # same as '$args as Code or Hash($args) a + a +Casted as an array, you can access to all positionals. Casted as a +a hash, all nameds. As a scalar, the invocant. As a code, the a +slurpy nameless block. s/casted/cast/g and i would word those as 'cast into an array'. here is my rewrite: When cast into an array, you can access all the positional arguments; Into a hash, all named arguments; Into a scalar, the invocant; Into code, into slurpy nameless block. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: [svn:perl6-synopsis] r8520 - doc/trunk/design/syn
Uri Guttman wrote: When cast into an array, you can access all the positional arguments; Into a hash, all named arguments; Into a scalar, the invocant; Into code, into slurpy nameless block. The last 'into' should be 'the'. s/Into/into/g -- Affijn, Ruud
Re: [OT] TDD + Pair Programming
* Jeffrey Thalhammer [EMAIL PROTECTED] [2006-04-02 02:05]: I have never actually had an opportunity to practice this, but I've always felt that the most obvious way to combine test-driven development with pair programming was to have one person write test code while the other person writes application code. Seems awkward to me. The idea of test-*driven* development is that the guy who writes application code writes only as much as is necessary to pass the existing tests – the two can’t be done independently of each other to the extent that you seem to be suggesting. Also seems to miss the point. The idea of writing tests first is that you get a feedback loop between a) designing and using an API prior to implementing it and b) attempting to implementing the design. That is, you get a feedback loop where the API design and the implementation process inform each other. The process you suggest seems more applicable to cases where there already is a very precise design spec and the development effort is solely straightforward implementation. In that case, yes, one developer can write tests and another can write the implementation. So, it depends. Most of the time, your idea is not applicable; but sometimes, such as when you’re implementing a standard (say, you’re writing a HTTP library or an XML parser or whatever), it is a good approach. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: [svn:perl6-synopsis] r8520 - doc/trunk/design/syn
On Sun, Apr 02, 2006 at 02:15:46AM +0200, Ruud H.G. van Tol wrote: : Uri Guttman wrote: : : When cast into an array, you can access all the positional : arguments; Into a hash, all named arguments; Into a scalar, the : invocant; Into code, into slurpy nameless block. : : The last 'into' should be 'the'. : : s/Into/into/g s[ s ( .* ) g ][s:g$0] TomTiedy
Re: [OT] TDD + Pair Programming
On Apr 1, 2006, at 4:04 PM, Jeffrey Thalhammer wrote: I have never actually had an opportunity to practice this, but I've always felt that the most obvious way to combine test-driven development with pair programming was to have one person write test code while the other person writes application code. That approach is probably worth an experiment for some project, but it's not the normal meaning of Test Driven Development. In normal TDD you spend a very small amount of time writing a test, and then another alms amount of time writing *just enough* application code to make the test pass. Each mini-iteration might take between 1 and 5 minutes. Here's a pretty good Power Point slide show that demonstrates the process: http://www.butunclebob.com/files/downloads/Bowling%20Game%20Kata.ppt --- Matisse Enzer [EMAIL PROTECTED] http://www.matisse.net/ - http://www.eigenstate.net/
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
On Mar 31, 2006, at 11:02 AM, Adam Kennedy wrote: Most end users don't see the build stage as being somehow distinct, all they want to do is install a module. I agree 100% with that, and urge others to keep that in mind. --- Matisse Enzer [EMAIL PROTECTED] http://www.matisse.net/ - http://www.eigenstate.net/
[svn:perl6-synopsis] r8531 - doc/trunk/design/syn
Author: autrijus Date: Sat Apr 1 19:35:01 2006 New Revision: 8531 Modified: doc/trunk/design/syn/S02.pod Log: * S02: typo fix and wording cleanup from Uri Guttman. Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podSat Apr 1 19:35:01 2006 @@ -401,8 +401,9 @@ %$args; # same as '$args as Hash or Hash($args) $args; # same as '$args as Code or Code($args) -Casted as an array, you can access to all positionals. Casted as a hash, all -nameds. As a scalar, the invocant. As a code, the slurpy nameless block. +When cast into an array, you can access all the positional arguments; Into a +hash, all named arguments; Into a scalar, the invocant; Into code, its slurpy +nameless block. All prefix sigil operators accept one positional argument, evaluated in scalar context as a rvalue. They can interpolate in strings if called with
[svn:perl6-synopsis] r8532 - doc/trunk/design/syn
Author: autrijus Date: Sat Apr 1 20:10:15 2006 New Revision: 8532 Modified: doc/trunk/design/syn/S02.pod Log: * upper/lowercase English nit fix for the last patch as suggested by TimToady Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podSat Apr 1 20:10:15 2006 @@ -401,8 +401,8 @@ %$args; # same as '$args as Hash or Hash($args) $args; # same as '$args as Code or Code($args) -When cast into an array, you can access all the positional arguments; Into a -hash, all named arguments; Into a scalar, the invocant; Into code, its slurpy +When cast into an array, you can access all the positional arguments; into a +hash, all named arguments; into a scalar, the invocant; into code, its slurpy nameless block. All prefix sigil operators accept one positional argument, evaluated in
[svn:perl6-synopsis] r8533 - doc/trunk/design/syn
Author: autrijus
Date: Sat Apr 1 20:46:57 2006
New Revision: 8533
Modified:
doc/trunk/design/syn/S13.pod
Log:
* S13: specify type casting in the form of
multi submethod *infix:as
which usually only cares about the class of its second invocant.
Modified: doc/trunk/design/syn/S13.pod
==
--- doc/trunk/design/syn/S13.pod(original)
+++ doc/trunk/design/syn/S13.podSat Apr 1 20:46:57 2006
@@ -116,3 +116,17 @@
this hash over a lexical scope, so you could have different policies
on magical autogeneration. The default mappings correspond to the
standard fallback mappings of Perl 5 overloading.
+
+=head1 Type Casting
+
+A class can use the C *infix:as submethod to declare that its objects
+can be casted to some other class:
+
+multi submethod *infix:as (IO) { $*OUT }
+multi submethod *infix:as (Int) { 1 }
+multi submethod *infix:as (Str) { Hello }
+
+With the above declaration, C$obj as foo is equivalent to C$obj as Str,
+because the multi dispatch cares only about the class.
+
+=cut
[svn:perl6-synopsis] r8534 - doc/trunk/design/syn
Author: autrijus
Date: Sat Apr 1 20:49:18 2006
New Revision: 8534
Modified:
doc/trunk/design/syn/S06.pod
doc/trunk/design/syn/S12.pod
Log:
* Larry (aka TimToady in the previous commit log; sorry for
spilling of IRC context) requested that multi should still
only default to multi sub to reduce lookarounds.
* Clarify that unary operators such as !$x always prefers
method dispatch first, as $x.prefix!.
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podSat Apr 1 20:49:18 2006
@@ -62,15 +62,7 @@
proto method bar {...}
multi method bar {...}
-If the routine keyword is omitted, it defaults to Cmethod inside a
-class or role, and Csub inside a module or package.
-
-class C {
-multi foo {...} # multi method foo
-}
-module M {
-multi bar {...} # multi sub bar
-}
+If the routine keyword is omitted, it defaults to Csub.
=head2 Named subroutines
@@ -467,7 +459,7 @@
If the parameter list for a Cmulti contains no colon to delimit
the list of invocant parameters, then all positional parameters are
considered invocants. If it's a Cmulti method and Cmulti submethod,
-an additional implicit unamed Cself invocant is prepended to the
+an additional implicit unnamed Cself invocant is prepended to the
signature list.
For the purpose of matching positional arguments against invocant parameters,
Modified: doc/trunk/design/syn/S12.pod
==
--- doc/trunk/design/syn/S12.pod(original)
+++ doc/trunk/design/syn/S12.podSat Apr 1 20:49:18 2006
@@ -651,6 +651,10 @@
close($handle,)
+This applies to prefix unary operators as well:
+
+!$obj; # same as $obj.prefix:!
+
A method call first considers methods (including multi-methods and submethods)
from the class hierarchy of C$handle, and fails over to the subroutine
dispatcher as a last resort only if no method can be found in the class
@@ -686,9 +690,7 @@
The syntax for calling back to CMyClass is C$obj!MyClass::meth().
-Outside a class or a role, the Csub keyword is optional after either
-Cmulti or Cproto. Within a class or a role, the Cmethod keyword
-is implied instead of Csub.
+The Csub keyword is optional after either Cmulti or Cproto.
A Cproto declaration must come before any matching multis, if at all.
Re: [svn:perl6-synopsis] r8532 - doc/trunk/design/syn
a == autrijus [EMAIL PROTECTED] writes: a Author: autrijus a Date: Sat Apr 1 20:10:15 2006 a New Revision: 8532 a Modified: adoc/trunk/design/syn/S02.pod a Log: a * upper/lowercase English nit fix for the last patch as suggested a by TimToady you might as well attribute the s:g/Into/into/ to dr. ruud. all timtoady did was correct dr. ruud's p5 s///g into p6's s:g///. if we are going to pick nits this small, then the tiny amount of credit is worth bestowing upon the correct contributor. :) one of these days when i have tuits of large circumference, i will do a nit pass over as much of the A/E/S as i can handle before my brain explodes. having done tech editing for perl books is good training for this. in fact it would be a good idea to have several such passes by those with editing skill before those docs are 'released'. some of the concepts are so new to so many and are bleeding edge that the wording used has to be extra clean of nits and such stuff as dangling pronouns and other common flaws of technical writing. speaking of bleeding edge? what do you call the opposite of that? spoiler space the coagulated edge. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
[svn:perl6-synopsis] r8535 - doc/trunk/design/syn
Author: autrijus
Date: Sat Apr 1 21:18:08 2006
New Revision: 8535
Modified:
doc/trunk/design/syn/S06.pod
Log:
* S06: Rationalize the free mix of named and positional args.
Positional pair arguments must _always_ be put in parentheses.
Multiple named arguments with the same name can be concatenated
into a @param now. $param gets the _last_ named argument,
similar to how hash constructor and rule bindings work.
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podSat Apr 1 21:18:08 2006
@@ -338,6 +338,8 @@
possible on those arguments that are bound to a final slurpy or
arglist variable.)
+=head2 Named arguments
+
Named arguments are recognized syntactically at the
comma level. Pairs intended as positional arguments rather than
named arguments must be isolated by extra parens:
@@ -405,36 +407,34 @@
bound to positionals only by name, not as ordinary positional CPair
objects. Leftover named arguments can be slurped into a slurpy hash.
-After the positional and named arguments, all the rest of the arguments
-are taken to be list arguments. Any pairs within the list are taken
-to be list elements rather than named arguments, and show up as CPair
-arguments even if the compiler marked them as named.
-
-It is possible that named pairs are not really a separate type; it
-would be sufficient to have a bit somewhere in the Pair that can be
-interrogated under the C.named property. The compiler is allowed to
-stop marking named pairs at the first C == , but the code that
-converts unused positional arguments to implicit slurpy list needs to
-be careful to clear the C.named property on arguments so converted.
-For instance, if you say
+Because named and positional arguments can be freely mixed, the
+programmer always needs to disambiguate pairs literals from named
+arguments with parenthesis:
+# Named argument a
push @array, 1, 2, :ab;
-the compiler cannot know that the slurpy list starts at 1, so it markes
-:ab as a named pair. But that mark needs to be cleared, or
+# Pair object (a='b')
+push @array, 1, 2, (:ab);
+
+Perl 6 allows multiple same-named arguments, and records the relative
+order of arguments with the same name. When there are more than one
+argument, the C@ sigil in the parameter list causes the arguments
+to be concatenated:
-say pop(@array);
+sub fun (Int @x) { ... }
+fun( x = 1, x = 2 ); # @x := (1, 2)
-will then think you said:
+Other sigils binds only to the Ilast argument with that name:
-say *pop(@array);
+sub fun (Int $x) { ... }
+f( x = 1, x = 2 );# $x := 2
-and treat :ab as a named argument to print, which is not what you want.
+This means a defaults must come Ibefore known named parameters,
+similar to how hash constructors work:
-In any event, the named parameters need to be kept in the list until
-bound. An implementation that pulls named parameters out of the list
-into a hash prematurely will lose the ordering of the push above,
-for instance.
+# Allow x and y in %defaults be overrided
+f( *%defaults, x = 1, y = 2 );
=head2 Invocant parameters
Re: replacement of $
On Sun, Apr 02, 2006 at 02:04:07 +0300, Larry Wall wrote: ^^^-- (actually that was IDT in the headers) Hi, I'm in Israel and Japan at the same time! Nice one though ;-) plugIf you guys would have participated in the keysigning parties.../plug -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpbTq7cX8r2g.pgp Description: PGP signature
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
demerphq wrote: On 4/1/06, Adam Kennedy [EMAIL PROTECTED] wrote: Similarly if somebody has an error in their Build.PL or Makefile.PL are you going to say that the installer doesnt work? Yes, absolutely. So you would file a bug with ExtUtils::MakeMaker or Module::Build when the pre-build script that accompanies a script has a syntax error in it? No, you'd file it against the distribution that contained the Makefile.PL or Build.PL. Just because they implement the installer using a particular library, doesn't mean you blame the library for their mistakes. Adam K
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
chromatic wrote: On Saturday 01 April 2006 03:41, demerphq wrote: So you would file a bug with ExtUtils::MakeMaker or Module::Build when the pre-build script that accompanies a script has a syntax error in it? Don't forget with every distribution that marked that distribution as a dependency. That's a far hazier situation and you know it :) It's only a bug in the dependent module if it's fixed in the parent module, and the dependent one doesn't update the dependency to point to the new version. Adam K
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
On 4/2/06, Adam Kennedy [EMAIL PROTECTED] wrote: demerphq wrote: On 4/1/06, Adam Kennedy [EMAIL PROTECTED] wrote: Similarly if somebody has an error in their Build.PL or Makefile.PL are you going to say that the installer doesnt work? Yes, absolutely. So you would file a bug with ExtUtils::MakeMaker or Module::Build when the pre-build script that accompanies a script has a syntax error in it? No, you'd file it against the distribution that contained the Makefile.PL or Build.PL. Ah so, you've changed your position somewhat then eh? I guess you dont think its a bug in the installer anymore? I mean if its a bug in the installer why would you report the matter to the distribution author? Just because they implement the installer using a particular library, doesn't mean you blame the library for their mistakes. You mean just because something fails duing installation doesnt mean its a problem with the installer? :-) Cheers, Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
On 4/2/06, demerphq [EMAIL PROTECTED] wrote: On 4/2/06, Adam Kennedy [EMAIL PROTECTED] wrote: demerphq wrote: On 4/1/06, Adam Kennedy [EMAIL PROTECTED] wrote: Similarly if somebody has an error in their Build.PL or Makefile.PL are you going to say that the installer doesnt work? Yes, absolutely. So you would file a bug with ExtUtils::MakeMaker or Module::Build when the pre-build script that accompanies a script has a syntax error in it? No, you'd file it against the distribution that contained the Makefile.PL or Build.PL. Ah so, you've changed your position somewhat then eh? I guess you dont think its a bug in the installer anymore? I mean if its a bug in the installer why would you report the matter to the distribution author? Just because they implement the installer using a particular library, doesn't mean you blame the library for their mistakes. You mean just because something fails duing installation doesnt mean its a problem with the installer? :-) Which says to me that being clear about which phase of the build process something fails _is_ actually useful. As thats how you decide who to file your bug with. :-) Yves -- perl -Mre=debug -e /just|another|perl|hacker/
