Damian Conway wrote:
Let's assume that op is overloaded for two completely unrelated types
A and B, which are both defining their respective identity elements
but !(A.identval =:= B.identval). How should the op multi method object
pick the correct one *without* looking at $value's type?
Your
On Thursday 09 June 2005 12:21, John Macdonald wrote:
On Thu, Jun 09, 2005 at 06:41:55PM +0200, TSa (Thomas Sandla
wrote:
Edward Cherlin wrote:
That means that we have to straighten out the functions
that can return either a Boolean or an item of the
argument type. Comparison functions
On Tuesday 07 June 2005 08:08, Larry Wall wrote:
Okay, I've made up my mind. The err option is not tenable
because it can cloak real exceptions, and having multiple
versions of reduce is simply multiplying entities without
adding much power. So let's allow an optional identvalue
trait on
On Tuesday 07 June 2005 22:35, Sam Vilain wrote:
Let's look at the type of one of the many `reduce' variants in
Haskell;
foldr1 :: (a - a - a) - [a] - a
This is the Perl6ish;
sub reduce( ::Code{( ::(someType), ::(someType) ) returns
::(someType)} $func, Array of ::(someType) )
Edward Cherlin wrote:
That means that we have to straighten out the functions that can
return either a Boolean or an item of the argument type.
Comparison functions = = = != should return only Booleans,
I'm not sure but Perl6 could do better or at least trickier ;)
Let's assume that = =
HaloO Larry,
you wrote:
: Might I add that it should read
:
: $var = (op.does(identval) ??
: op.identval($value) :: undef) op $value;
:
: The rational is, that op is subject to MMD, so the .identval method
: should be dispatched as well. Actually op.identity($value)
On Thu, Jun 09, 2005 at 06:41:55PM +0200, TSa (Thomas Sandlaß) wrote:
Edward Cherlin wrote:
That means that we have to straighten out the functions that can
return either a Boolean or an item of the argument type.
Comparison functions = = = != should return only Booleans,
I'm not sure
TSa (Thomas Sandlaß) wrote:
Let's assume that op is overloaded for two completely unrelated types
A and B, which are both defining their respective identity elements
but !(A.identval =:= B.identval). How should the op multi method object
pick the correct one *without* looking at $value's type?
Edward Cherlin wrote:
You haven't convinced me, but rather than flog a dead horse,
I'll just suggest that we both reserve the right to say I
told you so when there are several years' worth of Perl 6
code out there, and we see how common our respective examples
are.
No need to wait. There is a
TSa (Thomas Sandla) wrote:
I'm not sure but Perl6 could do better or at least trickier ;)
Let's assume that = = when chained return an accumulated
boolean and the least or greatest value where the condition was
true. E.g.
0 2 3 returns 0 but true
1 2 1 returns 1 but false
4 5
Larry wrote:
Okay, I've made up my mind. The err option is not tenable because
it can cloak real exceptions, and having multiple versions of reduce is
simply multiplying entities without adding much power. So let's allow
an optional identvalue trait on operators. If it's there, reduce
can
Damian Conway wrote:
So, to clarify again, if $var is undefined, then the assignment:
$var op= $value;
is equivalent to:
$var = (op.does(identval) ?? op.identval() :: undef) op $value;
Correct?
Might I add that it should read
$var = (op.does(identval) ??
On Wed, Jun 08, 2005 at 11:40:49AM +0200, TSa (Thomas Sandlaß) wrote:
: Damian Conway wrote:
: So, to clarify again, if $var is undefined, then the assignment:
:
: $var op= $value;
:
: is equivalent to:
:
: $var = (op.does(identval) ?? op.identval() :: undef) op $value;
:
: Correct?
:
On Tue, Jun 07, 2005 at 10:52:55PM +, Luke Palmer wrote:
: Okay, I was referring more to the implementation. How do we tell apart:
:
: 3 4 = 5 == 5
:
: From
:
: 3 lt 4 = 5 != 5
:
: ?
As long as the actual arguments aren't allowed to be lazy/thunky/iteratey,
they can just be
On Wednesday 01 June 2005 17:18, Deborah Pickett wrote:
You haven't convinced me, but rather than flog a dead horse,
I'll just suggest that we both reserve the right to say I
told you so when there are several years' worth of Perl 6
code out there, and we see how common our respective examples
Okay, I've made up my mind. The err option is not tenable because
it can cloak real exceptions, and having multiple versions of reduce is
simply multiplying entities without adding much power. So let's allow
an optional identvalue trait on operators. If it's there, reduce
can use it. If it's
On 6/7/05, Larry Wall [EMAIL PROTECTED] wrote:
Okay, I've made up my mind. The err option is not tenable because
it can cloak real exceptions, and having multiple versions of reduce is
simply multiplying entities without adding much power. So let's allow
an optional identvalue trait on
On Tue, Jun 07, 2005 at 09:41:49PM +, Luke Palmer wrote:
: and still don't make sense as reduce operators.
Yeah, I keep confusing them with min and max.
: That reminds me, how are , , etc. defined anyway? How can we tell
: them to be list-associative with each other?
Because they're all
On 6/7/05, Larry Wall [EMAIL PROTECTED] wrote:
On Tue, Jun 07, 2005 at 09:41:49PM +, Luke Palmer wrote:
: and still don't make sense as reduce operators.
Yeah, I keep confusing them with min and max.
: That reminds me, how are , , etc. defined anyway? How can we tell
: them to be
Luke Palmer wrote:
and still don't make sense as reduce operators. Observe the table:
# of args | Return (type)
0 | -Inf
1 | Num (the argument)
2 | bool
... | bool
Let's look at the type of one of the many `reduce'
On Tuesday 07 June 2005 23:41, Luke Palmer wrote:
On 6/7/05, Larry Wall [EMAIL PROTECTED] wrote:
Okay, I've made up my mind. The err option is not tenable because
it can cloak real exceptions, and having multiple versions of reduce is
simply multiplying entities without adding much power.
Damian Conway wrote:
Deborah Pickett wrote:
You are going to see empty lists more often than you think in
expressions like
$product = [*] @array;
and having to write that as
$product = [*] 1, @array;
just to protect against a common case doesn't exactly flaunt Perl's
DWIMmery to me. I
Damian Conway wrote:
What you want is:
$product = ([*] @values err 0);
Or:
$factorial = ([*] 1..$n err 1);
The err operator bind only to the point on the instruction it is
attached to, ie it's not a shortcut for eval(), right?
I'm just seeing some edge cases here for custom defined
On Wed, 1 Jun 2005 13.19, Joe Gottman wrote:
Juerd asked:
2+ args: interpolate specified operator
1 arg: return that arg
0 args: fail (i.e. thrown or unthrown exception depending on use
fatal)
Following this logic, does join( , @foo) with [EMAIL PROTECTED] being 0
On 6/1/05, Deborah Pickett [EMAIL PROTECTED] wrote:
I'm still in the camp of those wanting each operator to know its own identity
value (perhaps in terms of a trait). The identity of multiplication (say) is
always 1, after all, and it doesn't change depending on when you do
multiplication in
Deborah Pickett wrote:
You are going to see empty lists more often than you think in expressions like
$product = [*] @array;
and having to write that as
$product = [*] 1, @array;
just to protect against a common case doesn't exactly flaunt Perl's DWIMmery
to me. I *have* to write 1 there,
On Wed, 1 Jun 2005, Luke Palmer wrote:
$ordered = [] @array;
If @array is empty, is $ordered supposed to be true or false? It
certainly shouldn't be anything but those two, because is a boolean
operator.
I read that (mathematically) as for all i, for all j such that j-i=1,
a_ia_j,
On 6/1/05, Michele Dondi [EMAIL PROTECTED] wrote:
On Wed, 1 Jun 2005, Luke Palmer wrote:
$ordered = [] @array;
If @array is empty, is $ordered supposed to be true or false? It
certainly shouldn't be anything but those two, because is a boolean
operator.
I read that
Hi,
You have to either supply an initial value or refactor your logic not
to allow an empty @array (as in the first case). If you want it some
other way, there are far too many special cases we have to work with,
some of which are just mathematically impossible.
I think `fail`ing is the best
On Wed, 1 Jun 2005, Luke Palmer wrote:
I read that (mathematically) as for all i, for all j such that j-i=1,
a_ia_j, which is certainly satisfied by an empty list.
Yep, it sure is. Now tell Perl to read it that way for any operator.
Should _I_?!? ;-)
I wonder what a logic-oriented
Luke Palmer wrote:
For something like:
$ordered = [] @array;
If @array is empty, is $ordered supposed to be true or false? It
certainly shouldn't be anything but those two, because is a boolean
operator.
I have no problem with 3-state logic systems (true, false, undef) if
this is
$ordered = [] @array;
This is asking Is @array ordered? In the case of a 0-element or
1-element array, the answer is It is not disordered, which means
$ordered is true.
$ordered = ! [!] @array;
Rob
On Wed, 1 Jun 2005 19.37, Damian Conway wrote:
Deborah Pickett wrote:
Someone please convince me otherwise.
So what you want is not an identity value as default (which isn't even
possible for many operators, as Luke pointed out), but a predictable
failure value as default, so you can
On Mon, May 23, 2005 at 08:54:19PM +, [EMAIL PROTECTED] wrote:
:
: There are actuall two usefull definition for %. The first which Ada calls
'mod' always returns a value 0=XN and yes it has no working value that is an
identity. The other which Ada calls 'rem' defined as follows:
:
:
All this discussion of identity defaults for reductions has been very
interesting and enlightening.
But it seems to me that the simplest correct behaviour for reductions is:
2+ args: interpolate specified operator
1 arg: return that arg
0 args: fail (i.e. thrown or unthrown
Damian Conway wrote:
0 args: fail (i.e. thrown or unthrown exception depending on use
fatal)
...
$sum = ([+] @values err 0);
$prod = ([*] @values err 1);
$prob = ([*] @probs err 0);
Just wanted to check, if I've said use fatal: will that err 0 DWIM,
or will the
Dave Whipp wrote:
Damian Conway wrote:
0 args: fail (i.e. thrown or unthrown exception depending on use
fatal)
...
$sum = ([+] @values err 0);
$prod = ([*] @values err 1);
$prob = ([*] @probs err 0);
Just wanted to check, if I've said use fatal: will that err 0
Damian Conway wrote:
And what you'd need to write would be:
$sum = (try{ [+] @values } err 0);
The err ... idiom seems too useful to have it break in this case.
Afterall, the purpose of err 0 is to tell the stupid computer that I
know what to do with the empty-array scenario.
Feels
Dave Whipp wrote:
Damian Conway wrote:
And what you'd need to write would be:
$sum = (try{ [+] @values } err 0);
The err ... idiom seems too useful to have it break in this case.
Afterall, the purpose of err 0 is to tell the stupid computer that I
know what to do with the
Damian Conway skribis 2005-06-01 10:44 (+1000):
2+ args: interpolate specified operator
1 arg: return that arg
0 args: fail (i.e. thrown or unthrown exception depending on use fatal)
Following this logic, does join( , @foo) with [EMAIL PROTECTED] being 0 fail
too?
I dislike
Juerd asked:
2+ args: interpolate specified operator
1 arg: return that arg
0 args: fail (i.e. thrown or unthrown exception depending on use fatal)
Following this logic, does join( , @foo) with [EMAIL PROTECTED] being 0 fail too?
No. It returns empty string. You could think of
-Original Message-
From: Damian Conway [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 31, 2005 11:14 PM
To: perl6-language@perl.org
Subject: Re: reduce metaoperator on an empty list
Juerd asked:
2+ args: interpolate specified operator
1 arg: return that arg
0
Joe Gottman pointed out:
No. It returns empty string. You could think of Cjoin as being
implemented:
sub join (Str $sep, [EMAIL PROTECTED]) { reduce { $^a ~ $sep ~ $^b } ,
@list }
If this were the case, then
join '~', 'a', 'b', 'c'
would equal '~a~b~c' instead of
On Fri, May 20, 2005 at 10:14:26PM +, [EMAIL PROTECTED] wrote:
Mark A. Biggar wrote:
Well the identity of % is +inf (also right side only).
I read $n % any( $n..Inf ) == $n. The point is there's no
unique right identity and thus (Num,%) disqualifies for a
Monoid. BTW, the above
HaloO Mark,
please don't regard the following as obtrusive.
you wrote:
If as usual the definition of a right identity value e is that a op e = a for
all a,
then only +inf works. Besdies you example should have been;
Or actually $n % any( abs($n)+1 .. Inf ) to really exclude 0
from the
There are actuall two usefull definition for %. The first which Ada calls
'mod' always returns a value 0=XN and yes it has no working value that is an
identity. The other which Ada calls 'rem' defined as follows:
Signed integer division and remainder are defined by the relation:
A =
On Thursday 19 May 2005 20:42, Andrew Rodland wrote:
On Thursday 19 May 2005 10:51 pm, Sam Vilain wrote:
Edward Cherlin wrote:
Here is the last answer from Ken Iverson, who invented
reduce in the 1950s, and died recently.
file:///usr/share/j504/system/extras/help/dictionary/intro
On Friday 20 May 2005 07:18, John Macdonald wrote:
Is there a built-in operator that doesn't have a meaningful
identity value?
Certainly.
I first thought of exponentiation, but it has
an identity value of 1 - you just have to realize that since
it is a right associative operator, the
On Friday 20 May 2005 08:11, TSa (Thomas Sandla) wrote:
John Macdonald wrote:
... (and there may be additional
operator attributes that make sense there too, although none
come immediately to mind).
Well, I wonder why people neglect the fact that the
neutral/identity element is not a
Mark == Mark A Biggar [EMAIL PROTECTED] writes:
Mark The usual definition of reduce in most languages that support it, is
Mark that reduce over the empty list produces the Identity value for the
Mark operation.
In Smalltalk, the equivalent of reduce is inject:into:, so a
sum reduce looks like:
John Macdonald wrote:
... (and there may be additional
operator attributes that make sense there too, although none
come immediately to mind).
Well, I wonder why people neglect the fact that the neutral/identity
element is not a property of the operator alone?! Besides the
associativity and
John Macdonald wrote:
Is there a built-in operator that doesn't have a meaningful
identity value? I first thought of exponentiation, but it has
an identity value of 1 - you just have to realize that since
it is a right associative operator, the identity has to be
applied from the right.
Well the
Mark A. Biggar wrote:
Well the identity of % is +inf (also right side only).
I read $n % any( $n..Inf ) == $n. The point is there's no
unique right identity and thus (Num,%) disqualifies for a
Monoid. BTW, the above is a nice example where a junction
needn't be preserved :)
E.g. if XY is left
On Thursday 19 May 2005 19:51, Sam Vilain wrote:
Edward Cherlin wrote:
Here is the last answer from Ken Iverson, who invented
reduce in the 1950s, and died recently.
file:///usr/share/j504/system/extras/help/dictionary/intro28
.htm
Mark A. Biggar wrote:
Well the identity of % is +inf (also right side only).
I read $n % any( $n..Inf ) == $n. The point is there's no
unique right identity and thus (Num,%) disqualifies for a
Monoid. BTW, the above is a nice example where a junction
needn't be preserved :)
If as usual
On 5/19/05, Brad Bowman [EMAIL PROTECTED] wrote:
Can't the appropriate identity just be prepended?
my @a;
[+] @a; # 0? exception?
[+] (0, @a);
[*] @a; # 1? exception?
[*] (1, @a);
[] @a; # false?
[] (-Inf, @a); # ???
Wow, that's actually pretty elegant, and it has the
On Sat, May 07, 2005 at 010008PM -0700, Larry Wall wrote:
On the other hand, since we've distinguished hyperops on
infixes from hyperops on unaries, maybe an infix hyperop in
unary position just does the thing to itself:
@squares = * @list;
which gives us a sum-of-squares that looks
On Wed, 18 May 2005, Matt Fowles wrote:
All~
What does the reduce metaoperator do with an empty list?
Interesting. Mathematically an empty sum is zero and an empty product is
one. Maybe each operator {c,s}hould have an associated method returning
its neutral element for [] to use it on empty
On Wed, 18 May 2005, Rob Kinyon wrote:
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),
I
On Wednesday 18 May 2005 17:57, Matt Fowles wrote:
All~
What does the reduce metaoperator do with an empty list?
Here is the last answer from Ken Iverson, who invented reduce in
the 1950s, and died recently.
file:///usr/share/j504/system/extras/help/dictionary/intro28.htm
Identity Functions
Michele Dondi wrote:
On Wed, 18 May 2005, Rob Kinyon wrote:
1) undef (which may or may not contain an exception), or
2) some unit/identity value that is a trait of the operator,
I think that the unit/identity/neutral value is a trait of the
operator *and* the type of the values which are expected
On Wed, 18 May 2005, 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,
Edward Cherlin wrote:
Here is the last answer from Ken Iverson, who invented reduce in
the 1950s, and died recently.
file:///usr/share/j504/system/extras/help/dictionary/intro28.htm
[snip]
Thanks for bringing in a little history to the discussion. Those links
are all local to your system; do
Stuart Cook wrote:
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
On Thursday 19 May 2005 10:51 pm, Sam Vilain wrote:
Edward Cherlin wrote:
Here is the last answer from Ken Iverson, who invented reduce in
the 1950s, and died recently.
file:///usr/share/j504/system/extras/help/dictionary/intro28.htm
[snip]
Thanks for bringing in a little history to
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
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
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
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
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
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
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
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?
On Sat, May 14, 2005 at 10:53:38PM +0800, Autrijus Tang wrote:
: On Sat, May 14, 2005 at 10:56:29PM +1000, Damian Conway wrote:
: 8. To verify the monotonicity of a sequence:
:
: $is_monotonic = [] @numbers;
:
: Hey. Does this mean that the [] metaoperator folds with the
:
Larry Wall skribis 2005-05-14 8:29 (-0700):
: say [x];
: Is it a repeating metaoperator on an empty list, or a single-element
: array reference that contains the return value of calling x()?
Always the first. [x] doesn't have to do lookahead.
Does this mean that [x] is just an
On 5/7/05, Patrick R. Michaud [EMAIL PROTECTED] wrote:
It might not be a problem -- I'm thinking we may end up tokenizing
most or all of the meta operators, so that [+] would be considered
its own token, and then the longest matching token rule
would be sufficient to disambiguate the terms:
On Sat, May 07, 2005 at 05:11:19PM +1000, Stuart Cook wrote:
: On 5/7/05, Patrick R. Michaud [EMAIL PROTECTED] wrote:
: It might not be a problem -- I'm thinking we may end up tokenizing
: most or all of the meta operators, so that [+] would be considered
: its own token, and then the longest
On Sat, May 07, 2005 at 01:00:08PM -0700, Larry Wall wrote:
: On the other hand, since we've distinguished hyperops on infixes from
: hyperops on unaries, maybe an infix hyperop in unary position just
: does the thing to itself:
:
: @squares = »*« @list;
:
: which gives us a sum-of-squares
Luke Palmer wrote:
On 5/4/05, Larry Wall [EMAIL PROTECTED] wrote:
[] could mean monotonically increasing.
Not unless we make boolean operators magic. There are arguments for
doing that, but I don't really want to think about how that would be
done at the moment. Reduce over a straight-up (or
On Wed, May 04, 2005 at 11:58:59PM -0600, Luke Palmer wrote:
: On 5/4/05, Larry Wall [EMAIL PROTECTED] wrote:
: [] could mean monotonically increasing.
:
: Not unless we make boolean operators magic. There are arguments for
: doing that, but I don't really want to think about how that would be
Larry Wall [EMAIL PROTECTED] wrote:
It would be nice to have an easy-to-access What's this? interface
that could be stitched into your favorite editor to identify what's
under the cursor, or at least a command like:
p6explain '[+]'
s:p5/nice to have/absolutely necessary/ unless $self ~~
On Wed, 4 May 2005, Larry Wall wrote:
It would be nice to have an easy-to-access What's this? interface
that could be stitched into your favorite editor to identify what's
under the cursor, or at least a command like:
p6explain '[+]'
That would make me extremely happy.
:$sum = [+]
On May 5, 2005, at 11:28 , John Williams wrote:
How does [+] know you mean
reduce infix:+, @array;
instead of
reduce prefix:+, @array;
which is nonsense, but the [+] is in a prefix position.
Because [] applies only to infix operators, as I understand it.
With the hyper metaoperator, the real
On Thu, 5 May 2005, David Wheeler wrote:
I can see how to ask for a binary (hence infix) operator, but how
do I ask
for a prefix or postfix operator specifically, which + and + do?
Maybe there are Operator::Prefix, etc, roles defined so you can ask
for
them?
Ask for them for what?
On Thu, 5 May 2005, John Williams wrote:
or even
@x -= @y;
Doh! That should be C $x -= $y; of course.
If I understand correctly, so far we have the following meta-operators:
[ ]
circumfix meta-operator on infix operator which produces a prefix operator
circumfix meta-operator on infix operator which produces an infix operator
=
postfix meta-operator on infix operator which produces an infix
On 5/5/05, Stuart Cook [EMAIL PROTECTED] wrote:
+-+---+-++
| Meta-op | is| operates on | to produce |
+-+---+-++
| [ ] | circumfix | infix | prefix |
On 5/6/05, Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote:
I find this table very interesting, in that it shows the fundamental
difference between reduce and the existing meta-ops.
Yep, that was basically the whole point of the table.
The existing meta-operators alter the semantics of the
Are these equivalent? (Assuming reduce isn't going away)
Larry Wall skribis 2005-05-04 5:36 (-0700):
$sum = \\+ @array;
$fact = \\* 1..$num;
$sum = reduce infix:+, @arrayd;
$fact = reduce infix:*, 1..$num;
$firsttrue = \\|| @args;
$firstdef = \\// @args;
Juerd skribis 2005-05-04 14:53 (+0200):
@foo == zip == @bar
H...
@quux
||
||
\/
@foo == zip == @bar
/\
||
||
@xyzzy
:)
Juerd
--
http://convolution.nl/maak_juerd_blij.html
This may be a naive question, but what's wrong with just having a
keyword called reduce()? Why do we need an operator for everything?
I'm worried that the list of P6 operators is going to be as long as
the list of P5 keywords, with a lot of them looking something like:
verbdirect objectindirect
On Wed, 2005-05-04 at 08:36, Larry Wall wrote:
I propose that reduce become a metaoperator that can be applied to
any binary operator and turns it syntactically into a list operator.
Sounds very cool! I like it... but...
$sum = ®+ @array;
I don't think you can do that workably. In the
On Wed, May 04, 2005 at 02:53:54PM +0200, Juerd wrote:
: Hm, if == and == are made special syntax, maybe this would be
: possible?
:
: @foo == zip == @bar
It's already the case that == binds tighter, so it should work the
same as
@foo == (zip == @bar)
or
zip == @bar == @foo
or
On Wed, May 04, 2005 at 09:00:46AM -0400, Aaron Sherman wrote:
: That said, let me try to be helpful, and not just complain:
:
: $sum = (+) @array;
:
: I've not thought through all of the implications to the parser, but I
: think this works, and it certainly ends up looking very mnemonic
Aaron Sherman skribis 2005-05-04 9:00 (-0400):
$sum = ®+ @array;
I don't think you can do that workably. In the font I use, I was
scratching my head asking how does @ work there?! Yep, I can't tell ®
and @ apart without getting REAL close to the screen.
Perhaps this just means that the
On Wed, May 04, 2005 at 08:59:04AM -0400, Rob Kinyon wrote:
: This may be a naive question, but what's wrong with just having a
: keyword called reduce()? Why do we need an operator for everything?
Because it's an operator/macro in any event, with weird unary or
listop parsing:
reduce(+)
On Wed, 4 May 2005, Larry Wall wrote:
I propose that reduce become a metaoperator that can be applied to
any binary operator and turns it syntactically into a list operator.
I second that. By all means! (But I thin it would be desirable to have a
'plain' reduce operator as well)
Michele
--
The
Larry Wall skribis 2005-05-04 6:10 (-0700):
On Wed, May 04, 2005 at 08:59:04AM -0400, Rob Kinyon wrote:
: This may be a naive question, but what's wrong with just having a
: keyword called reduce()? Why do we need an operator for everything?
Because it's an operator/macro in any event, with
Using that argument, every keyword is really an operator/macro.
Instead of sub/method/multimethod, we could use a special character.
sub foo { ... }
becomes
foo { ... }
A method is , a multimethod is *, and so on. (I don't have a
Unicode mail client or I'd look for a Unicode character.)
What
On Wed, May 04, 2005 at 02:58:14PM +0200, Juerd wrote:
: Juerd skribis 2005-05-04 14:53 (+0200):
: @foo == zip == @bar
:
: H...
:
:@quux
: ||
: ||
: \/
: @foo == zip == @bar
: /\
: ||
: ||
1 - 100 of 113 matches
Mail list logo
