|
00:07
oodani left,
oodani joined
01:01
johnjay joined
|
|||
| Voldenet | using feed operators is not insanely hard with ops if one uses blocks | 01:32 | |
| m: (1,2,3) ==> { [+] @^x }() ==> say() | |||
| camelia | 6 | ||
| Voldenet | however | 01:33 | |
| m: (1,2,3) ==> { [+] $^x }() ==> say() # uhhh | |||
| camelia | 3 | ||
| nemokosch | it just lowkey defeats the purpose | ||
| Voldenet | oh, totally not | ||
| nemokosch | well, go ahead | 01:34 | |
| I can't think of one single case where .&{} isn't superior | |||
| Voldenet | if you want to say "processing from left to right", you can't do it in any other way easily | ||
| m: (1,2,3).&{ [+] @^x }.say | |||
| camelia | 6 | ||
| nemokosch | I can think of two ways right away | ||
| .&{} and andthen | |||
| Voldenet | I can actually think of a case where it isn't superior | 01:35 | |
| m: (1,2,3) .&{ [+] @^x }.say # you want newlines | |||
| camelia | ===SORRY!=== Error while compiling <tmp> Malformed postfix call (only basic method calls that exclusively use a dot can be detached) at <tmp>:1 ------> (1,2,3) .<HERE>&{ [+] @^x }.say # you want newlines |
||
| Voldenet | :D | ||
| nemokosch | m: (1,2,3)\ .&{ [+] @^x }.say | ||
| Voldenet | in fact, that's why I use feed operator instead | ||
| nemokosch | I honestly think it's stupid but the workaround is simply | ||
| simple* | |||
| Voldenet | that \ gives it that distinct C macros feel, but I'm not a fan | ||
| nemokosch | well, it's still better than all the nuances of ==> and the random call-looking syntax | 01:36 | |
| the mere fact that you have to pretend to make a call with ==> is such a red flag imo | 01:37 | ||
| Voldenet | I do things like this with feed operators 0x0.st/PcGd.raku | ||
| nemokosch | so that the compiler frontend can rewrite the call halfway | ||
| ironically, ==> is more like a macro than andthen | 01:38 | ||
| andthen does create an evaluation context | |||
| Voldenet | Yeah, it rewrites the call | ||
| but honestly if .& worked with syntax formatting, I'd prefer it too | 01:39 | ||
| nemokosch | all the signatures are odd because you have to pass the value on the left as the argument on the right | ||
| Voldenet | haha yes, but it's nothing too uncomfortable | 01:40 | |
| other than being "weird" | |||
| nemokosch | nothing ever is "too uncomfortable" | 01:41 | |
| this feels like people saying about whatever that "you can do that in C, too, so why bother" | |||
| like of course, there will always be a way | |||
| that's not a high tally | |||
| Voldenet | for some reason I recall some horrors of seeing things being doable in C | 01:42 | |
| Dynamic arrays? Iterators? Everything is possible if you macro it hard enough | |||
| but I mean, putting the argument on the other side of the signature is just slightly different syntax than regular .& | 01:43 | ||
| it's not foreign and if you build subs for feed operators use, it requires 0 effort… | 01:44 | ||
| nemokosch | as long as you don't consider the functions interfaces | 01:45 | |
| Voldenet | …and in fact, regular ufcs like `sub($topic, $args…)` is just incompatible with it | ||
| nemokosch | which I think is quite a hard cost in itself | ||
| Voldenet | so it really depends - if you've written everything for ==> in mind, .& is going to be useless | 01:46 | |
| and the other way around | |||
| well, not useless, since you can still reorder arguments in a block | 01:47 | ||
| nemokosch | in one case, the argument to pass comes first | 01:51 | |
| in the other case, it comes last: what number is that? | |||
| in general, I think in one case you do what makes sense anyway, and .& just works with it | 01:52 | ||
| in the other case, you do what ==> forces you to | |||
| Voldenet | I'd like to disagree, but ==> does feel weird to use | 01:53 | |
| it's like | in powershell | |||
| theoretically like bash, but what the hell | 01:54 | ||
| but once you get used to this weirdness, it's not that different | 01:55 | ||
| nemokosch | again, "it's not useless" | 01:59 | |
| but not really worth using either | |||
| [Coke] | nice test module for reporting where two long lists differ (not just that they do) | 02:14 | |
| ? | 02:15 | ||
| antononcube | @Coke "Algorithm::Diff" should work on sequence. | 02:30 | |
| "Math::DistanceFunctions::Edit" can be used to find Edit distance between two sequences. | 02:33 | ||
| [Coke] | ... Those aren't Test modules, though. | 02:38 | |
| nemokosch | it wasn't clear what kind of criterion "test modules" encodes | ||
| antononcube | I see. I was not sure what "test module" is. I thought "test" as "function" (for making a test.) | 02:39 | |
| nemokosch | I'd have suggested to just turn them into key-value pairs and then zip and filter some way | ||
|
02:43
hulk joined
02:45
kylese left
|
|||
| [Coke] | as in a module that exports test functions (like Test) that generate TAP, but with helpful output and not "expected: <1000 characters>, got: <1000 slightly different ones>" | 02:50 | |
| but yes, could use those to make the one I want if it doesn't exist. | 02:51 | ||
| doesn't matter now, the test is passing. | |||
|
03:11
johnjay left
03:15
hulk left,
kylese joined
03:20
arkiuat left
03:36
johnjay joined
03:37
johnjay left
03:45
johnjay joined
03:50
johnjay left
04:04
lichtkind__ joined
04:06
lichtkind_ left
04:10
Romanson joined
04:23
Aedil joined
04:27
stanrifkin_ joined
04:29
stanrifkin left
04:59
wayland76 joined
05:01
stanrifkin_ left
05:09
johnjay joined
05:10
johnjay left
05:18
johnjay joined
09:00
Romanson left
|
|||