### Re: Plethora of operators

Juerd wrote: Juerd skribis 2005-05-14 17:23 (+0200): Markus Laire skribis 2005-05-14 18:07 (+0300): [+^=] (@a, @b, @c) These arrays flatten first (otherwise [+] @foo could never calculate the sum of the elements), so imagine that you have \$foo, \$bar, \$baz, \$quux, \$xyzzy to let +^= operate

### Re: Plethora of operators

On Mon, May 16, 2005 at 10:18:47AM +0300, Markus Laire wrote: : As S09 says that: : : At the statement level, a semicolon terminates the current : expression. Within any kind of bracketing construct, semicolon : notionally produces a list of lists, the interpretation of which :

### Re: Plethora of operators

[»+^=«] reminds me of a P5 regex that has a comment saying This is black magic. Don't touch!. --That's-- my complaint. Indeed. There's a time and a place for that sort of black magic, and it's usually about once per 5,000 lines of code, and so deep and well wrapped in comments and unit tests

### Re: Plethora of operators

Adam Kennedy wrote: And reduction? I write 25,000+ lines of Perl a year, and if you are talking about something like List::Util::reduce, I think I've used it maybe twice? Which proves what? That you don't (yet) write the sort of code that benefits from reductions? That you don't (yet) think in

### Re: Plethora of operators

On 14/05/05, Damian Conway [EMAIL PROTECTED] wrote: Here are a few of the things I'll be using reductions for in Perl 6... 1. To add things up: \$sum = [+] @amounts; 2. To calculate the probability that I'll need to use a reduction today: \$final_prob =

### Re: Plethora of operators

Damian Conway skribis 2005-05-14 22:56 (+1000): \$leaf_value = [.{}] %hash, @keys; \$propped = [but] \$value, @properties; With the precedence of [op] being that of a normal list op, the above are a problem. Perhaps ; or multiple == can solve this? Juerd --

### Re: Plethora of operators

Juerd [EMAIL PROTECTED] writes: Damian Conway skribis 2005-05-14 22:56 (+1000): \$leaf_value = [.{}] %hash, @keys; \$propped = [but] \$value, @properties; With the precedence of [op] being that of a normal list op, the above are a problem. Perhaps ; or multiple == can

### Re: Plethora of operators

On Sat, May 14, 2005 at 10:56:29PM +1000, Damian Conway wrote: 3. To drill down a hierarchical data structure, following the path specified by a list of keys: \$leaf_value = [.{}] %hash, @keys; I think this one needs to be written as: \$leaf_value = [.{}] \%hash,

### Re: Plethora of operators

Eirik Berg Hanssen skribis 2005-05-14 16:22 (+0200): With the precedence of [op] being that of a normal list op, the above are a problem. Perhaps ; or multiple == can solve this? I suppose the first must just make sure not to flatten the %hash: \$leaf_value = [.{}] \%hash, @keys; # %hash

### Re: Plethora of operators

DC == Damian Conway [EMAIL PROTECTED] writes: DC Here are a few of the things I'll be using reductions for in Perl 6... DC 3. To drill down a hierarchical data structure, following the path DC specified by a list of keys: DC \$leaf_value = [.{}] %hash, @keys;

### Re: Plethora of operators

Jonathan Scott Duff skribis 2005-05-14 9:49 (-0500): Then surely \$leaf = [.{}] %hash, \$k1, \$k2, \$k3 is the same as\$leaf = %hash .{} \$k1 .{} \$k2 .{} \$k3 Then perhaps the easy way out is to make .{} \$key and .[] \$index valid syntax. Or perhaps [] can play the role of

### Re: Plethora of operators

Adam Kennedy kirjoitti: [»+^=«] reminds me of a P5 regex that has a comment saying This is black magic. Don't touch!. --That's-- my complaint. I look at... but the basic operator there is just ^, with a + modifier to indicate numeric XOR, = to indicate an assignment operator, »« to indicate

### Re: Plethora of operators

Markus Laire skribis 2005-05-14 18:07 (+0300): [+^=] (@a, @b, @c) These arrays flatten first (otherwise [+] @foo could never calculate the sum of the elements), so imagine that you have Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html

### Re: Plethora of operators

Juerd skribis 2005-05-14 17:23 (+0200): Markus Laire skribis 2005-05-14 18:07 (+0300): [+^=] (@a, @b, @c) These arrays flatten first (otherwise [+] @foo could never calculate the sum of the elements), so imagine that you have \$foo, \$bar, \$baz, \$quux, \$xyzzy to let +^= operate on.

### Re: Plethora of operators

On Sat, May 14, 2005 at 05:05:10PM +0200, Juerd wrote: Jonathan Scott Duff skribis 2005-05-14 9:49 (-0500): Then surely \$leaf = [.{}] %hash, \$k1, \$k2, \$k3 is the same as \$leaf = %hash .{} \$k1 .{} \$k2 .{} \$k3 Then perhaps the easy way out is to make .{} \$key and .[]

### Re: Plethora of operators

On Sat, May 14, 2005 at 10:55:43AM -0500, Jonathan Scott Duff wrote: : But perhaps the reduce operator is some of that sufficiently advanced : technology that knows how the operator it wraps is slotted and does : something appropriate. Possibly. Or we just define infix .{}. and .[]. variants,

### Re: Plethora of operators

On Sat, May 14, 2005 at 09:20:21AM -0700, Larry Wall wrote: On Sat, May 14, 2005 at 10:55:43AM -0500, Jonathan Scott Duff wrote: : But perhaps the reduce operator is some of that sufficiently advanced : technology that knows how the operator it wraps is slotted and does : something

### Re: Plethora of operators

Larry Wall skribis 2005-05-14 9:20 (-0700): Possibly. Or we just define infix .{}. and .[]. variants, or some such. The problem is that we already have @foo[] meaning the same as @foo, and an always allowed . that also allows you to put whitespace around it. This means that %foo.{}.\$kv should

### Re: Plethora of operators

On Sat, May 14, 2005 at 06:41:35PM +0200, Juerd wrote: : Larry Wall skribis 2005-05-14 9:20 (-0700): : Possibly. Or we just define infix .{}. and .[]. variants, or some such. : : The problem is that we already have @foo[] meaning the same as @foo, and : an always allowed . that also allows you

### Re: Plethora of operators

Larry Wall wrote: On Sat, May 14, 2005 at 06:41:35PM +0200, Juerd wrote: : Larry Wall skribis 2005-05-14 9:20 (-0700): : Possibly. Or we just define infix .{}. and .[]. variants, or some such. : : The problem is that we already have @foo[] meaning the same as @foo, and : an always allowed .

### Re: Plethora of operators

On Sat, May 14, 2005 at 12:51:32PM -0500, Rod Adams wrote: : Larry Wall wrote: : : On Sat, May 14, 2005 at 06:41:35PM +0200, Juerd wrote: : : Larry Wall skribis 2005-05-14 9:20 (-0700): : : Possibly. Or we just define infix .{}. and .[]. variants, or some : such. : : : : The problem is that

### Re: Plethora of operators

Larry Wall wrote: On Sat, May 14, 2005 at 12:51:32PM -0500, Rod Adams wrote: : Unless, of course, there is some subtle difference between a 3-d hash : and a hash of hashes of hashes that invalidates this. No difference, I hope. The multidimensional notation is meant to extend to HoH and AoA

### Re: Plethora of operators

On Sat, May 14, 2005 at 01:36:22PM -0500, Rod Adams wrote: : Larry Wall wrote: : : On Sat, May 14, 2005 at 12:51:32PM -0500, Rod Adams wrote: : : : Unless, of course, there is some subtle difference between a 3-d hash : : and a hash of hashes of hashes that invalidates this. : : No difference,

### Re: Plethora of operators

On 5/14/05, Larry Wall [EMAIL PROTECTED] wrote: On Sat, May 14, 2005 at 01:36:22PM -0500, Rod Adams wrote: : Larry Wall wrote: : : On Sat, May 14, 2005 at 12:51:32PM -0500, Rod Adams wrote: : : : Unless, of course, there is some subtle difference between a 3-d hash : : and a hash of hashes

### Re: Plethora of operators

Rob Kinyon wrote: So, does this mean that I can do something like: @a = [ 1 .. 4 ]; \$x = @a{2}; and have \$x == 3? If so, is there any reason (other than clarity) to use the @a[] notation? The @ already indicates you have an array vs. the % which indicates hash. Is there a reason to have the

### Re: Plethora of operators

Damian Conway [EMAIL PROTECTED] wrote: 3. To drill down a hierarchical data structure, following the path specified by a list of keys: \$leaf_value = [.{}] %hash, @keys; When I saw this, the following happened. *pause for a second* Wow. *a few more seconds* Holy

### Re: Plethora of operators

Larry Wall skribis 2005-05-14 9:45 (-0700): : OTOH, reduce probably just needs to be smart enough to understand : postcircumfix. Perhaps whitespace helps, [{ }], in parallel with : postcircumfix:{ }, to avoid a conflict with an infix {}. Erm, I don't like tokens with spaces in the middle.

### Re: Plethora of operators

Larry wrote: Actually, I think Damian's original formulation is sufficiently clear. aolMe too!/aol ;-) I think that a standard [.infix markerpostfix marker] abbreviation for all postcircumfix operators within [op] reductions would be a useful bit of dwimmery. Damian

### Re: Plethora of operators

On 5/15/05, Juerd [EMAIL PROTECTED] wrote: How does [EMAIL PROTECTED] know the difference between postcircumfix:!@ # and postcircumfix:! @#? Perhaps it checks how many different variations are actually defined--if it finds only one, it can DWIM, and if it finds more than one it can barf with

### Re: Plethora of operators

On Wed, May 04, 2005 at 10:58:22AM -0400, Rob Kinyon wrote: : I just started following the list again after a few months (though I : have been skimming the bi-weekly summaries) and I'm a little alarmed : at what seems to be a trend towards operaterizing everything in sight : and putting those

### Re: Plethora of operators

Are there any particular other operators you're worried about? I think the current design does a pretty good job of factoring out the metaoperators so that the actual set of underlying basic operators *is* relatively small. Yes, you can now say something like \$x = [»+^=«] @foo; but