Virtual methods
In Perl 6, I don't think we need to tag methods as virtual like C++
does, since we have the handy yadda, yadda to do that for us.
However, there is a variant of C++'s virtual that I'd love to see. By
default a role cannot override the methods of a class, but if it could
override those methods specifically marked with the virtual trait, then
we could define stub methods in classes that don't have a specific
behavior until a more concrete role is mixed in.
This gives you a form of auto-loading like delegation, but with less
storage overhead (since there's no encapsulation until you need it).
Here's an example:
role X {
has Str $.string handlesucfirst;
# I'll write something like an accessor to avoid brining
# up some questions around how virtual methods interact
# with auto-accessors just yet.
method setstring(Str $string) { $.string = $string }
}
class Y {
method setstring(Y $me: Str $string)
is virtual {
$me does X;
$me.setstring($string);
}
}
my Y $var;
$var.setstring(hello, world); # overrides setstring
say $var.ucfirst; # says Hello, world
$var.setstring(bye, now); # calls existing setstring
say $var.ucfirst; # says Bye, now
You can probably tell that I'm about to suggest that this would be the
most efficient way to implement the dynamic functionality of Any, and
given the recent ponie/parrot discussions around flags, I think using
virtual methods as flags is probably the right way to go
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Default precedence level of user defined infix ops
Hi,
now that the following works in Pugs :)...
sub infix:. (Code x, Code y) { sub ($z) { x(y($z)) } }
(say . int)(10/3);# 3
use Set;
sub infix: ($item, @set) {
set(@set).includes($item);
}
foo bar baz foo; # true
23 bar baz foo; # false
...we wondered what the default precedence of those user defined infix ops
should be.
And how do I explicitly define the precedence?
--Ingo
--
Linux, the choice of a GNU | Mathematicians practice absolute freedom.
generation on a dual AMD | -- Henry Adams
Athlon!|
Re: Virtual methods
On 5/18/05, Aaron Sherman [EMAIL PROTECTED] wrote:
In Perl 6, I don't think we need to tag methods as virtual like C++
does, since we have the handy yadda, yadda to do that for us.
However, there is a variant of C++'s virtual that I'd love to see. By
default a role cannot override the methods of a class, but if it could
override those methods specifically marked with the virtual trait, then
we could define stub methods in classes that don't have a specific
behavior until a more concrete role is mixed in.
This gives you a form of auto-loading like delegation, but with less
storage overhead (since there's no encapsulation until you need it).
Here's an example:
role X {
has Str $.string handlesucfirst;
# I'll write something like an accessor to avoid brining
# up some questions around how virtual methods interact
# with auto-accessors just yet.
method setstring(Str $string) { $.string = $string }
}
class Y {
method setstring(Y $me: Str $string)
is virtual {
$me does X;
Except that mixins like this always treat things as virtual.
Whenever you mixin a role at runtime, Perl creates an empty, anonymous
subclass of the current class and mixes the role in that class. Since
roles beat superclasses, you'll always override your own methods.
Luke
Re: Default precedence level of user defined infix ops
On 5/18/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote:
(B Hi,
(B
(B now that the following works in Pugs :)...
(B
(B sub infix:. (Code x, Code y) { sub ($z) { x(y($z)) } }
(B (say . int)(10/3);# 3
(B
(B use Set;
(B sub infix:$B":(B ($item, @set) {
(B set(@set).includes($item);
(B }
(B "foo" $B":(B bar baz foo; # true
(B 23$B":(B bar baz foo; # false
(B
(B ...we wondered what the default precedence of those user defined infix ops
(B should be.
(B
(BIn the absence of a trait specifying otherwise, the precedence
(Bdefaults to the same as infix:+.
(B
(B And how do I explicitly define the precedence?
(B
(BUsing the `tighter`, `looser`, and `equiv` traits. You specify
(Bprecedence in terms of the precedence of other existing ops.
(B
(Bsub infix:.(f, g) is looser(infix:+) {...}
(B
(BLuke
Re: Virtual methods
On Wed, 2005-05-18 at 10:51, Luke Palmer wrote:
Except that mixins like this always treat things as virtual.
Whenever you mixin a role at runtime, Perl creates an empty, anonymous
subclass of the current class and mixes the role in that class. Since
roles beat superclasses, you'll always override your own methods.
Ok, good point (I've even pointed that out to others before, and I
missed it)...
I know that's the way it works, but now it's really bothering me.
There are many gotchas that fall out of that. For example, you might
have a special role that overrides .print to handle structured data, so
your code says:
my Foo $obj;
given $obj {
when StructuredPrintRole {
# Someone's already taken care of it, possibly
# adding a more specialized role, so leave it
# alone.
}
default {
# Add in a boring default handler
$obj does StructuredPrintRole
}
}
$obj.print($structured_data);
Woefully, you lose is Foo happens to be DECLARED with
StructuredPrintRole, and it overrode print. But, if it just inherited a
print(), then it works. In other words, this code will mysteriously fail
the second someone innocently adds a print method to Foo!
Action at a distance... my head hurts.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: The Void type
HaloO Autrijus,
you wrote:
On Fri, May 13, 2005 at 07:13:53PM +0200, TSa (Thomas Sandlaß) wrote:
Larry Wall wrote:
: Void context still exists and is not a form of singular or plural
: context. Perhaps this should be called nullar context, although void
: context works equally well for me and is not confusing because we have
: no Void type.
Nice, without Void we don't need the double headed
pseudo type lattice needed if we were to distinguish
subs that return no usefull---that is Any---value
from the ones that return no value at all.
Hrm. So if I have a sub that does nothing:
sub Foo { }
I don't know what the empty body does. But it might just return
an undef value.
Is it illegal to say this?
sub Foo returns Void { }
Well, $Larry said that there's no Void type. Thus it's
illegal unless of course some non-standard class bears
that name which would be a bit odd.
What about:
sub Foo returns :() { }
Ups, looks quite void to me. So, this might prevent e.g.
$x = Foo();
by giving a static type error. OTOH, @Larry might argue
that it's one way to write :(Any).
Or do I really need to convert it to this?
sub Foo returns Any { }
The only reason to distinguish the topmost type from Void
is that it can't be used as a value e.g. in an assignment.
OTOH such a Code subtype should be easily subtypable, and the
return type is covariant like the invocants, but the
non-invocants are contra-variant.
So, assuming Bit : Int : Num : Any, and : beeing the
subtype relation, and using the -- for function types,
this means e.g.
:( Bit,Int : Int,Num -- Int ) : :( Int,Int : Bit,Int -- Num )
In words:
1) :(Bit,Int) is more specific than :(Int,Int) for MMD
2) :(Int,Num) is more general than :(Bit,Int) for type safety on call
3) :(Int) can go were a :(Num) is expected as return type
Subtyping :(: Any -- ) 'sub with param type Any returning void'
wouldn't work if Void is the bottommost type or outside the
type system.
Actually I still wonder if the type system will work as indicated
above at all. P6l might find that too BD-ish.
--
TSa (Thomas Sandlaß)
Re: Closures and CALLER
Aaron Sherman wrote: Ok, so log and log10: multi sub Math::Basic::log (: Num ?$x = $CALLER::_, Num +$base); log10 := log.assuming:base(10); Sorry, I don't want to interfere but two nit-pickings from me: 1) It's log10:() and log:(: Num ?$, Num +$) these days, isn't it? And I'm unsure about the meaning of the first. And shouldn't you use the ::= operator? 2) More important: isn't the multi without invocants useless or even outright wrong? Or shall it indicate an undispatched, compile-time, declaration-based, overloaded function ala C++? Does such a thing exist in Perl6? Regards, -- TSa (Thomas Sandlaß)
Re: ^method ?
HaloO Juerd, you wrote: (This illustrates my feeling about @foo[] being the same as @foo. It feels inconsistent with foo() not being foo.) I have the same feeling. But I would like @foo[] to mean something else than plain @foo which should be---hmm, how shall I put that---a underefenced reference to whatever hides behind the ref|variable|name. The [] then does the deref like () derefs foo. Regards, -- TSa (Thomas Sandlaß)
Re: (1,(2,3),4)[2]
Juerd wrote: my @b = [1,2,[3,4]]; is([EMAIL PROTECTED], 1, 'Array length, nested [], outer []s'); Isn't that a bit inconvenient? To get e.g. 2 out of @b one has to write @b[0][1] while for $b a $b[1] suffices. And @x = @b maintains this superficial level of indirection? Does @x = @b[] remove one level? How does that compare to @x[] = @b? Thus my @b = (1,2,[3,4]); is equivalent to my $b = [1,2,[3,4]]; which in turn is equivalent to my $b = (1,2,[3,4]); and $b = @b blows away one level of indirection? Or is it then $b[0][1] == 2 as well? In the end the LHS is needed to calculate +[1,2,[3,4]] == 1|3? The same applies to testcases 7 and 8. All sane! :) Am I insane? -- TSa (Thomas Sandlaß)
Re: Multiple colons
Autrijus Tang wrote: I think the former is simpler (always use coercion), but the latter makes it possible to define various other things that, although not isomorphic with builtin numbers, can still use arithmetic operators. I haven't understood what Larry meant with hard constraint but I would opt for ([3]). In general the builtin operators should be grouped into roles which are in turn composed into classes like Num which implement them. -- TSa (Thomas Sandlaß)
Re: Closures and CALLER
On Wed, 2005-05-18 at 14:57, TSa (Thomas Sandlaß) wrote: Aaron Sherman wrote: Ok, so log and log10: multi sub Math::Basic::log (: Num ?$x = $CALLER::_, Num +$base); log10 := log.assuming:base(10); Sorry, I don't want to interfere but two nit-pickings from me: 1) It's log10:() and log:(: Num ?$, Num +$) these days, isn't it? And I'm unsure about the meaning of the first. And shouldn't you use the ::= operator? Yes on part 2, but on part 1... not sure. Anyone? 2) More important: isn't the multi without invocants useless or even outright wrong? Or shall it indicate an undispatched, compile-time, declaration-based, overloaded function ala C++? Does such a thing exist in Perl6? I don't know the MMD system well enough to be sure (I became aware of how multi subs work two days ago). Certainly S06 doesn't imply that this is valid. I'll have to re-read the relevant bits of A12, unless a certain former maintainer wants to speak up :) -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: ^method ? (Is $_ still aliasing $?SELF?)
Damian Conway wrote:
Now, personally, I would like to see a short-cut for *both* types of
method call,...
Looks like this syntax is now .method and ./method plus the private
counterpart .:method.
If I have .foo() as $_.foo(), then I can get unary method call on
invocant very easily, even if methods don't topicalize their invocant.
method bar ($_:) {
.foo();
}
Ahh, does this mean that the auto-aliasing is ditched?
I personally regard $_ as a bit too volatile and if it
is a rw binding it's outright dangerous to not have access
to $?SELF after some topicalizing statement! Or am I missing
something? I mean are all topicalizers properly temping $_?
How is that enforced in non-standard code?
BTW, is $_ more a global variable with lexical overriding or an
always passed implicit argument to blocks? E.g. all methods get
an implicit *%_ or was that for submethods only?
--
TSa (Thomas Sandlaß)
Re: Default precedence level of user defined infix ops
Luke Palmer wrote:
And how do I explicitly define the precedence?
Using the `tighter`, `looser`, and `equiv` traits. You specify
precedence in terms of the precedence of other existing ops.
sub infix:.(f, g) is looser(infix:+) {...}
This is interesting. So, infix: is similar to Haskell's
() circumfix operator, like ((+) 1 2) (1 + 2).
Which method does infix:+ refer to, if you have;
multi sub infix:+(Num $i, Num $j) { $i.add($j) }
multi sub infix:+(Set $i, Set $j) { $i.union($j) }
?
Are these automatically locked to the same level, in fact, does it
make sense for any 'operator' (ie, the sub's short name) to exist
in multiple precedence levels at once?
Or is it simply a major ParseF*** to have to determine precedence
/after/ determining types of operands?
Sam.
Re: Default precedence level of user defined infix ops
Luke Palmer wrote: In the absence of a trait specifying otherwise, the precedence defaults to the same as infix:+. Heh. It'd be much safer to *require* a precedence specification on any new operator. If they're changing the parser, they ought to have the decency to be explicit about precisely where they're changing it. On the other hand, if we do end up with a default (still a Bad Idea, IMHO), it probably should be C is looser(infix:+) , so that people don't have to rewire their understanding of the standard precedence sets every time someone who's defining an operator is too lazy to think about precedence or to type two dozen extra characters. Damian
Re: (1,(2,3),4)[2]
TSa (Thomas Sandlaß) skribis 2005-05-18 21:54 (+0200): Juerd wrote: my @b = [1,2,[3,4]]; is([EMAIL PROTECTED], 1, 'Array length, nested [], outer []s'); Isn't that a bit inconvenient? To get e.g. 2 out of @b one has to write @b[0][1] while for $b a $b[1] suffices. http://learn.perl.org/library/beginning_perl/ Parens and square brackets are very different things. The above is more commonly written as my @b = ([1,2,[3,4]); Having arrayrefs flatten in list context, or having [] to be able mean something other than constructing an arrayref, is a change that requires the very fundaments of Perl to change very heavily, beginning by eliminating lists entirely, and using only arrays. I believe I said it before, but I'll do it again: Perl is not Python. Just that the two languages are both powerful, and both begin with a P, and in some respects even syntactically look like eachother (hey, that's what we get for loving ASCII), doesn't mean any theory applicable to one automatically makes sense for the other. And @x = @b maintains this superficial level of indirection? ARRAY = LIST is the syntax for assigning to an array. Note that the RHS is list context, not Array context. Does @x = @b[] remove one level? How does that compare No. As far as I know, @b[] and @b are the synonymous. my @b = (1,2,[3,4]); is equivalent to my $b = [1,2,[3,4]]; No, that's not equivalent. $b contains a reference to an array, while @b itself is an array. Hoping the box diagram worked the last time, I'll try again: +-- @b +-- $b(this array has no name; | | it is anonymous) V V +--+ +++--+ | elements | | reference | elements | +--+ |++--+ ARRAY SCALARARRAY which in turn is equivalent to my $b = (1,2,[3,4]); That is only because the comma operator is in scalar context. The parens here merely GROUP, for precedence. my $b = eval 1,2,[3,4] would be exactly the same. Just to show you the parens are NOT constructors of the list. $b = @b No, that assigns a *reference to $b* to @b, without any copying of elements. Am I insane? No, you just STILL can't cope with Perl's notion of names, containers and values, and you don't realise that () and [] are not related, more specifically: that () has absolutely nothing to do with arrays or lists. These are mistakes many Perl 5 beginners make, especially those coming from Python. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
reduce metaoperator on an empty list
All~ What does the reduce metaoperator do with an empty list? my @a; [+] @a; # 0? exception? [*] @a; # 1? exception? [] @a; # false? [||] @a; # false? [] @a; # true? Also if it magically supplies some correct like the above, how does it know what that value is? Thanks, Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Re: reduce metaoperator on an empty list
Matt Fowles wrote: All~ What does the reduce metaoperator do with an empty list? my @a; [+] @a; # 0? exception? [*] @a; # 1? exception? [] @a; # false? [||] @a; # false? [] @a; # true? Also if it magically supplies some correct like the above, how does it know what that value is? My general thoughts has been that: [op] @list behaves something like: eval join(op, @list) so feeding it an empty list would return undef, regardless of op. Similarly, if @list is just one element, it returns that element. -- Rod Adams
Re: reduce metaoperator on an empty list
Matt Fowles wrote: All~ What does the reduce metaoperator do with an empty list? my @a; [+] @a; # 0? exception? [*] @a; # 1? exception? [] @a; # false? [||] @a; # false? [] @a; # true? Also if it magically supplies some correct like the above, how does it know what that value is? The usual definition of reduce in most languages that support it, is that reduce over the empty list produces the Identity value for the operation. So for the above ops the answers are: 0, 1, depends, false, true. For chained ops like '' it depends on whether xyz return x or z on being true. if x then -inf else if z then +inf (don't ask if it returns y). Note that some ops (like '%') don't have an identity value and therefore [%] over the empty list is the equivalent to a divide by 0 and probably throws an exception or at least returns undef. Now this is a problem for user defined operations, so reduce of a user defined op over the empty list is either an exception, return undef or we need a trait that can be specified for an infix op that specifies what to return for reduce over the empty list. The compiler shouldn't bother to check if what you specified is really the Identity value for op, but I'd consider it a bug if it isn't. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: reduce metaoperator on an empty list
On 5/19/05, Matt Fowles [EMAIL PROTECTED] wrote: All~ What does the reduce metaoperator do with an empty list? /me puts on his lambda hat In Haskell, there is a distinction between foldl and foldl1 (similar remarks apply to foldr/foldr1[1]): The former (foldl) requires you to give an explicit 'left unit'[2], which is implicitly added to the left of the list being reduced. This means that folding an empty list will just give you the unit. i.e. foldl (+) 0 [a,b,c] = ((0+a)+b)+c foldl (+) 0 [] = 0 The latter (foldl1) doesn't use a unit value, but this means that you can't fold empty lists. i.e. foldl1 (+) [a,b,c] = (a+b)+c foldl1 (+) [] = ***error*** /me puts camel hat back on This suggests that []-reducing an empty list should probably (IMO) do one of the following: * Fail, since it's an ill-defined operation without an explicit unit * Try to find a suitable unit value (see below), and fail if it doesn't find one You /could/ try to do something 'sensible' and return 0 or undef, but this seems likely to result in more confusion. Another alternative is to give the user the option of specifying such a unit when using the reduction meta-operator, but this seems to work against the whole point of [+] (which is brevity). If you want to specify your own unit, use 'reduce'. my @a; [+] @a; # 0? exception? [*] @a; # 1? exception? [] @a; # false? [||] @a; # false? [] @a; # true? Also if it magically supplies some correct like the above, how does it know what that value is? Perhaps the operator could have some kind of 'unit' trait? (Or perhaps 'left_unit' and 'right_unit'?) Stuart [1] Just remember that unlike foldr/foldl, which are explicitly right/left associative, [+] is 'DWIM-associative', reflecting the associativity of the underlying operator. [2] e.g. 0 is the left (and right) unit of + because 0 + x == x (and x + 0 == 0)
Re: reduce metaoperator on an empty list
To summarise what I think everyone is saying, []-reducing an empty list yields either: 1) undef (which may or may not contain an exception), or 2) some unit/identity value that is a trait of the operator, depending on whether or not people think (2) is actually a good idea. The usual none(@Larry) disclaimer applies, of course... Stuart
Re: reduce metaoperator on an empty list
On 5/18/05, Stuart Cook [EMAIL PROTECTED] wrote: To summarise what I think everyone is saying, []-reducing an empty list yields either: 1) undef (which may or may not contain an exception), or 2) some unit/identity value that is a trait of the operator, depending on whether or not people think (2) is actually a good idea. I would think that the Principle of Least Surprise points to (1), given that the standard explanation of the [EMAIL PROTECTED] is eval join( '+', @x ) ... Rob
Re: reduce metaoperator on an empty list
Rob Kinyon wrote: On 5/18/05, Stuart Cook [EMAIL PROTECTED] wrote: To summarise what I think everyone is saying, []-reducing an empty list yields either: 1) undef (which may or may not contain an exception), or 2) some unit/identity value that is a trait of the operator, depending on whether or not people think (2) is actually a good idea. I would think that the Principle of Least Surprise points to (1), given that the standard explanation of the [EMAIL PROTECTED] is eval join( '+', @x ) ... $rod == none(@Larry), and therefore just because I think it should be that way, doesn't mean it is that way. But the eval join way of looking at it does seem to be consistent with what I've seen discussed previously, and would provide a useful way to remember the effects of edge cases. -- Rod Adams
Perl 6 Summary for 2005-05-03 through 2005-05-17
Perl 6 Summary for 2005-05-03 through 2005-05-17 All~ Welcome ot another fortnight's summary. Wouldn't it just figure that I can't think of anything sufficiently non-sequiterish to amuse myself. Perhaps I need a running gag like Leon Brocard or chromatic's cummingseque capitalization Maybe I should start one and not tell you. That could be fun. Sorry for spelling errors, gmails spell checker is busted for the moment. Perl 6 Compiler pugs commit emails If you have ever been foolish enough to want to get an email for every commit in Pugs, Sam Vilain created a way to help you sip from the firehose. Have fun. http://xrl.us/f5q7 given when nested Luke Palmer had a question about how nested when statements in a given block should act. His intuition disagreed with Pugs, but most others supported Pugs. http://xrl.us/f5q8 I don't need to walk around in circles Autrijus has made Pugs into a registered compiler for Parrot. Since Pugs already allowed you to embed parrot code (well pir anyway) directly into perl 6, this allows you to embed the perl 6 in your pir in your perl 6. Now the possibilities are endless, at least until you blow your mental stack. Those of you with tail call optimization in your mental stack may simply go into an infinite loop if you prefer. http://xrl.us/f5q9 xor on lists Trewth Seeker expressed his opinion about the proper definition of xor quite strongly. Unfortunately, his opinion is at odds with established mathematics, as Mark Biggar pointed out to him. http://xrl.us/f5ra PGE features update Patrick provided an update on the state of the Perl Grammar Engine. It has many nifty new features. http://xrl.us/f5rb Pugs on Cygwin Rob Kinyon and Gaal Yahas worked to improve Pugs support for Cygwin. Unfortunately the thread winds down with an unanswered question, fortunately Stevan clued me in on IRC that things are working just yet. http://xrl.us/f5rc Pugs gets some objects and some rules Autrijus announced that Pugs now has basic support for Objects and Rules. Sometimes he scares me. Usually he just makes me really want to learn haskell though. http://xrl.us/f5rd regression test Miroslav Silovic provided a regression test for hyper ops. Some people just don't appreciate the fun of regressing. http://xrl.us/f5re basic test for classes Stevan Little provided a patch for a simple object test. Autrijus applied it. Odd, cause I am pretty sure that Stevan has the commit bit... http://xrl.us/f5rf torturing PGE Juerd provided a link to a big rule that could segfault PGE. Kind reminds me of a homework assignment I had to create a regular expression which matched all strings of numbers that did not contain any repeated digits. Easy in perl, but hard in math. I think the resultant regex was somewhere around 17 MB. http://xrl.us/f5rg Pugs 6.2.3 with Live CD Autrijus released Pugs 6.2.3 which contains 10% more awesome then Pugs 6.2.2. You should check it out on the live CD that Ingo Blechschmidt released. http://xrl.us/f5rh -- release anouncement http://xrl.us/f5ri -- live CD PXPerl meets Pugs Grégoire Péan announced that he has added Pugs binaries to his windows distribution of Perl. Pretty cool. Autrijus innocently asked him to take on the slightly larger task of producing binaries of Parrot too, so that Pugs could be at its more powerful. http://xrl.us/f5rj Parrot Wow did you see how I mentioned Parrot before going into. That was like an awesome transition. My high school english teachers would be so proud... character classes Patrick wants character class opcodes of the form find first and find first not. Leo pointed him to some hysterical raisins who might help. http://xrl.us/f5rk PGE on MinGW François Perrad fixed a problem with building PGE on MinGW. Patrick applied the patch. http://xrl.us/f5rm PIO_fdopen return value Luke Palmer both intoduced me to the wonderfully cute phrase untodid and provided a patch making PIO_fdopen return NULL when give bad flags. Leo applied the patch, but Melvin Smith warned that this might be a bad idea. Silence after that. http://xrl.us/f5rn embedding initialization Jeff Horwitz was having trouble embedding PIR into C. Leo provided some pointers. Jeff was happy. http://xrl.us/f5ro Test::Builder updates Previously, Michael G Schwern announced an update to Test::Builder. chromatic asked if it was worth the upgrade. Michael replied probably, but I don't think anyone has acted on it. http://xrl.us/f5rp miniparrot Robert Spier created a miniparrot at Bernhard Schmalhofer request. This miniparrot does not replace our make system, but it does make our
Re: reduce metaoperator on an empty list
Stuart Cook wrote: To summarise what I think everyone is saying, []-reducing an empty list yields either: 1) undef (which may or may not contain an exception), or 2) some unit/identity value that is a trait of the operator, depending on whether or not people think (2) is actually a good idea. The usual none(@Larry) disclaimer applies, of course... Well the only case where it probably really matters is [+] where you really want the result to be 0. Of course +undef == 0, so maybe returning undef might be okay. I'm thinking about the case: [+] grep some_condition, @a where you really want the total to be 0, even if the result of the grep is empty. A case can also be made for (assuming @a = ();) that [EMAIL PROTECTED] == 1 [EMAIL PROTECTED] eq '' (also covered by ~undef) [?[EMAIL PROTECTED] ~~ true [?|[EMAIL PROTECTED] ~~ false (also covered by ?undef) [EMAIL PROTECTED] ~~ false (also covered by ?undef) [+[EMAIL PROTECTED] == MAXINT (whatever that is) [+|[EMAIL PROTECTED] == 0 (also covered by +undef) [EMAIL PROTECTED] == 0 (also covered by +undef) chained ops are wierd [[EMAIL PROTECTED] ~~ false [[EMAIL PROTECTED] ~~ false [[EMAIL PROTECTED] ~~ true [[EMAIL PROTECTED] ~~ true Other ops have theoritical values that I don't know if we can handle: [~[EMAIL PROTECTED] should be an infinitely long bitstring of 1's [~|[EMAIL PROTECTED] should be an infinitely long bitstring of 0's Again, given that that the really important case [+] is covered by +undef == 0, maybe just always returning undef is good enough. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: reduce metaoperator on an empty list
Another alternative is to give the user the option of specifying such a unit when using the reduction meta-operator, but this seems to work against the whole point of [+] (which is brevity). If you want to specify your own unit, use 'reduce'. Can't the appropriate identity just be prepended? my @a; [+] @a; # 0? exception? [+] (0, @a); [*] @a; # 1? exception? [*] (1, @a); [] @a; # false? [] (-Inf, @a); # ??? Brad -- People with intelligence will use it to fashion both true and false and will try to push through whatever they want with their clever reasoning. This is injury from intelligence. Nothing you do will have effect if you do not use truth. -- Hagakure
