02:33 sortiz joined 02:49 skids joined 04:15 geekosaur joined 07:27 RabidGravy joined 09:18 geekosaur joined 09:51 TimToady joined
dalek kudo/nom: fd29b24 | lizmat++ | src/core/ (16 files):
Make grep a frontend of where

Inspired by gist.github.com/0racle/ea0523759e2da15758d4 .
Remembering my first exposure to Perl and Unix, I never understood what "grep" meant: "find" was always more natural to me, but of course that meant something else in the Unix world already.
Since we already use "where" and not "grep" for subtypes, it only seems natural to use "where" instead of "grep".
868d8b4 | lizmat++ | src/core/ (16 files): Revert "Make grep a frontend of where"
This reverts commit fd29b24939bcb565a88292a5456483c3393d7cea.
11:19
lizmat the commit is github.com/rakudo/rakudo/commit/fd...939bcb565a 11:20
spectested clean, fwiw
0racle++ for getting this on the road :-) 11:21
timotimo wait, we're getting "where"?
i thought we were 100% NOPE on that suggestion?
lizmat we were ?
timotimo "we don't know something that's 100% the same as another thing", i thought
psch having both definitely seems weird 11:22
lizmat well, let me put it this way: .grep cannot be removed until we have a looong deprecation cycle
timotimo er, not "know", "want" 11:23
lizmat well, it wouldn't be the first commit of mine to be reverted :-)
psch i mean, i like the sentiment. grep is really just a *nix-ism that we don't need to be tied to 11:24
i just don't know if the deprecation cycle can ever finish, seeing as it's so culturally ingrained
lizmat well visually the o's in looooong have some feel of infiniity in them :-) 11:25
using .grep incurs a small overhead now :-)
timotimo i actually like that grep can be easily verbed, whereas where can't 11:26
lizmat
.oO( I whered it )
11:30
psch "don't you mean 'was'?"
lizmat
.oO( the items wheren't there )
11:32
masak I'm mostly "meh" about adding `where` as a method. it makes the `where` of subtypes and parameter narrowing more confusing, since it's really a different thing. 11:48
but I think things like that, targeting the most core parts of the everyday API, shouldn't be added without enough deliberation and discussion 11:49
masak lizmat++ # quick turnaround :) 11:51
lizmat :-( 11:52
masak if I were interested in adding synonyms for "where", I would probably recommend "filter", which has a lot of prior art and which people would probably recognize for what it is
"filter" is a verb
lizmat "* jnthn is glad we got something a bit shorter than filter, without having to abbreviate )" 11:53
masak well, I'm not jnthn. :) 11:54
lizmat and you're not pumpking :-) 11:55
[Coke] -1 on .where for .grep from me. Yes, I also thought it was mostly nope from the core devs on that one.
masak lizmat: no, I don't claim any authority on this. 11:56
[Coke] ... and it was reverted on the next page of scrollback.
masak I just had to search for a few minutes to re-remember what Ruby chose for this word. "select" :/
(and "reject" for negative grep, which is perhaps the only redeeming feature of that naming decision)
timotimo .keep-only-matching 11:58
lizmat let's stop this discussion: core devs (other than me) were apparently NOPE on this
I must have missed that
if either jnthn or TimToady decide it was a good idea after all, there's a revert to revert 11:59
masak I don't see why "let's stop" would be necessary -- but I'll shut up about it now
lizmat because this is quickly devolving into bikeshedding
timotimo also, there's a possibility that discussing this further could negatively impact liz' mood, which i also wouldn't like 12:00
lizmat I thought 0racle++ made a good point in gist.github.com/0racle/ea0523759e2da15758d4
timotimo not saying that's what's going on, but i think it should be considered, at least in the back of your head :)
lizmat especially about the 7 year old girls part, which rang so true with my first experience with Unix and Perl
my mood for today is already negatively impacted... so you don't have to worry about that 12:01
I'll go cycling in a little while and feel better after that
timotimo p6-wig also gives you .where, which is a good step in that direction 12:02
lizmat if you think that is a good step, why not have it in core then ? 12:03
timotimo in my day-to-day life and conversation with like-minded friends, i already use "to grep" and "grepping" as a regular word :S 12:04
lizmat "like-minded" sounds very echo-chambery to me
timotimo that's true
having the functionality duplicated still feels "smelly" to me, but throwing out grep would, as you pointed out, require a really long deprecation cycle
lizmat cycling& 12:05
psch #126527 is weird :/ 12:10
wrt .where, the deprecation cycle is what concerns me most as well 12:12
and lots of long-term *nix users might just consider that another change for the sake of change, and i don't know if there'd be enough 7 year old girls to refill the potential loss in user base there 12:13
as in, i like the change, but i think inertia is already a concern now 12:14
awwaiid hoelzro: are you doing any active work on the REPL? I've been playing with moving the looping, reading, and printing bits in there (into REPL.pm instead of the nqp Compiler.nqp and rakudo Compiler.nqp) and it's starting to look promising. 12:47
on this "where" discussion, ruby interestingly has select and find_all implemented identically, and are what we call grep. They additionally have 'grep' which does a === match (so typically passed a regex) and takes an additional block that works like a .map of the matching entries. 12:58
side note: Go to ruby-doc.org/core-2.3.0/Enumerable.html and mouse-hover over a method entry like grep. You will see a "click to toggle source" button in the upper-right corner. Click that sucker to see the top-level implementation (either in C or Ruby). Works on all the ruby-doc.org stuff -- pretty sweet. 13:01
though in ruby land ActiveRecord (and ORMs across all the lands) often use .where, though I suppose that context should in theory be pretty clear 13:03
timotimo i'd almost say we should call it .keep 13:09
awwaiid ooo. nice and short
timotimo though on second thought that sounds more like a mutating method perhaps
awwaiid ah.
timotimo @foos.keep(* < 5) really does read well
awwaiid maybe this is why the Great Unixers invented a new word :)
too bad 'take' is taken :) 13:11
masak 'keep' sounds like it'd mutate for some reason 13:12
awwaiid 'take', 'gather', 'keep', 'choose', 'adopt', ... . Alright, me being a thesaurus is probably not helpful. Time to walk the dog and get breakfast! 13:14
timotimo if we can use lojban spelling, we could spell "choice" as "cois" 13:15
that's the same length as "grep" and "keep"
choose would be even shorter as "cus"
psch ...i don't think length is the concern
timotimo jnthn said he's happy we have something shorter than "filter"
and that's just 2 additional characters compared to grep. choose is the same length as filter 13:16
psch jnthn also said "we don't two ways to do the exactly the same thing" 13:18
which points back at actually deprecating grep being the concern
at least that's how i see it 13:19
and i think that's just way to much fallout for far too little gain
well, jnthn said it grammatically correct... :) 13:24
btw, i find it humorous that this issue has already been described as bikeshed the day before yesterday here: 13:25
irclog.perlgeek.de/perl6/2016-04-01#i_12270384
and just to be clear: i'd welcome an authorative decision that says we're deprecating .grep for .where
m: my \it := [[2,3],[4,[5,6]]]>>.squish[0][2]; "$_ ".print for IterationEnd.WHICH, it, it =:= IterationEnd 13:52
camelia rakudo-moar 868d8b: OUTPUT«Mu|60166368 Use of Nil in string context in block at /tmp/52phNs24bW line 1␤ False »
psch $ ./perl6-j -e'my \it := [[2,3],[4,[5,6]]]>>.squish[0][2]; "$_ ".print for IterationEnd.WHICH, it, it =:= IterationEnd'
Mu|679099929 Mu<679099929> False
i think that's behind #125577
m: my \it := [[2,3],[4,[5,6]]]>>.squish[0][2]; "$_ ".print for IterationEnd.WHICH, it.WHICH, it =:= IterationEnd # clearer 13:54
camelia rakudo-moar 868d8b: OUTPUT«Mu|62607680 Nil False »
psch now how does the Iterator API actually work... :)
awwaiid my wife suggested 'vet' and 'sift' when I was trying to describe this to her :) 14:08
timotimo sift is a beautiful word, but is it obvious? :\ 14:09
grep isn't obvious at all, so sift probably wins that by default
TimToady I really don't think we're changing anything here; 'where' in particular has no current auto-iterative meaning, it's only used where something external is looking for a boolean smartmatch, so that would be confusing to overload 14:18
and I don't buy the etymological fallacy that just because grep used to mean something else, it means only that today
and everyone is acting like they're bored :) 14:19
timotimo btw, if anybody cares, the "lines" version of this benchmark github.com/tbrowder/perl6-read-wri...st.pl6#L46 spends about 16% of its time all-in-all gc_mark-ing an Array object; i think we're keeping around a gigantic amount of these lines rather than going through them sequentially for some reason 14:22
we don't have a "batching" thing in place there yet perhaps?
awwaiid what does "my $*AUTOPRINTPOS := nqp::tellfh(nqp::getstdout());" mean? I'm trying to understand method autoprint in nqp/src/HLL/Compiler.nqp 14:39
mmm. I guess tellfh gets the file pos. so this snapshots it and then doesn't print if something else has been printed. 14:40
ok, answered my own question, thanks
geekosaur wonders how well that works on something without a seek position 14:58
16:19 Ven joined
hoelzro awwaiid: I'm doing a bit of cleanup atm and allowing the user to select their preferred line editor 16:25
awwaiid hoelzro: what sort of cleanup? I'm making pretty good progress I think. Well I should be able to incorporate any of your cleanup well enough 16:27
hoelzro awwaiid: well, I moved the line editor role mixin stuff into their own functions for now, for example
awwaiid ah nice 16:28
I'm transferring functionality from nqp/src/HLL/Compiler.nqp -> src/Perl6/Compiler.nqp and then src/Perl6/Compiler.nqp -> src/core/REPL.pm, so that the main loop { read; eval; print } lives directly in REPL.pm . I think that doesn't conflict with the role mixins at all 16:29
hoelzro cool =) 16:30
awwaiid I'm in the middle of some destruction at the moment, but when I get it stable again I'll push the branch 16:31
masak TimToady is right -- surely we have something to energize us much more than a bikeshedding? 16:34
hoelzro awwaiid: cool, let me know! 16:36
awwaiid hoelzro: when you are devving this you just run 'make' in rakudo over and over and it takes like 1 minute each time, right? Any edit/compile/test shortcut I should be using? 16:40
hoelzro awwaiid: I revert -n this commit while I'm working: f7d1c4b 16:41
and set PERL6LIB=src/core
that way, you don't need to make to load your changes
I want to add a RAKUDO_REPL_MODULE env var to add the same functionality, but I have some concerns about how to do that securely 16:42
awwaiid that works when you make changes to REPL.pm but not src/Perl6/Compiler.nqp, right?
hoelzro yes
awwaiid ok cool
16:55 hankache joined 17:18 Ven joined 17:28 Ven joined 17:48 Skarsnik joined 17:57 pmurias joined
pmurias re grep/where having both seems inferior than having just grep 17:59
I'm might be biased in terms of UNIXisms as I was introduced to unix/perl at the same time and both seemed awesome 18:01
18:34 Ven joined 18:39 hankache_ joined
timotimo damn, i made a mistake 18:57
the part where we spend so much time in gc_mark isn't lines, it's slurp
github.com/tbrowder/perl6-read-wri...st.pl6#L63 - in this case it doesn't surprise that we'd be marking a gigantic array 18:59
lizmat is back from cycling 19:27
without starting up the .where discussion again, I would like to do a post-mortem as far as I'm concerned 19:28
- I had completely missed the discussion that had led to the NOPE verdict
I was under the impression that we would have this type of discussion on #p6dev rather than #perl6 19:29
I don't backlog #perl6 anymore: when I'm online I sort of follow it, but when I'm not, I'm not
I also understand that these discussions may happen at places where we don't expect them
I would therefore suggest that *if* we have such a discussion on a place other than #p6dev, someone should at least put a link to the discussion on #p6dev 19:30
this would saved us a lot of hassle 19:31
having missed the discussion, I thought the gist / PR had just been warnocked
- the argument that this can live in module space, I think is basically void 19:32
as far as I understand precomp, any module that does an augment, can not be used by a module that is precomped
nine jnthn is that assertion correct, or am I having a brainfart here ?
- this whole thing was about .where as a synonym for .grep 19:33
as far as I was concerned, there was never a question of needing another name for grep
just that, since we have where for subtypes, it seemed logical to have it as a synonym for .grep to me 19:34
and remembering my confusion about "grep" when entering the Unix world ~22 years ago 19:35
I thought it would make sense for non-Unix newbies
and I guess there's a reason why languages as Ruby have things like "select" and "reject", instead of "grep" 19:36
- end of post mortem
19:36 skids joined
timotimo lizmat: i'm not happy with the way i brought up my understanding of the issue when i saw that commit message :| 19:36
moritz if I wanted to implement TR///, how do I make it only available in v6.d? 19:44
lizmat moritz: afaik nine has a conceptual 6.d setting sitting in a branch 20:41
nine lizmat: I'm not sure either, but I guess things would really start to break when two precomped modules use the same class but one of them expects an augmented version and the other doesn't. 21:15
moritz: commit f6ea6553af39bf7b0a0e18bafc1ad46638b7c97e in the language_versions branch is an attempt at doing a v6.d setting 21:16
lizmat nine: I vaguely remember discussing this
nine +1 +1 +1 on posting important discussions on #p6dev
vendethiel- lizmat++: fwiw, I really appreciate that you're pushing terms easier to understand for non-unix-ers/unix newbies :) 21:22
it's most often confusing to me who hasn't been using that for 20 years :P
(even .uniq is) 21:25
lizmat vendethiel- : that's why it's called unique nowadays :0)
:-) rather :-)
vendethiel- yes, I remember bikeshedding to get that new name :P 21:27
it's good that we aren't locked up anyways, if someone wants to provide a module that re-verbs ours (use Ruby; :P), they can do that just fine! 21:28
.oO( but how long will it take for these 7 years old to learn UNIX? ) *g*
MadcapJake wrt .where: rigaux.org/language-study/syntax-ac...stKeeplmnt 21:33
lizmat good night, #perl6! 21:54
23:06 vendethiel joined 23:44 vendethiel joined