🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm Set by lizmat on 8 June 2022. |
|||
04:47
kjp left
04:48
kjp_ joined
07:34
samebchase left
07:36
samebchase joined
08:28
sena_kun joined
11:21
Altai-man joined
11:25
sena_kun left
12:45
raiph joined
|
|||
Geth | rakudo/lizmat-flat-hammer: aced91cf4c | (Elizabeth Mattijsen)++ | 2 files Improve .flat logic - add positional to indicate number of levels to flatten. Defaults to Inf / Whatever - add boolean named arg :hammer. If specified with a true value, will disregard any containerization on Iterables, and flatten those iterables. Defaults to False Inspired by github.com/Raku/problem-solving/issues/431 |
12:53 | |
rakudo: lizmat++ created pull request #5594: Improve `.flat` logic |
12:54 | ||
ugexe | can't that already be done with .tree? | 13:07 | |
i'm not sure, i just remember .tree being able to do something with arbitrarily nested data structures | |||
lizmat | I guess: .tree(*.flat xx 10) would do 10 levels of flattening | 13:19 | |
but infinite levels of flattening are not supported: | |||
m: dd (1,$(2,$(3,(4,5,()))),42,43,(44,45)).tree(*.flat xx 10); | |||
camelia | (1, 2, 3, 4, 5, 42, 43, 44, 45).Seq | ||
lizmat | m: dd (1,$(2,$(3,(4,5,()))),42,43,(44,45)).tree(*.flat xx *); | ||
camelia | Cannot .elems a lazy list in block <unit> at <tmp> line 1 |
||
ugexe | Should it work though? if yes I'd probably argue *that* should be the supported way of multi-level flattening | 13:48 | |
lizmat | well... arguably it should work, but whether that would need to be the (only) way to support multi-levek flattening? | 13:52 | |
it would require you to know abour .tree *and* *.flat xx * | |||
the latter I think is definitely not for newbies | |||
ugexe | we have to consider huffmanization, and part of that involves how long raku has existed without anyone asking for an alternative way of doing it | 13:55 | |
regardless, newbies would have to know how to use these additions to .flat. and that knowledge only applies to this one specific function | 13:57 | ||
lizmat | re hufmannization: perhaps :hammer should be True by default in 6.e | 14:02 | |
ugexe | i imagine that would break a whole lot of code | ||
and again: why is this being huffmanized? | 14:04 | ||
lizmat | see github.com/Raku/problem-solving/issues/431 | ||
ugexe | my interpretation is that one person has asked for this. i | 14:05 | |
i'm not sure that is a good reason to huffmanize something | |||
arguably three people :) i'm not sure at what number i would draw the line, it just feels like the beginning of a discovery process or something rather than a sufficient number of people needing it | 14:06 | ||
as a discovery process we have found that .tree can potentially solve this issue | 14:07 | ||
that being said I don't have much else to add. i was mostly curious if this could already be done without additional api surface area | 14:09 | ||
lizmat | could you add these remarks to the PS issue ? | 14:13 | |
or shall I just add a link to the irclogs ? | |||
14:14
kjp_ left,
kjp joined
|
|||
lizmat | done so | 14:15 | |
afk& | |||
gfldex | When it comes to flattening large trees performance becomes a consideration. I don't think .tree(*.flat xx 10) would win that race. | 14:16 | |
ugexe | why not? note i have no idea how .tree or .flat are actually implemented | 14:17 | |
gfldex | It has to build that `xx` list and apply a Whatevercode. You can't speed that up with nqp-ops. | 14:18 | |
ugexe | if the performance difference between those two techniques is large then I'd be more inclined to agree with the proposed PR | 14:31 | |
nine | That list can be constant folded at compile time and calling a Whatevercode is just that - calling code, which we've become quite good at since newdisp | 14:42 | |
14:45
librasteve_ joined
|
|||
librasteve_ | o/ | 14:45 | |
some fair comments on the level of ask on :hammer, I have dug up a couple of examples of others on raku channels that have been irked by flat and posted these over on PS | |||
15:45
raiph left
|
|||
Geth | rakudo/lizmat-flat-hammer: da853f8367 | (Elizabeth Mattijsen)++ | src/core.c/Array.rakumod Make sure Arrays also get hammered The Array class had a shortcut to .flat, because all of the elements in an Array are always containerized, so calling .flat on it wouldn't change anything anyhow. Until we added the :$hammer named argument. So if that is specified with a True value, call the Iterable's version of .flat instead |
18:44 | |
19:31
librasteve_ left
20:51
Altai-man left,
Altai-man joined
23:01
Altai-man left
|