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. Compar
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
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
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?
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,
>
>
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) r
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 < >
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 ::(someT
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"
> tra
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 exa
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 ev
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;
: >
:
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) ??
&op.
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
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 mu
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' vari
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
> :
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 a
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
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'
On 6/6/05, Sam Vilain <[EMAIL PROTECTED]> wrote:
> Roger Hale wrote:
> > This is why I would rather the o -> [o] circumfixion left [o] an infix,
> > not prefix operator. I would rather be explicit about my identity:
> > $product = 1 [*] @array;
>
> Hmm. Not all operators *have* an identity.
HaloO Roger,
I'm answering here to your other mail as well. In my example
I was intensionally changing from last to first and positive
and negative numbers! This is a sublety of distance preserving,
direction aware counting in multiples of arbitrary
unity---or some such ;)
you wrote:
This is why
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 o
Roger Hale wrote:
This is why I would rather the o -> [o] circumfixion left [o] an infix,
not prefix operator. I would rather be explicit about my identity:
$product = 1 [*] @array;
Hmm. Not all operators *have* an identity.
You'd have to write, in that case;
@array[0] [ƒ] @[EMAI
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 *h
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 in
> > $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
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 w
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_i
Yep, it sure is. Now tell Perl to read it that way for any operator.
Should _I_?!? ;-)
I wonder what a logic-oriented programming language a' la prolog would say
in this case.
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 b
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 rea
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_i
Why sh
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 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
> multiplicatio
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
Joe Gottman pointed out:
No. It returns empty string. You could think of C 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 'a~b~c'
> -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 specif
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
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 dislik
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 empty-
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 empty-
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.
Feel
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" D
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 fatal
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 e
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<=X
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. B
I would really like to see ($x div $y) be (floor($x/$y)) and ($x mod $y) be
($x - $x div $y). If the divisor is positive the modulus should be
positive, no matter what the sign of the dividend. Avoids lots of special
case code across 0 boundaries.
On 2005-05-23 18:49, "TSa (Thomas Sandlaß)" <[
[EMAIL PROTECTED] wrote:
There are actuall two usefull definition for %. The first which Ada calls 'mod'
always returns a value 0<=XSigned integer division and remainder are defined by the relation:
A = (A/B)*B + (A rem B)
where (A rem B) has the sign of A and an absolute value less than
There are actuall two usefull definition for %. The first which Ada calls
'mod' always returns a value 0<=X 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 o
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 junct
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
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, th
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/
Mark~
On 5/20/05, [EMAIL PROTECTED] <[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,
> 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
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
http://www.jsoftware.com/books/help/dictionary/in
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 XSorry, is it t
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 i
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 commuta
On Fri, May 20, 2005 at 06:09:55AM -0700, Randal L. Schwartz wrote:
> > "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> operati
> "Randal" == Randal L Schwartz writes:
Randal> For example, if I wanted the identity hash (where all values are 1,
Randal> but keys are original list elements), I could do:
Randal> my %hash = @somelist.inject({}, { $^a{$^b} = 1; $^a });
And yes, I know I can spell this as:
my %hash = ({},
> "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" re
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 h
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
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 yo
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,
depe
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 f
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
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 don'
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 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 tha
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
> 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 prepen
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 u
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 o
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 p
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
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) re
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
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?
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
--
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 th
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 "long
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 te
On Fri, May 06, 2005 at 12:23:49PM +1000, Stuart Cook wrote:
> On 5/6/05, Stuart Cook <[EMAIL PROTECTED]> wrote:
> > (snip) As long as each meta-operator
> > explicitly knows what type of regular operator it accepts (and
> > produces), there shouldn't be any problems with ambiguity.
> >
>
> Havin
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 t
On 5/6/05, Stuart Cook <[EMAIL PROTECTED]> wrote:
(B> (snip) As long as each meta-operator
(B> explicitly knows what type of regular operator it accepts (and
(B> produces), there shouldn't be any problems with ambiguity.
(B>
(B
(BHaving posted that, I immediately thought of some problems:
(
On 5/5/05, Stuart Cook <[EMAIL PROTECTED]> wrote:
> +-+---+-++
> | Meta-op | is| operates on | to produce |
> +-+---+-++
> | [ ] | circumfix | infix | prefix |
> +-+---+
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 infi
On Thu, 5 May 2005, John Williams wrote:
> or even
>
> @x -= @y;
Doh! That should be C< $x -= $y; > of course.
On Thu, May 05, 2005 at 03:03:22PM -0400, Rob Kinyon wrote:
: Can I put an operator in a variable and then use it in the []
: reduce meta-operator? Something like:
:
: $op = '+';
: $x = [$op] @x;
Nope. That would be parsed as a list of one element, followed by a
syntax error. You'll have to
Can I put an operator in a variable and then use it in the []
reduce meta-operator? Something like:
$op = '+';
$x = [$op] @x;
Rob
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
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
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
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 $
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 woul
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
1 - 100 of 127 matches
Mail list logo
