Newest at the top
| 2024-11-13 21:10:20 +0100 | <dmj`> | haskell report, "Modules may be mutually recursive." |
| 2024-11-13 21:08:43 +0100 | <lxsameer> | cheers |
| 2024-11-13 21:08:42 +0100 | <yin> | it's a language extension |
| 2024-11-13 21:08:26 +0100 | <yin> | functional dependencies |
| 2024-11-13 21:07:45 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3117-f07c-987b-fc29-77ee-addd.rev.sfr.net) (Ping timeout: 256 seconds) |
| 2024-11-13 21:04:30 +0100 | mari-estel | (~mari-este@user/mari-estel) (Quit: good night) |
| 2024-11-13 21:00:44 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2024-11-13 21:00:05 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-11-13 20:59:18 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-11-13 20:59:15 +0100 | <lxsameer> | tomsmeding: since I don't know the name of this concept, i don't know what to search in the manual |
| 2024-11-13 20:58:14 +0100 | <tomsmeding> | but read the manual |
| 2024-11-13 20:58:11 +0100 | <tomsmeding> | the `|` is more like the `|` in a list comprehension, and the `->` is a bit like implication here |
| 2024-11-13 20:58:09 +0100 | <lxsameer> | ah got it, thanks folks |
| 2024-11-13 20:57:58 +0100 | <tomsmeding> | lxsameer: yes :) |
| 2024-11-13 20:57:56 +0100 | <geekosaur> | not as "or" |
| 2024-11-13 20:57:52 +0100 | <geekosaur> | in general a single vertical bar in Haskell is read as "where" or "such that" |
| 2024-11-13 20:57:41 +0100 | <lxsameer> | tomsmeding: was that `no` for me? |
| 2024-11-13 20:57:12 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 276 seconds) |
| 2024-11-13 20:56:53 +0100 | <tomsmeding> | https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/functional_dependencies.html#extens… |
| 2024-11-13 20:56:46 +0100 | <tomsmeding> | -XFunctionalDependencies |
| 2024-11-13 20:56:42 +0100 | <tomsmeding> | no |
| 2024-11-13 20:56:33 +0100 | <lxsameer> | in the following syntax `class Monad m => MonadReader r m | m -> r where` that pipe reads as MonadReader on r m OR m -> r, correct? |
| 2024-11-13 20:56:23 +0100 | <tomsmeding> | vector tries a bit too hard to be generic with a bunch of stuff |
| 2024-11-13 20:56:13 +0100 | <tomsmeding> | reading the source here is not likely to be very enlightening :D |
| 2024-11-13 20:55:56 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2024-11-13 20:55:36 +0100 | <haskellbridge> | <thirdofmay18081814goya> ok i will spend a while reading these and their source, highly appreciate the comments tyvm |
| 2024-11-13 20:54:26 +0100 | <tomsmeding> | `containers` also does (Data.Map etc.) |
| 2024-11-13 20:54:13 +0100 | <tomsmeding> | yes |
| 2024-11-13 20:54:09 +0100 | <haskellbridge> | <thirdofmay18081814goya> oh wow ok the package annotates each function's time complexity |
| 2024-11-13 20:54:03 +0100 | <tomsmeding> | as long as you're just reading into an existing immutable vector, almost anything sensible is fast |
| 2024-11-13 20:53:46 +0100 | <tomsmeding> | Data.Vector has GHC rewrite rules (RULEs) that try to make creating vectors fast even if you use multiple functions after each other (e.g. cons, append, fromList), but for best results, try to create the whole thing in one go |
| 2024-11-13 20:53:46 +0100 | mantraofpie | (~mantraofp@user/mantraofpie) (Ping timeout: 260 seconds) |
| 2024-11-13 20:52:52 +0100 | <tomsmeding> | cons creates a new vector |
| 2024-11-13 20:52:51 +0100 | hellwolf | (~user@0e2f-3a3b-aecf-adb3-0f00-4d40-07d0-2001.sta.estpak.ee) hellwolf |
| 2024-11-13 20:52:47 +0100 | <tomsmeding> | tail and init are read-only |
| 2024-11-13 20:52:36 +0100 | <haskellbridge> | <thirdofmay18081814goya> wait sorry I'm not fully understanding, what distinguishes tail/init vs. tail/cons? |
| 2024-11-13 20:52:31 +0100 | mantraofpie_ | (~mantraofp@user/mantraofpie) mantraofpie |
| 2024-11-13 20:51:18 +0100 | <tomsmeding> | (so tail/init etc. are actually quite fine, they are O(1) and just produce views on the underlying data) |
| 2024-11-13 20:50:19 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 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 +0100 | JuanDaugherty | (~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 |