|
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
|
|||
| Voldenet | question about docs: "$_ is the topic variable. A fresh one is created in every block." | 09:57 | |
| m: $_ = 3; { $_ = 4; }; say $_ # shouldn't this say 3 if fresh block would create a new topic variable? | 09:58 | ||
| camelia | 4 | ||
| Voldenet | m: $_ = 3; -> { $_ = 4; }(); say $_ | 10:00 | |
| camelia | 4 | ||
| Voldenet | m: $_ = 3; sub { $_ = 4; }(); say $_ | ||
| camelia | 3 | ||
| lizmat | no... because the default signature of a block binds to the outer $_ | 10:02 | |
| m: dd { say "foo" } | 10:03 | ||
| camelia | -> ;; $_? is raw = OUTER::<$_> { #`(Block|4771719725712) ... } | ||
| lizmat | Voldenet: the "-> ;; $_? is raw = OUTER::<$_>" bit | ||
| m: m: $_ = 3; -> $_ { $_ = 4; }; say $ | |||
| camelia | (Any) | ||
| lizmat | m: m: $_ = 3; -> $_ { $_ = 4; }; say $_ | ||
| camelia | 3 | ||
| lizmat | m: { say MY::<$_>:exists } | 10:04 | |
| camelia | True | ||
| Voldenet | That makes sense, but I thought that `-> {…}` syntax would change the signature to not have the topic | 10:09 | |
|
10:09
librasteve_ joined
|
|||
| lizmat | m: m: $_ = 3; -> { $_ = 4; }; say $_ | 10:09 | |
| camelia | 3 | 10:10 | |
| lizmat | it does ? | ||
| Voldenet | (in this case -> {} is not invoked) | ||
| lizmat | m: m: $_ = 3; -> { $_ = 4; }(); say $_ | ||
| camelia | 4 | ||
| lizmat | heh | ||
| that feels... wrid | 10:11 | ||
| weird rather | |||
| I guess it's to make this work: | 10:12 | ||
| m: $_ = 42; if 666 { .say } | |||
| camelia | 42 | ||
| lizmat | maybe we need to look at the docs... | 10:13 | |
| Voldenet | yes, the part about plain `{}` inheriting $_ is clear (and docs already mention it), just the part where `-> {}` also does inherit it is a bit unclear | 10:14 | |
| and I can't see docs for `$_` in pointy block signatures | 10:15 | ||
| lizmat | yeah... *that* feels like a bit of a WAT | ||
| Voldenet | though it does feel like something undocumented rather than a bug | ||
| lizmat | yeah... changing that would probably break a lot of code in the wild | ||
| Voldenet | m: sub n(&fn) { fn(); }; $_ = 3; n(-> { $_ = 4; }); say $_ # this is also modifying the $_ | 10:22 | |
| camelia | 4 | ||
| Voldenet | so I think blocks always inherit $_ unless redefined | 10:23 | |
| m: $_ = 3; -> $_ { $_ = 4; }(my $n); say $_ # | |||
| camelia | Cannot assign to a readonly variable or a value in block <unit> at <tmp> line 1 |
||
| Voldenet | m: $_ = 3; -> $_ is raw { $_ = 4; }(my $n); say $_ # | ||
| camelia | 3 | ||
| lizmat | yeah looks like | 10:24 | |
| Voldenet | would make more sense in docs.raku.org/language/variables#T...__variable | 10:25 | |
| …if it's specified in roast, that is | |||