New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate flatmap
#5989
Comments
From @smlsSo, Perl 6 has a built-in `flatmap` routine: .flatmap({ ... }) Show of hands: Who is reasonably sure, without testing it or looking .flat.map({ ... }) .map({ ... }).flat .flat.map({ ... }).flat .map({ slip ... }) And if Perl 6 regulars and core developers can't tell, do you think a Note that the four behaviors are the same (or at least easy to Second strike: Whoever wrote the p6doc entry Third strike: Its behavior isn't actually tested in Roast. The single Fourth strike: Whereas `deepmap` and `duckmap` differ from plain `map` Is all that confusion (and the needless proliferation of the Perl 6 Unless I'm missing something vital, I'd say it's hard to argue that I therefore suggest initiating the deprecation cycle in order to |
From @zoffixznetOn Thu, 05 Jan 2017 21:47:20 -0800, smls75@gmail.com wrote:
✋
What do you mean? I just raised my hand showing I was sure! And there
You seem to have a pretty good idea of what it does. Why not fix the docs |
The RT System itself - Status changed from 'new' to 'open' |
From @LLFournI took a look through my codebase to see where I have used flatmap. Every so +1 LL On Fri, Jan 6, 2017 at 4:47 PM Sam S. <perl6-bugs-followup@perl.org> wrote:
|
From @AlexDanielOn 2017-01-05 21:47:20, smls75@gmail.com wrote:
Another thing to note is that flatmap was working differently before the GLR. <AlexDaniel> commit: pre-glr,HEAD say ((1, 2), <a b>).flatmap(&uc).join('|'); To me it seems that it slipped through the cracks and nobody thought about it after the GLR. So yes, if somebody thinks that flatmap should stay, please justify its existence. Until then, +1. |
From @smls
Okay, I get it, I shouldn't have tried to be cute in how I phrased that. But do you really think I'm wrong in considering each of the four behaviors listed at the top as something that a reasonable Perl 6 user might expect a routine called `flatmap` to do, and that this presents a trap? Especially if the behavior of the similarly named `deepmap` leads one to guess wrong? If a feature provides significant value, such a trap can be a fair price. But if `flatmap` has any value at all over chaining `map` and `flat`, it's not apparent. Can it work marginally faster? If so, that might justify its use in core, but for a user-exposed builtin that seems like a weak rationale. I can't think of any other functionally redundant built-in in Perl 6 that exists purely for some slight performance benefit. The possibilities for a slippery slope would be endless: Do we also need a `flatzip`, `flatrotor`, `grepmap`, etc? Or was it introduced to avoid copying the whole list in memory between the `map` and `flat` step, back when `map` used to return a memoizing `List/Parcel` rather than a one-off `Seq` before the GLR?
I think the state of its documentation is a symptom of the confusion the routine provokes, not its cause. Also, I only know what I found out by thoroughly testing the routine with Rakudo. In order to properly update the docs, waiting for an explanation from the language designers / core developers would be prudent, I think, seeing how it has no meaningful tests in Roast isn't mentioned in the design docs. |
From @zoffixznetOn Wed, 11 Jan 2017 03:03:29 -0800, smls75@gmail.com wrote:
Right, it's a bit weird to base your argument on a fictional survey with results you made up :)
In a way, yeah. deepmap doesn't do a combination of .deep and .map called in a particular order. I'd expect .flatmap to do something that *can't* be replicated by putting a dot in its name to make two other method calls. But it does, so IMO .flatmap is kinda useless. |
From @zoffixznet
Nope. I agree it should be tossed. There's one test in 6.c-errata that merely tests its nodality. I'd say deprecate it in 6.d and toss it in 6.e. I listed that on the 6.d's TODO: Raku/6.d-prep@2cc614b |
From @AlexDanielA lot of discussion drifted to this ticket for some reason: Raku/doc#1428 Let's get ourselves back here. On 2017-07-31 14:40:50, cpan@zoffix.com wrote:
|
Migrated from rt.perl.org#130520 (status was 'open')
Searchable as RT130520$
The text was updated successfully, but these errors were encountered: