Logs: liberachat/#haskell
| 2021-07-01 20:55:51 | <monochrom> | I feel that the pushback operation is usually motivated by, only, wanting a lookahead and deciding split it into read-then-pushback. |
| 2021-07-01 20:56:10 | <dminuoso> | What's the role of "putback"? leftover from conduit? |
| 2021-07-01 20:56:16 | <davean> | monochrom: its not wanting - theres no choice |
| 2021-07-01 20:56:21 | <tomsmeding> | dminuoso: as monochrom says, lookahead |
| 2021-07-01 20:56:24 | <monochrom> | in which case perhaps supporting lookahead itself directly solves the real problem |
| 2021-07-01 20:56:25 | <davean> | the control domains are split |
| 2021-07-01 20:56:28 | <dminuoso> | tomsmeding: Right, then `leftover`! |
| 2021-07-01 20:56:34 | <dminuoso> | Alright, I see what you mean |
| 2021-07-01 20:57:03 | <davean> | Leftover (Pipe l i o u m r) l |
| 2021-07-01 20:57:05 | <davean> | Return leftover input, which should be provided to future operations. |
| 2021-07-01 20:57:07 | → | safinaskar joins (~safinaska@109.252.90.89) |
| 2021-07-01 20:57:12 | → | nate1 joins (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-01 20:57:13 | <davean> | thats part of the core operational instructions of Conduit |
| 2021-07-01 20:57:23 | × | TheRAt quits (~TheRAt@user/therat) (Ping timeout: 268 seconds) |
| 2021-07-01 20:57:40 | <davean> | monochrom: well, its required if you're *monadic* I suppose - I guess weaker streaming might not require it |
| 2021-07-01 20:57:41 | <tomsmeding> | that's approaching the number of type parameters in a project of mine |
| 2021-07-01 20:57:48 | <davean> | monochrom: I'd have to consider if its optional in Selective |
| 2021-07-01 20:58:00 | <monochrom> | and I feel that lookahead semantics and implementation is likely much nicer than pushback semantics and implementation |
| 2021-07-01 20:58:11 | <dminuoso> | davean: Leftover is mostly just needed for fusion (and lookahead) though. |
| 2021-07-01 20:58:19 | <chris_> | thx cale tomsmeding, looking at your stuff now |
| 2021-07-01 20:58:27 | <safinaskar> | is there analog of c++'s std::vector in haskell? i. e. mutable vector i can add elements to. It should have function with type (Vec s a -> a -> ST s (Vec s a)) and that function should not create copy of a vector! |
| 2021-07-01 20:58:29 | <chris_> | i just wrote another func for now with another param |
| 2021-07-01 20:58:31 | <davean> | monochrom: You'd have to have fusion across arbitrary monadic value sets |
| 2021-07-01 20:58:36 | <chris_> | but i'll see how u guys did it |
| 2021-07-01 20:58:39 | <dminuoso> | or rather I need to got sleep, I cant form coherent sentences anymore |
| 2021-07-01 20:58:39 | <chris_> | or recommend |
| 2021-07-01 20:58:52 | <davean> | monochrom: I don't think its viable in any generalized streaming library |
| 2021-07-01 20:59:05 | <safinaskar> | i am aware of hackage package "vector", but as well as i know, its "grow" function creates copy of source vector, and thus can be slow |
| 2021-07-01 20:59:13 | <davean> | safinaskar: 'vector' |
| 2021-07-01 20:59:21 | <davean> | safinaskar: C++'s also creates a copy |
| 2021-07-01 20:59:34 | <tomsmeding> | davean: only if it exhausts the underlying buffer |
| 2021-07-01 20:59:48 | <davean> | tomsmeding: correct, smae as MVector in 'vector' with certain uses |
| 2021-07-01 21:00:08 | <safinaskar> | davean: if you push N elements to c++'s vector one-by-one, full copy will be performed (log N) times |
| 2021-07-01 21:00:09 | <ixlun> | So, is the issue that I'm having that I don't have a 1:1 mapping between input and output elements? |
| 2021-07-01 21:00:17 | <davean> | safinaskar: sure, so do that with 'vector' |
| 2021-07-01 21:00:30 | <dminuoso> | ixlun: Personally Id do some memory profiling to be sure here. |
| 2021-07-01 21:00:31 | <safinaskar> | davean: docs don't say this |
| 2021-07-01 21:00:51 | <chris_> | https://paste.tomsmeding.com/xxaG2Kxy |
| 2021-07-01 21:00:58 | <chris_> | tomsmeding: |
| 2021-07-01 21:01:09 | <davean> | safinaskar: MVector !Int !Int !(MutableArray s a), so you'd have to use it the way you want it |
| 2021-07-01 21:01:10 | <chris_> | Cale: |
| 2021-07-01 21:01:41 | <davean> | safinaskar: it doesn't manage it for you |
| 2021-07-01 21:01:44 | <dminuoso> | ixlun: I gotta go to bed, but this talk nicely illuminated how you can e.g. use eventlog2html https://www.youtube.com/watch?v=6Ljv5FHGXDM |
| 2021-07-01 21:01:54 | <safinaskar> | okey, give 5 mins, i will write example |
| 2021-07-01 21:01:54 | × | nate1 quits (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2021-07-01 21:02:08 | <dminuoso> | (or ghc-debug) |
| 2021-07-01 21:02:10 | <davean> | safinaskar: But it allows slicing, so basicly you just return the size you want when you finish |
| 2021-07-01 21:02:23 | <davean> | safinaskar: its not as nice |
| 2021-07-01 21:02:32 | <ixlun> | dminuoso: Cool, thanks for the talk. I'll have a watch and see if I can get any further. Thanks! |
| 2021-07-01 21:03:23 | <monochrom> | Yeah, I think Selective is related. Moving even one level up, the only motivation of lookahead is "a <- lookahead; case a of { 5 cases; }". It may be even better to just provide a cominbator for that instead of exposing lookahead. |
| 2021-07-01 21:03:32 | <davean> | monochrom: anyway, I'd be super interested if you could show that you could cover the space of even something as limited as Conduit with just lookahead |
| 2021-07-01 21:03:36 | <davean> | I don't think its theoretically possible |
| 2021-07-01 21:04:04 | <davean> | monochrom: no, sadly thats not the only motivation |
| 2021-07-01 21:04:10 | <dminuoso> | ixlun: Personally I suspect that at the end of your pipe you have something like a large String (or maybe some [Bit]), and are left with large amounts of unconsumed input. |
| 2021-07-01 21:04:27 | <davean> | monochrom: I can push the pushback to an arbitrary depth |
| 2021-07-01 21:04:33 | <dminuoso> | But I encourage you to perhaps look at the video, and try and employ those memory debugging techniques yourself. |
| 2021-07-01 21:05:16 | × | _ht quits (~quassel@82-169-194-8.biz.kpn.net) (Remote host closed the connection) |
| 2021-07-01 21:05:21 | <ixlun> | Indeed, I'll take a look.. Might be a job for tomorrow though. hanks for the link! |
| 2021-07-01 21:05:35 | <monochrom> | Then this comes down to "LL(1) is much more optimzable than arbitrary lookahead, which is yet more optimizable than full monadic" etc. |
| 2021-07-01 21:05:37 | <davean> | monochrom: this issue is deeply related to parsing |
| 2021-07-01 21:05:47 | <monochrom> | Yeah, that. |
| 2021-07-01 21:05:51 | <dminuoso> | Debugging this in terms of allocations is probably easier, since GHC has good abilities to show you where allocations happen exactly |
| 2021-07-01 21:06:16 | <davean> | which is why I like calling in an explicite stack when I need it |
| 2021-07-01 21:06:40 | × | cuz quits (~user@38.140.58.234) (Ping timeout: 265 seconds) |
| 2021-07-01 21:06:42 | × | MQ-17J quits (~MQ-17J@d14-69-206-129.try.wideopenwest.com) (Ping timeout: 240 seconds) |
| 2021-07-01 21:07:00 | <safinaskar> | here is example! https://paste.debian.net/1203071/ |
| 2021-07-01 21:07:31 | <monochrom> | BTW unpopular opinion: Control.Machine and Data.Lens. >:) |
| 2021-07-01 21:07:33 | <safinaskar> | how many times this code will duplicate whole vector? (assuming N is length of source list, i. e. length of [a]) |
| 2021-07-01 21:07:37 | <safinaskar> | N or log(N)? |
| 2021-07-01 21:08:42 | <davean> | safinaskar: N, because you're calling grow every time instead of slicing the vector |
| 2021-07-01 21:09:16 | <tomsmeding> | davean: so what safinaskar is asking is whether there is a library that already encapsulates this intelligent growing behaviour |
| 2021-07-01 21:09:30 | <tomsmeding> | (like std::vector in c++ :) ) |
| 2021-07-01 21:09:30 | <davean> | tomsmeding: for streaming and such there is, not sure about list |
| 2021-07-01 21:09:56 | <davean> | for list, vector already has stuff |
| 2021-07-01 21:10:13 | <tomsmeding> | I haven't seen such a library but that says absolutely nothing because I'm usually quite unaware of all the wealth of libraries in existence |
| 2021-07-01 21:10:28 | → | MQ-17J joins (~MQ-17J@d14-69-206-129.try.wideopenwest.com) |
| 2021-07-01 21:10:38 | <davean> | Data.Vector.fromList is O(N) |
| 2021-07-01 21:10:41 | → | abrar_ joins (~abrar@static-108-2-152-54.phlapa.fios.verizon.net) |
| 2021-07-01 21:10:47 | <davean> | which clearly you can see doesn't allow N copies |
| 2021-07-01 21:10:54 | <davean> | for example |
| 2021-07-01 21:11:31 | <tomsmeding> | well yes, if you know in advance how many elements you're going to push, you can do it in linear time :) |
| 2021-07-01 21:11:54 | <davean> | https://hackage.haskell.org/package/vector-conduit-0.5.0.0/docs/Data-Conduit-Vector.html for streaming for example |
| 2021-07-01 21:12:03 | <davean> | tomsmeding: fromListN vs. fromList ;) |
| 2021-07-01 21:12:49 | <davean> | tomsmeding: Vector's fusion system takes care of it |
| 2021-07-01 21:12:54 | <davean> | oh, ok |
| 2021-07-01 21:12:55 | × | Pickchea quits (~private@user/pickchea) (Quit: Leaving) |
| 2021-07-01 21:13:10 | <davean> | heres whats confusing here! safinaskar and tomsmeding, Vector depends on fusion to deal with this sort of thing |
| 2021-07-01 21:13:47 | <tomsmeding> | which merges operations only if the compiler can pair them together |
| 2021-07-01 21:14:03 | <davean> | tomsmeding: well, of it you do them specificly via explicite fusion |
| 2021-07-01 21:14:12 | <davean> | tomsmeding: but like fromList does that explicitely |
| 2021-07-01 21:14:17 | <tomsmeding> | right |
| 2021-07-01 21:15:22 | <davean> | so Vector already encapsulates this, just not how you expect to see it |
| 2021-07-01 21:16:12 | <davean> | All the normal functions in Vector already use it though |
| 2021-07-01 21:16:20 | <tomsmeding> | but long story short, Vector doesn't have this 'push' operation, but it should be easily implementable in terms of 'grow' with slicing? |
| 2021-07-01 21:16:33 | <davean> | tomsmeding: It does have the push operation, on Streams |
| 2021-07-01 21:16:47 | <davean> | tomsmeding: under Data.Vector.Fusion.Stream |
| 2021-07-01 21:17:11 | <davean> | tomsmeding: see snoc and cons |
| 2021-07-01 21:17:50 | × | takuan quits (~takuan@178-116-218-225.access.telenet.be) (Ping timeout: 272 seconds) |
| 2021-07-01 21:18:10 | <safinaskar> | tomsmeding: "but it should be easily implementable in terms of 'grow' with slicing" - no, because i don't want new variable, i want "push" to look like it changed existing entity. I. e. I want to still refer to my modified vector using same "MVector s a" handle, just as I can in C++ |
| 2021-07-01 21:19:00 | <davean> | cons prepends an element, snock appends an element |
All times are in UTC.