2024/11/13

Newest at the top

2024-11-13 20:49:51 +0100 <tomsmeding> read-only you can do essentially whatever you wish; for producing vectors, you should try to produce the whole thing in one go
2024-11-13 20:49:26 +0100 <tomsmeding> what you should be wary of is tail/cons
2024-11-13 20:49:17 +0100 <tomsmeding> no Foldable/Traversable are perfectly fine
2024-11-13 20:49:04 +0100 <haskellbridge> <thirdofmay18081814goya> i'll have a look i was weary of just focusing on the existence of the "Foldable" instance by fear of the possibility it would just throw out the performance benefits
2024-11-13 20:48:24 +0100 <tomsmeding> but really, just glance through https://hackage.haskell.org/package/vector-0.13.2.0/docs/Data-Vector.html
2024-11-13 20:47:54 +0100 <tomsmeding> and you can unfoldrN (unfoldr with a known target size)
2024-11-13 20:47:49 +0100 <haskellbridge> <thirdofmay18081814goya> tomsmeding: anything really i usually use my usernames as memory palaces
2024-11-13 20:47:31 +0100JuanDaugherty(~juan@user/JuanDaugherty) (Quit: JuanDaugherty)
2024-11-13 20:47:30 +0100 <haskellbridge> <thirdofmay18081814goya> vs. the imperative representation of arrays as things you "for" loop over
2024-11-13 20:47:25 +0100 <tomsmeding> but you can foldr
2024-11-13 20:47:21 +0100 <tomsmeding> you should not treat a Vector as a linked list
2024-11-13 20:47:07 +0100 <haskellbridge> <thirdofmay18081814goya> i.e. the general ability to pattern match
2024-11-13 20:47:00 +0100 <haskellbridge> <thirdofmay18081814goya> uh well I'm mostly reasoning very loosely about cata/ana, wrt List the significant part in both cases is a pattern match on "cons" into some other datatype (cata very loosely) or a pattern match on some other type onto "List" (ana very loosely)
2024-11-13 20:45:50 +0100 <tomsmeding> thirdofmay18081814goya: how should we properly mention you, because it's bridged (and not plumbed) your mxid is not a nick here, so we don't have autocomplete
2024-11-13 20:45:05 +0100abrar(~abrar@pool-72-78-199-167.phlapa.fios.verizon.net)
2024-11-13 20:45:05 +0100 <EvanR> had to review the log carefully to see who "goya" is xD
2024-11-13 20:44:55 +0100 <haskellbridge> <zwro> tomsmeding: you're absolutely correct. my examples were bad. i'm sure i had some kind of problem with driving Functor in the past but can't remember the exact case. maybe later it'll come to me
2024-11-13 20:44:40 +0100 <tomsmeding> goya: if you point to the precise "ana/cata/hylo" methods that you mean (there are various packages defining them in various ways iirc), then we could see how compatible the type signatures would be
2024-11-13 20:44:25 +0100 <EvanR> you can still treat it like a representable functor
2024-11-13 20:43:43 +0100 <tomsmeding> there are no recursion schemes for the thing because, well, it's not a tree
2024-11-13 20:43:35 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2024-11-13 20:43:28 +0100 <tomsmeding> it has a Foldable instance, and there are various methods
2024-11-13 20:43:11 +0100 <EvanR> vector package, Data.Vector
2024-11-13 20:43:00 +0100 <haskellbridge> <thirdofmay18081814goya> what module for said "Vector"?
2024-11-13 20:42:53 +0100abrar(~abrar@pool-72-78-199-167.phlapa.fios.verizon.net) (Ping timeout: 245 seconds)
2024-11-13 20:42:42 +0100 <EvanR> and has a bunch of snazzy rewrite rules for fusion
2024-11-13 20:42:14 +0100 <EvanR> but is implemented behind the scenes in a compact way
2024-11-13 20:42:03 +0100 <tomsmeding> goya: how are they defined for Vector?
2024-11-13 20:41:55 +0100 <EvanR> has a lot of instances like List does
2024-11-13 20:41:46 +0100 <EvanR> Vector is pretty good
2024-11-13 20:40:51 +0100 <haskellbridge> <thirdofmay18081814goya> can I still think in terms of ana/cata/hylo or will this destroy the performance benefits?
2024-11-13 20:40:38 +0100 <haskellbridge> <thirdofmay18081814goya> long time user of "List", now need to use arrays from performance-critical usecase (processing logs, text files of more than 3 million lines)
2024-11-13 20:40:14 +0100alexherbo2(~alexherbo@2a02-8440-3117-f07c-987b-fc29-77ee-addd.rev.sfr.net) alexherbo2
2024-11-13 20:37:13 +0100ash3en(~Thunderbi@ip1f10cbd6.dynamic.kabel-deutschland.de) (Client Quit)
2024-11-13 20:34:30 +0100 <tomsmeding> (one could of course design the _classes_ differently, but that's a separate topic)
2024-11-13 20:34:08 +0100 <tomsmeding> (my point was: I agree with your feelings, but the types imply this: "feels weird" =/=> "there are other choices for GHC's deriving mechanism")
2024-11-13 20:33:35 +0100 <tomsmeding> sure
2024-11-13 20:33:23 +0100 <c_wraith> Err. Or that foldable shouldn't provide length
2024-11-13 20:33:09 +0100 <tomsmeding> but I would argue it's a very sensible choice
2024-11-13 20:33:08 +0100 <c_wraith> that's not intuitive, but I'm not comfortable declaring tuples aren't foldable or that foldable provide length
2024-11-13 20:33:02 +0100 <tomsmeding> for Ord, Foldable, Traversable you do definitely have a choice of ordering, which constructor does it visit in which order; GHC makes a choice here
2024-11-13 20:32:41 +0100 <tomsmeding> zwro: which class? Functor doesn't give one a lot of leeway
2024-11-13 20:32:25 +0100ash3en(~Thunderbi@ip1f10cbd6.dynamic.kabel-deutschland.de) ash3en
2024-11-13 20:32:25 +0100 <tomsmeding> I would be the last one to say that `length (1,2,3) == 1` is intuitive
2024-11-13 20:32:20 +0100 <haskellbridge> <zwro> but what about trees?
2024-11-13 20:32:14 +0100 <tomsmeding> similarly for Foldable on tuples
2024-11-13 20:32:03 +0100 <haskellbridge> <zwro> point taken
2024-11-13 20:30:28 +0100 <tomsmeding> it may look weird, but by the types it must be this
2024-11-13 20:30:14 +0100 <tomsmeding> and Functor, by its kind, maps over the last type-argument
2024-11-13 20:30:06 +0100 <tomsmeding> the only sensible Functor instance for (a, b, c) is indeed the one GHC defines for tuples, because it's ((,,) a b c)