🦋 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