When you use REDUCE you basically operate in the DO dialect, where PAREN! groups can be used for precedence on items:
>> reduce ["Hello" (3 + 4) * 5]
== ["Hello" 35]
While in the COMPOSE dialect, PAREN! is used to call out which parts of the block you want to evaluate with the DO dialect, leaving the rest alone:
>> compose ["Hello" (3 + 4) * 5]
== ["Hello" 7 * 5]
But if you want to run reduce or compose and have a few things you want to leave in as literal parentheses, is there another idiom for it besides to-paren and a block?
>> reduce ["Hello" (3 + 4) * 5 to-paren ["inside!"]]
== ["Hello" 35 ("inside")]
Sidenote: I wonder what sort of craziness would result from LIT-PAREN?
>> reduce ["Hello" (3 + 4) * 5 '("inside!")]
== ["Hello" 35 ("inside")]
...then again, I don't know that I want to think about it. :-)
The more general way to achieve what you want is to rely on quote:
>> reduce ["Hello " (3 + 4) * 5 quote ("inside!")]
== ["Hello " 35 ("inside!")]
QUOTE is available in R3 and in R2 since 2.7.7.
Another idiom, yes:
>> reduce ["Hello" (3 + 4) * 5 first [("inside!")]]
== ["Hello" 35 ("inside")]
Not sure it's any better, but it is a different animal.
Related
The R metaop should reverse the effect of the operator it applies too. However, it does apparently a bit more than that, reversing lists if that's what it's applied to:
my #crossed = <1 2 3> Z <4 5 6>; # [(1 4) (2 5) (3 6)]
say [RZ] #crossed; # ((3 2 1) (6 5 4))
What I would like to obtain is the original lists, however, the result is reversed. Is there something I'm missing here?
R metaop does not reverse the effect of the operator. Instead it reverses the order of the operands, i.e.
$lhs <op> $rhs === $rhs R<op> $lhs
Or in your example the semantics are like this:
[RZ] [<1 4>, <2 5>, <3 6>] #is the same as [Z] [<3 6>, <2 5>, <1 4>]
Z itself does already create the original lists. No need for R Operator.
my #crossed = <1 2 3> Z <4 5 6>; # [(1 4) (2 5) (3 6)]
say [Z] #crossed; #((1 2 3) (4 5 6))
The last line here results in a incorrect signature to the map call:
my #array=[0,1,2];
say "String Repetition";
say #array.map({($_ x 2)});
say #array.map: * x 2;
say "\nCross product ";
say #array.map({($_ X 2)});
say #array.map: * X 2;
say "\nList Repetition";
say #array.map({$_ xx 2});
say #array.map: * xx 2;
The output being:
String Repetition
(00 11 22)
(00 11 22)
Cross product
(((0 2)) ((1 2)) ((2 2)))
(((0 2)) ((1 2)) ((2 2)))
List Repetition
((0 0) (1 1) (2 2))
Cannot resolve caller map(Array:D: Seq:D); none of these signatures match:
($: Hash \h, *%_)
(\SELF: █; :$label, :$item, *%_)
The x operator returns a Str, the X returns a List of Lists and the xx return a List.
Is this changed somehow using the Whatever. Why is this error happening? Thanks in advance
Let me see if I can get this through clearly. If I don't, please ask.
Short answer: xx has a special meaning together with Whatever, so it's not creating a WhateverCode as in the rest of the examples.
Let's see if I can get this straight with the long answer.
First, definitions. * is called Whatever. It's generally used in situations in which it's curried
I'm not too happy with this name, which points at functional-language-currying, but does not seem to be used in that sense, but in the sense of stewing or baking. Anyway.
Currying it turns it into WhateverCode. So an * by itself is Whatever, * with some stuff is WhateverCode, creating a block out of thin air.
However, that does not happen automatically, because some times we need Whatever just be Whatever. You have a few exceptions listed on Whatever documentation. One of them is using xx, because xx together with Whatever should create infinite lists.
But that's not what I'm doing, you can say. * is in front of the number to multiply. Well, yes. But this code in Actions.nqp (which generates code from the source) refers to infix xx. So it does not really matter.
So, back to the short answer: you can't always use * together with other elements to create code. Some operators, such as that one, .. or ... will have special meaning in the proximity of *, so you'll need to use something else, like placeholder arguments.
The xx operator is “thunky”.
say( rand xx 2 );
# (0.7080396712923503 0.3938678220039854)
Notice that rand got executed twice. x and X don't do that.
say( rand x 2 );
0.133525574759261740.13352557475926174
say( rand X 1,2 );
((0.2969453468495996 1) (0.2969453468495996 2))
That is xx sees each side as something sort of like a lambda on their own.
(A “thunk”)
say (* + 1 xx 2);
# ({ ... } { ... })
say (* + 1 xx 2)».(5);
# (6 6)
So you get a sequence of * repeated twice.
say (* xx 2).map: {.^name}
# (Whatever Whatever)
(The term *, is an instance of Whatever)
This also means that you can't create a WhateverCode closure with && / and, || / or, ^^ / xor, or //.
say (* && 1);
# 1
Note that * also does something different on the right side of xx.
It creates an infinite sequence.
say ( 2 xx * ).head(20);
# (2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2)
If xx wasn't “thunky”, then this would also have created a WhateverCode lambda.
* > 20 && * %% 5 used in grep seems wrong, does is equal to a WhateverCode lambda that takes 2 arguments? As this explain on SO
> my #a = 1,12,15,20,25,30,35,37;
> #a.grep: * > 20 && * %% 5 # The result seems strange, expected (25 30 35)
(15 20 25 30 35)
> #a.grep: * %% 5 && * > 20
(25 30 35 37)
> #a.grep: { $_>20 && $_ %% 5 }
(25 30 35)
> #a.grep: all(* > 20, * %% 5)
(25 30 35)
> #a.grep: -> $a { all($a > 20, $a %% 5) }
(25 30 35)
> #a.grep: -> $a {$a > 20 && $a %% 5}
(25 30 35)
Golfed
my &or = * == 1 || * == 2 ;
my &and = * == 1 && * == 2 ;
say .signature, .(1), .(2)
for &or, ∧
displays:
(;; $whatevercode_arg_1 is raw)TrueFalse
(;; $whatevercode_arg_4 is raw)FalseTrue
I still don't know what's going on [ed: that is, I didn't at the time I wrote this paragraph; I kept what I wrote in this answer as the mystery unfolded], but it's clear that the signature is for just one arg and the result is as per just the right hand expression for the &and and the left hand for the &or which means the code doesn't seem to have, er, left the result that's, er, right. Investigation continues... (and no, I'm not det remiker).
Mystery solved
So, it looks like the logical ops (&&, ||, and, or, etc.) don't do Whatever-currying. Which is fair enough given that "not all operators and syntactic constructs curry * (or Whatever-stars) to WhateverCode". Logical, even, given their nature. They probably ought to be added to the table of exceptions on that page though.
In the meantime, operators like == do Whatever curry. Again, that's fair enough given "subexpressions may impose their own Whatever star rules".
So it makes sense that &or and &and turn in to...
Aha! Got it. The * == 1 and * == 2 are evaluated at compile-time and turn into WhateverCodes. As WhateverCodes they are just bits of code. They are defined. They are True. (This ignores calling them at run-time.) Then along comes the && and evaluates to the right hand WhateverCode. (The || would evaluate to its left hand WhateverCode.)
Hence the behavior we see.
A solution
Per prompting by #HåkonHægland, the code that would work is therefore code that doesn't rely on logical ops Whatever-currying, i.e.:
my #a = 1,12,15,20,25,30,35,37;
say #a.grep: { $_ > 20 && $_ %% 5 } # (25 30 35)
Now what?
Now we have to figure out what doc edits to propose...
Actually, before we do that, confirm that logical ops are supposed to not Whatever-curry...
And to start that ball rolling, I just trawled the results of a search for TimToady comments on #perl6 about "currying" (there were none on #perl6-dev), looking for ones pertinent to the case we have here.
First, one from 2017 that's arguably relevant to any doc edits:
the design docs actually try to avoid the word "currying" ... but it's hard to get people to use words differently than they do
Next, one from 2015 about && and || and such:
|| and && and such are really control flow operators, turned rather rapidly into 'if' and 'unless' ... those ops can be curried with .assuming, I assume
And finally a couple from 2010 that also seem potentially important (though perhaps one or more are no longer applicable?):
all operators autocurry a WhateverCode, whether or not they curry a Whatever
I think we can keep the current mechanism as a fallback for operators that still want to curry at run time
> my $d = * + * + *
> $d.arity
3
> my $e = * == 1 || * == 2 || * == 3
> $e.arity
1
as the doc say:
Returns the minimum number of positional arguments that must be passed in order to call the code object.
so I think the all three star in * == 1 || * == 2 || * == 3 is the same thing.
> my $e = * == 1 && * == 2 && * > 3
> $e(1)
False
> $e(2)
False
> $e(3)
False
> $e(4)
True
I've been trying to exercise my Perl 6 chops by looking at some golfing problems. One of them involved extracting the bits of an integer. I haven't been able to come up with a succinct way to write such an expression.
My "best" tries so far follow, using 2000 as the number. I don't care whether the most or least significant bit comes first.
A numeric expression:
map { $_ % 2 }, (2000, * div 2 ... * == 0)
A recursive anonymous subroutine:
{ $_ ?? ($_ % 2, |&?BLOCK($_ div 2)) !! () }(2000)
Converting to a string:
2000.fmt('%b') ~~ m:g/./
Of these, the first feels cleanest to me, but it would be really nice to be able to generate the bits in a single step, rather than mapping over an intermediate list.
Is there a cleaner, shorter, and/or more idiomatic way to get the bits, using a single expression? (That is, without writing a named function.)
The easiest way would be:
2000.base(2).comb
The .base method returns a string representation, and .comb splits it into characters - similar to your third method.
An imperative solution, least to most significant bit:
my $i = 2000; say (loop (; $i; $i +>= 1) { $i +& 1 })
The same thing rewritten using hyperoperators on a sequence:
say (2000, * +> 1 ...^ !*) >>+&>> 1
An alternative that is more useful when you need to change the base to anything above 36, is to use polymod with an infinite list of that base.
Most of the time you will have to reverse the order though.
say 2000.polymod(2 xx *);
# (0 0 0 0 1 0 1 1 1 1 1)
say 2000.polymod(2 xx *).reverse;
say [R,] 2000.polymod(2 xx*);
# (1 1 1 1 1 0 1 0 0 0 0)
#!/bin/csh
# cows = 4 - 3 + 1
echo $cows
This simple csh script when run produces "0" for output when I'd expect "2".
~root: csh simple.1
0
I did a bunch of looking and the only thing I could think of was that the "-" was being read as a unary negation rather than subtraction, therefore changing operator precedence and ending up with 4 - 4 rather than 2 + 1. Is this correct? If so, any reason why? If not...help!
Edit: So they're right associative! These operators are NOT right associative in C, are they? Is C-Shell that different from C?
While you are expecting the operators to be left associative, they are right associative in csh, so it's evaluated as 4-(3+1)
-
/ \
/ \
4 +
/ \
3 1
The + and - operators are right-associative in csh. This means that '4 - 3 + 1' is evaluated as '4 - (3 + 1)'.
Operator grouping. It's reading the operation as 4 - (3 + 1), as opposed to (4 - 3) + 1.