| 2024-08-09 00:00:14 +0200 | <monochrom> | In Haskell, someone has to choose one of them. |
| 2024-08-09 00:00:31 +0200 | <zzz> | is the fact that foldr and foldl can be defined in terms of eachother relevant to the argument you're making? |
| 2024-08-09 00:01:50 +0200 | <EvanR> | can they? |
| 2024-08-09 00:02:24 +0200 | <EvanR> | (specifically for list) |
| 2024-08-09 00:03:56 +0200 | <monochrom> | We can assume finite data structures for this context. |
| 2024-08-09 00:04:37 +0200 | <zzz> | yes, i admit some handwaving |
| 2024-08-09 00:04:40 +0200 | <monochrom> | Actually, 4 default implementations: foldr, foldl, fold, toList. |
| 2024-08-09 00:05:31 +0200 | <EvanR> | reducing a tree seems to have many possible strategies not just 4 |
| 2024-08-09 00:07:18 +0200 | <zzz> | trees are inherently something, right? like lists are inherently right fold by the way the data type is defined |
| 2024-08-09 00:07:48 +0200 | <EvanR> | you might say a list is a right leaning tree and a snoc list is left leaning |
| 2024-08-09 00:07:51 +0200 | <zzz> | i may not be expressing myself with the best words |
| 2024-08-09 00:07:57 +0200 | <monochrom> | trees are inherently trees. |
| 2024-08-09 00:08:08 +0200 | <sprout> | say it like it is |
| 2024-08-09 00:08:47 +0200 | <probie> | <unhelpful>`foldl` is just a special case of `foldr` for lists</unhelpful> |
| 2024-08-09 00:09:17 +0200 | <monochrom> | or you could say "branching left right and centre" if you're still looking for metaphors. |
| 2024-08-09 00:10:56 +0200 | <zzz> | can an argument be made that foldr should be just called fold? |
| 2024-08-09 00:11:20 +0200 | <EvanR> | :t fold |
| 2024-08-09 00:11:21 +0200 | <lambdabot> | (Foldable t, Monoid m) => t m -> m |
| 2024-08-09 00:11:37 +0200 | <EvanR> | see, that one is interesting because it doesn't matter how you reduce the tree, it comes out the same |
| 2024-08-09 00:11:45 +0200 | <EvanR> | because monoidness |
| 2024-08-09 00:12:20 +0200 | <zzz> | i want to understand this better |
| 2024-08-09 00:12:21 +0200 | <EvanR> | foldl and foldr meanwhile rely on narratives |
| 2024-08-09 00:12:40 +0200 | <monochrom> | I am not sure what's the use of such an argument, but yes. Because an argument can be made that X sshould be called Y, for all X and Y. |
| 2024-08-09 00:13:20 +0200 | <monochrom> | OK I know what's the use. Some people enjoy power trips obtained from controlling and/or changing terminology. |
| 2024-08-09 00:13:27 +0200 | <EvanR> | foldl and foldr appeal you specific reductions in situations where the order might matter |
| 2024-08-09 00:13:33 +0200 | <EvanR> | appeal to* |
| 2024-08-09 00:13:58 +0200 | <EvanR> | so some semblance of specificity is tacked onto the name |
| 2024-08-09 00:14:07 +0200 | <zzz> | agree |
| 2024-08-09 00:14:21 +0200 | <zzz> | but foldr is the "natural" one, isn't it |
| 2024-08-09 00:14:32 +0200 | <probie> | `foldr` (on lists, not `Foldable` in general) doesn't rely on a narrative at all, and is _the_ fold for lists. If I was making the standard library (and didn't have a `Foldable` typeclass), I'd have just called it fold |
| 2024-08-09 00:14:45 +0200 | <zzz> | the more fundamental one, using monochrome's terminology |
| 2024-08-09 00:14:49 +0200 | <EvanR> | foldl is "natural" for snoc lists? |
| 2024-08-09 00:15:16 +0200 | <probie> | Sure, but "snoc lists" aren't "lists", you've just moved the conversation from lists back to `Foldable` |
| 2024-08-09 00:15:17 +0200 | <monochrom> | This is why I don't say "fold" I say "catamorphism". |
| 2024-08-09 00:15:26 +0200 | <EvanR> | fold = foldr for lists makes sense because performance |
| 2024-08-09 00:15:45 +0200 | <zzz> | monochrom: catar / catal :p |
| 2024-08-09 00:15:52 +0200 | <EvanR> | doing it in another order would get the same answer but be silly |
| 2024-08-09 00:16:41 +0200 | <EvanR> | fold = foldr in general I don't know about that |
| 2024-08-09 00:17:05 +0200 | <zzz> | EvanR: silly is a strong word |
| 2024-08-09 00:17:11 +0200 | <EvanR> | yeah catamorphism is something else |
| 2024-08-09 00:17:32 +0200 | <EvanR> | which is a transformation rather than a reduction |
| 2024-08-09 00:17:33 +0200 | <probie> | monochrom: if I say {cata,ana,hylo}morphism instead of {∅,un,re}fold, I get in trouble for being elitist |
| 2024-08-09 00:17:39 +0200 | <EvanR> | but you can implement one with the other |
| 2024-08-09 00:19:19 +0200 | CiaoSen | (~Jura@2a05:5800:22f:a900:e6b9:7aff:fe80:3d03) (Ping timeout: 264 seconds) |
| 2024-08-09 00:19:27 +0200 | <zzz> | i think i get it. thanks |
| 2024-08-09 00:22:05 +0200 | <probie> | EvanR: I don't think you're right about them being different. In "Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire" there's the line "Without special notations pinpointing cata such as (|_|) or foldr" |
| 2024-08-09 00:22:38 +0200 | <probie> | The people who brought the term "catamorphism" to the "mainstream", think that `foldr` is a catamorphism |
| 2024-08-09 00:22:41 +0200 | <EvanR> | that doesn't prove I'm not right it proves what people mean by foldr isn't universal |
| 2024-08-09 00:23:12 +0200 | AlexNoo_ | (~AlexNoo@94.233.240.239) |
| 2024-08-09 00:23:32 +0200 | <monochrom> | I would simply leave communities that think that "catamorphism" is elitist. |
| 2024-08-09 00:24:19 +0200 | <monochrom> | And circling back, perhaps they do so for power trips. |
| 2024-08-09 00:24:45 +0200 | <Rembane> | +1 |
| 2024-08-09 00:25:20 +0200 | <EvanR> | I never understood elitist-as-derogatory from any perspective |
| 2024-08-09 00:25:34 +0200 | <monochrom> | Accusing other people of "watering down" is a power trip, but so is accusing other people of "elitist", generally accusing anything at all. |
| 2024-08-09 00:26:06 +0200 | <monochrom> | Generally accusing other people of "being different from me". |
| 2024-08-09 00:26:19 +0200 | halloy5409 | (~halloy540@147.235.212.157) (Remote host closed the connection) |
| 2024-08-09 00:26:33 +0200 | AlexNoo | (~AlexNoo@94.233.241.125) (Ping timeout: 252 seconds) |
| 2024-08-09 00:26:46 +0200 | AlexZenon | (~alzenon@94.233.241.125) (Ping timeout: 272 seconds) |
| 2024-08-09 00:27:42 +0200 | <EvanR> | let code do the talking xD |
| 2024-08-09 00:27:54 +0200 | <EvanR> | WildlyPopularProfitableMMO here we go |
| 2024-08-09 00:28:14 +0200 | <EvanR> | it will be called Elite: Dangerist |
| 2024-08-09 00:30:08 +0200 | <Rembane> | I first thought WildlyPopularProfitableMMO was a language extension... took me a while to realize that it's not. |
| 2024-08-09 00:30:35 +0200 | <zzz> | i wonder if APL-type languages have arguments about which symbol makes more sense for a given function |
| 2024-08-09 00:30:51 +0200 | <Rembane> | zzz: IIRC they do |
| 2024-08-09 00:30:56 +0200 | <EvanR> | it's a type synonym for an outlandishly detailed dependent type for elon's AI to solve for |
| 2024-08-09 00:31:01 +0200 | <Rembane> | zzz: It's a selling point |
| 2024-08-09 00:31:19 +0200 | <zzz> | i'm not surprised at all :D |
| 2024-08-09 00:31:27 +0200 | <Rembane> | EvanR: But does it do Blockchain? |
| 2024-08-09 00:32:28 +0200 | <EvanR> | but is it webscale? but will it blend? |
| 2024-08-09 00:32:51 +0200 | <Rembane> | And how well does it do microservices? |
| 2024-08-09 00:33:05 +0200 | <EvanR> | vom |
| 2024-08-09 00:33:24 +0200 | ystael | (~ystael@user/ystael) (Ping timeout: 276 seconds) |
| 2024-08-09 00:33:28 +0200 | zetef | (~quassel@2a02:2f00:5202:1200:3fa2:e908:b522:fa2f) |
| 2024-08-09 00:33:44 +0200 | zetef | (~quassel@2a02:2f00:5202:1200:3fa2:e908:b522:fa2f) (Client Quit) |
| 2024-08-09 00:34:04 +0200 | <Rembane> | Can almost quit from vom |
| 2024-08-09 00:34:04 +0200 | AlexZenon | (~alzenon@94.233.240.239) |
| 2024-08-09 00:37:33 +0200 | infinity0 | (~infinity0@pwned.gg) (Ping timeout: 252 seconds) |
| 2024-08-09 00:38:41 +0200 | <zzz> | elite and niche are different concepts imo, i'm not sure which one would apply better here |
| 2024-08-09 00:39:54 +0200 | <EvanR> | elite is effective and useful while niche isn't? xD |
| 2024-08-09 00:41:55 +0200 | <zzz> | what would be effecrive and useful i suspect is content-addressable code |
| 2024-08-09 00:42:08 +0200 | <zzz> | like in Unison |
| 2024-08-09 00:42:12 +0200 | <Rembane> | Elite content-addressable code! |
| 2024-08-09 00:42:39 +0200 | <EvanR> | Elite: Content-Addressable |
| 2024-08-09 00:42:51 +0200 | <Rembane> | Good DLC that one |
| 2024-08-09 00:45:33 +0200 | <zzz> | anyways, thank you for making me understand Foldable better |
| 2024-08-09 00:50:12 +0200 | <raehik> | I have a `Text -> m ByteString` parser where I know the maximum length the result can be from the length of the Text. I could use the `createUpToN` bytestring primitives to only allocate once. however, one could write "malicious" inputs that have a long max length, but a short parsed length |
| 2024-08-09 00:51:04 +0200 | <raehik> | is this sort of thing still a good idea? I'm never quite sure. I can always do a regular growing buffer which is likely hardly worse performance |
| 2024-08-09 00:52:03 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) (Ping timeout: 245 seconds) |
| 2024-08-09 00:56:21 +0200 | <raehik> | (also, what's the word compsci ppl use for "malicious" there, worst-case inputs? begins with P I swear) |
| 2024-08-09 00:56:35 +0200 | <c_wraith> | pathological |
| 2024-08-09 00:56:42 +0200 | <raehik> | c_wraith: ahhhh yes thanks :) |
| 2024-08-09 00:56:47 +0200 | <raehik> | knew it was medical |
| 2024-08-09 00:58:07 +0200 | <EvanR> | is the final ByteString built up from chunks? produce a list of chunks then join it all |
| 2024-08-09 00:58:25 +0200 | <EvanR> | or better yet, produce a lazy bytestring from it |
| 2024-08-09 00:58:34 +0200 | infinity0 | (~infinity0@pwned.gg) |
| 2024-08-09 00:59:33 +0200 | <raehik> | ah I tend to only think in terms of strict bytestrings |
| 2024-08-09 01:00:27 +0200 | <EvanR> | or just work with the list of smaller strict ByteStrings which is effectively the same thing |
| 2024-08-09 01:01:07 +0200 | <EvanR> | depends what you will do with it |
| 2024-08-09 01:01:08 +0200 | <raehik> | how would I chunk in this situation? or are you suggesting not to do the `createUpToN` idea |
| 2024-08-09 01:01:31 +0200 | <raehik> | the output will be written directly to memory or disk somewhere |
| 2024-08-09 01:01:43 +0200 | <raehik> | (if used) |
| 2024-08-09 01:01:48 +0200 | <EvanR> | are you proposing to allocate N then mutate the bytes later? |
| 2024-08-09 01:01:54 +0200 | <EvanR> | I'd avoid that |
| 2024-08-09 01:01:59 +0200 | <raehik> | https://hackage.haskell.org/package/bytestring-0.12.1.0/docs/Data-ByteString-Internal.html#v:creat… |
| 2024-08-09 01:02:14 +0200 | <EvanR> | IO :( |
| 2024-08-09 01:02:32 +0200 | <raehik> | not sure what's wrong with that |
| 2024-08-09 01:02:45 +0200 | <EvanR> | well then your parser needs IO |
| 2024-08-09 01:03:02 +0200 | <raehik> | I have a library that hides all this haha https://hackage.haskell.org/package/bytezap |
| 2024-08-09 01:03:10 +0200 | <EvanR> | you kind of can't hide IO |
| 2024-08-09 01:03:33 +0200 | <EvanR> | ok, unsafePerformIO ... which is getting fishy fast |
| 2024-08-09 01:04:36 +0200 | <raehik> | bytestring provides unsafeCreateUptoN as well which handles the IO unwrapping for us |
| 2024-08-09 01:04:43 +0200 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2024-08-09 01:04:58 +0200 | <raehik> | this is how most low-level bytestring manipulation is performed |
| 2024-08-09 01:06:11 +0200 | <EvanR> | ok but why do you want to do it xD |
| 2024-08-09 01:06:41 +0200 | <EvanR> | don't you like your programs to not segfault |
| 2024-08-09 01:07:09 +0200 | <EvanR> | with zero explanation of when or why |
| 2024-08-09 01:07:21 +0200 | <raehik> | my original point was that `createUptoN` lets me do a single allocation for all inputs without having to grow a buffer or do other stuff, which is fast |
| 2024-08-09 01:07:43 +0200 | <EvanR> | my suggestion didn't involve an IO based growing buffer or mutators |
| 2024-08-09 01:07:44 +0200 | <raehik> | but you can pass pathological inputs which could waste lots of memory |
| 2024-08-09 01:08:07 +0200 | <raehik> | oh sorry I don't think I understood properly then |
| 2024-08-09 01:08:30 +0200 | <EvanR> | a follow up was if your output is based on many small bytestring chunks logically glued together |
| 2024-08-09 01:08:45 +0200 | <EvanR> | or more complicated than that |
| 2024-08-09 01:09:17 +0200 | <raehik> | no the output is used as-is, not plugged together to more bytestrings |
| 2024-08-09 01:09:50 +0200 | <EvanR> | no... |
| 2024-08-09 01:12:05 +0200 | <raehik> | do you mean can the output be chunked conveniently during parsing? It can with a bit of bookkeeping |
| 2024-08-09 01:12:49 +0200 | <raehik> | but the single ByteString output isn't manipulated afterwards |
| 2024-08-09 01:12:54 +0200 | <EvanR> | I was wondering if you generate the output as simple chunks one after the other, not if you will later concat the output onto something else |
| 2024-08-09 01:13:07 +0200 | brettgilio | (~brettgili@154.3.237.18) (Quit: The Lounge - https://thelounge.chat) |
| 2024-08-09 01:13:10 +0200 | <EvanR> | generate vs consume |
| 2024-08-09 01:13:36 +0200 | <raehik> | ah no assume it's not being used in a chunking context |
| 2024-08-09 01:13:49 +0200 | <EvanR> | that... is not what |
| 2024-08-09 01:14:10 +0200 | <EvanR> | not asking about how you consume it |
| 2024-08-09 01:14:45 +0200 | <raehik> | I assumed you asked if the parsing is called sequentially on a large input, chunking as required |
| 2024-08-09 01:14:59 +0200 | rvalue- | (~rvalue@user/rvalue) |
| 2024-08-09 01:15:05 +0200 | <raehik> | it isn't. was that not what you were asking |
| 2024-08-09 01:15:19 +0200 | <raehik> | (sry for the misunderstandings) |
| 2024-08-09 01:15:20 +0200 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 252 seconds) |
| 2024-08-09 01:16:52 +0200 | <EvanR> | nope not talking about consume input either |
| 2024-08-09 01:17:05 +0200 | <EvanR> | or consuming anything at all, oh well! |
| 2024-08-09 01:19:00 +0200 | rvalue- | rvalue |
| 2024-08-09 01:19:00 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-08-09 01:19:27 +0200 | <probie> | zzz: I've not seen many arguments in the APL community around the choice of symbols. The only one that comes to mind is that from time to time, people suggest replacing `/` for either reduce or replicate |
| 2024-08-09 01:19:29 +0200 | <raehik> | I'm sorry I haven't understood your questions properly. I'd like to think it's the text medium's fault rather than either of ours |
| 2024-08-09 01:24:13 +0200 | pavonia | (~user@user/siracusa) |
| 2024-08-09 01:32:51 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-08-09 01:51:04 +0200 | acidjnk_new3 | (~acidjnk@p200300d6e72cfb069cd6142dbab03153.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2024-08-09 01:53:11 +0200 | <zzz> | probie: oh no |
| 2024-08-09 01:53:27 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-08-09 01:54:44 +0200 | zzz | zero |
| 2024-08-09 01:58:43 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 245 seconds) |
| 2024-08-09 02:01:56 +0200 | nunggu | (~q@user/nunggu) (Ping timeout: 260 seconds) |
| 2024-08-09 02:07:50 +0200 | xff0x | (~xff0x@2405:6580:b080:900:465e:7eef:8460:d9d2) (Quit: xff0x) |
| 2024-08-09 02:13:33 +0200 | spew | (~spew@201.141.102.132) |
| 2024-08-09 02:16:55 +0200 | g00gler | (uid125351@id-125351.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-08-09 02:39:50 +0200 | <probie> | zzz: That's also not really an argument over names though. It's about not wanting to have something which is a monadic operator (for those unfamiliar with APL, that has nothing to do with monads) and a dyadic function |
| 2024-08-09 02:45:33 +0200 | <zero> | probie: aren't all APL symbols monadic and dyadic depending on context? |
| 2024-08-09 02:47:45 +0200 | <zero> | wait what do you mean by operator vs function? |
| 2024-08-09 02:47:52 +0200 | <Axman6> | raehik: Where does the "etc" come from in your second example on https://github.com/raehik/symparsec?tab=readme-ov-file? |
| 2024-08-09 02:48:53 +0200 | <Axman6> | Also that package is so tempting... but I know I would only do horrible, awful things with it |
| 2024-08-09 02:49:03 +0200 | <probie> | zero: A monadic operator is written to the right of its its argument, whilst a monadic function goes to the left of it |
| 2024-08-09 02:49:20 +0200 | <zero> | probie: oh i see |
| 2024-08-09 02:51:05 +0200 | <zero> | i like J syntax |
| 2024-08-09 02:51:45 +0200 | <zero> | they ironed out much of the creases |
| 2024-08-09 02:51:56 +0200 | <probie> | most (but not all) operators take functions as arguments, but there are some (like `⍨`) which is an operator that can take data. Most APLs treat functions and data separately |
| 2024-08-09 02:52:51 +0200 | <raehik> | Axman6: oops that's a typo from rewriting. it's meant to be "" |
| 2024-08-09 02:54:29 +0200 | <probie> | The "APL" I think has the best syntax is BQN (also, BQN will let you have arrays of functions, which is something most APLs don't) |
| 2024-08-09 02:54:30 +0200 | <raehik> | I still think symparsec is excellent for making generics even safer. like I straight up promoted a runtime check to compile time in a lib of mine |
| 2024-08-09 02:54:42 +0200 | <Axman6> | Great, I thought so. I can make a PR if you like =) (I actually thing making the input "xFF_etc" is better here) |
| 2024-08-09 02:56:45 +0200 | <raehik> | I just pushed the fix sorry to steal your PR chance xd |
| 2024-08-09 02:57:02 +0200 | <Axman6> | D: |
| 2024-08-09 02:57:05 +0200 | <Axman6> | Rude |
| 2024-08-09 02:57:12 +0200 | <raehik> | good call, I considered that and made another change to have a suffix instead of empty |
| 2024-08-09 02:58:23 +0200 | <Axman6> | Also the next example doesn't make sense any more right? |
| 2024-08-09 02:58:39 +0200 | <Axman6> | oh it doesew |
| 2024-08-09 02:59:15 +0200 | <raehik> | I don't explain the return kind shape so it's not completely clear |
| 2024-08-09 02:59:17 +0200 | <Axman6> | How hard would a JSON parser be? I don't want this, but I would love to see it |
| 2024-08-09 03:00:18 +0200 | <Axman6> | Also, is Literal necessary? Could you just have Symbols? |
| 2024-08-09 03:00:43 +0200 | <raehik> | the current problem with symparsec is the minimal parser choice functionality (no backtracking, only certain choice "types" permitted) |
| 2024-08-09 03:01:07 +0200 | <raehik> | and probably no mutually recursive parsers (I can't figure them out) |
| 2024-08-09 03:01:47 +0200 | <Axman6> | I can't see any reason why recursive types could ever cause any problems =) |
| 2024-08-09 03:02:25 +0200 | <raehik> | I'm not sure the Or parser would work with a complex schema like JSON (I don't think so) |
| 2024-08-09 03:02:48 +0200 | <raehik> | regarding Literal: we need it for the bookkeeping |
| 2024-08-09 03:03:42 +0200 | <raehik> | you can't connect a `sym :: Symbol` together with another type-level parser because of how parser sequencing works |
| 2024-08-09 03:05:09 +0200 | <Axman6> | Fair enough |
| 2024-08-09 03:08:22 +0200 | <raehik> | symparsec is kind of designed for simple parsers and to be simple itself. I think if you were clever you could put backtracking directly in the parser runner |
| 2024-08-09 03:09:01 +0200 | <raehik> | but it would be scary and rolling my own singletons was enough for me to pause the project for now! :) |
| 2024-08-09 03:09:55 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) |
| 2024-08-09 03:11:26 +0200 | TonyStone | (~TonyStone@user/TonyStone) (Remote host closed the connection) |
| 2024-08-09 03:12:42 +0200 | spew | (~spew@201.141.102.132) (Read error: Connection reset by peer) |
| 2024-08-09 03:13:00 +0200 | ticat | (~ticat@156.251.248.134) |
| 2024-08-09 03:22:14 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-08-09 03:26:59 +0200 | ticat | (~ticat@156.251.248.134) (Quit: Client closed) |
| 2024-08-09 03:43:27 +0200 | ZharMeny | (~user@user/ZharMeny) (Quit: No Space Left on Device) |
| 2024-08-09 03:45:58 +0200 | bilegeek | (~bilegeek@2600:1008:b047:89f7:6723:6fe8:c1e7:6c2d) |
| 2024-08-09 03:46:24 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-08-09 03:49:37 +0200 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) (Quit: Lost terminal) |
| 2024-08-09 03:54:22 +0200 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) |
| 2024-08-09 03:57:16 +0200 | starburst | (~starburst@2601:602:480:9390::707d) |
| 2024-08-09 03:57:18 +0200 | <starburst> | ayaya |
| 2024-08-09 03:58:45 +0200 | dolio | (~dolio@130.44.140.168) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-08-09 04:00:16 +0200 | dolio | (~dolio@130.44.140.168) |
| 2024-08-09 04:00:24 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
| 2024-08-09 04:03:57 +0200 | dolio | (~dolio@130.44.140.168) (Client Quit) |
| 2024-08-09 04:07:11 +0200 | dolio | (~dolio@130.44.140.168) |
| 2024-08-09 04:08:45 +0200 | nadja | (~dequbed@banana-new.kilobyte22.de) (Ping timeout: 252 seconds) |
| 2024-08-09 04:09:15 +0200 | nadja | (~dequbed@banana-new.kilobyte22.de) |
| 2024-08-09 04:19:22 +0200 | <albet70> | whats the functions name to let [1..9] [11..19] [21..29] ... to be [[1,11,21..], [2,12,22..]...]? |
| 2024-08-09 04:19:54 +0200 | <albet70> | zip? |
| 2024-08-09 04:20:21 +0200 | <albet70> | or just use list comprehension? |
| 2024-08-09 04:21:28 +0200 | starburst | (~starburst@2601:602:480:9390::707d) (Quit: Client closed) |
| 2024-08-09 04:26:02 +0200 | <mauke> | > transpose [[1..9], [11..19], [21..29]] |
| 2024-08-09 04:26:04 +0200 | <lambdabot> | [[1,11,21],[2,12,22],[3,13,23],[4,14,24],[5,15,25],[6,16,26],[7,17,27],[8,18... |
| 2024-08-09 04:26:27 +0200 | <mauke> | zipN = transpose |
| 2024-08-09 04:27:27 +0200 | <edwardk> | :t Data.List.transpose |
| 2024-08-09 04:27:28 +0200 | <lambdabot> | [[a]] -> [[a]] |
| 2024-08-09 04:27:39 +0200 | <edwardk> | that's your friend here |
| 2024-08-09 04:29:09 +0200 | td_ | (~td@i53870904.versanet.de) (Ping timeout: 248 seconds) |
| 2024-08-09 04:30:47 +0200 | td_ | (~td@i53870929.versanet.de) |
| 2024-08-09 04:32:54 +0200 | <edwardk> | raehik: what is driving you to symparsec? |
| 2024-08-09 04:32:54 +0200 | <albet70> | thanks :) |
| 2024-08-09 04:33:29 +0200 | <edwardk> | raehik: e.g. does it _actually_ have to map from Symbol -> Type? or would using an actual parsing combinator library at compile time via template haskell be easier for what you want to do? |
| 2024-08-09 04:34:07 +0200 | <edwardk> | usually i go quasi-quote -> edsl, build what i want, and then generate haskell rather than go into singleton typing hell |
| 2024-08-09 04:35:50 +0200 | <raehik> | edwardk: I was writing some generics that want to operate on field names |
| 2024-08-09 04:36:04 +0200 | <edwardk> | er wait, you're writing this library, not using this library. misparsed |
| 2024-08-09 04:36:14 +0200 | <raehik> | I am also using the library :) |
| 2024-08-09 04:36:21 +0200 | <edwardk> | hah |
| 2024-08-09 04:36:44 +0200 | <raehik> | the singletons aren't necessary at all but once I figured they were possible, I wanted to have a go |
| 2024-08-09 04:37:04 +0200 | <edwardk> | ok, so that leaves you with much less palatable fallbacks. e.g. custom plugin to generate instances that do what you want |
| 2024-08-09 04:38:42 +0200 | <raehik> | I did manage to do what I want with symparsec |
| 2024-08-09 04:39:30 +0200 | <raehik> | It suffers from poor ergonomics but it all works and in Haskell land. (I don't know how to do TH or GHC plugins) |
| 2024-08-09 04:39:32 +0200 | <raehik> | https://hackage.haskell.org/package/generic-data-functions-0.6.0/docs/Generic-Data-Function-FoldMa… |
| 2024-08-09 04:39:40 +0200 | <edwardk> | general purpose recursion is probably the sort of thing that would need you to build a letrec equivalent and/or extend an environment of parsers |
| 2024-08-09 04:42:52 +0200 | <raehik> | kinda waiting for someone to take a look at symparsec and be like "oh you can do much better in like 50 lines" :D |
| 2024-08-09 04:43:19 +0200 | <raehik> | just like I did with csongor's symbol library (which was made before we could deconstruct Symbols) |
| 2024-08-09 04:44:09 +0200 | <raehik> | (oops I mean symbols library) |
| 2024-08-09 04:46:23 +0200 | <edwardk> | hah |
| 2024-08-09 04:46:42 +0200 | ell | (~ellie@user/ellie) (Quit: Leaving) |
| 2024-08-09 04:46:57 +0200 | <edwardk> | i mean, you could use my variant on singletons maybe. https://github.com/ekmett/haskell/tree/master/types |
| 2024-08-09 04:47:31 +0200 | <edwardk> | that transforms symbols into very introspectable things by making them equivalent to type level strings |
| 2024-08-09 04:47:35 +0200 | ell | (~ellie@user/ellie) |
| 2024-08-09 04:47:52 +0200 | <edwardk> | as in lists of type level chars |
| 2024-08-09 04:51:04 +0200 | <raehik> | I wrote my own explicit singletons that doesn't hide kind in a Sing type family (because it was hard to troubleshoot what I was doing wrong) instead https://hackage.haskell.org/package/singleraeh |
| 2024-08-09 04:53:10 +0200 | <raehik> | I wondered if there was another way to design a type-level parser lib that doesn't require writing the same thing twice for type and term level... but my approach is easiest for type-level hijinks and that's what I wanted most |
| 2024-08-09 04:54:43 +0200 | <edwardk> | fair nuff |
| 2024-08-09 04:55:07 +0200 | <edwardk> | mostly i just abuse reflection and little scoping tricks to fabricate the types i need with the instances i need |
| 2024-08-09 04:56:04 +0200 | <edwardk> | that's generally been enough for me to generate code that depends on terms that needs to manifest as types by bringing into scope reflection'ed dictionaries and unsafeCoerced type equalities |
| 2024-08-09 04:56:25 +0200 | <edwardk> | but i am willing to cheat my butt off to get around haskell's non-dependently typed nature |
| 2024-08-09 04:57:36 +0200 | <raehik> | I have read the reflection lib docs enough to know that about you haha :) |
| 2024-08-09 05:11:50 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 255 seconds) |
| 2024-08-09 05:12:45 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2024-08-09 05:16:28 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-08-09 05:22:42 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2024-08-09 05:36:30 +0200 | <edwardk> | hahahahha |
| 2024-08-09 05:47:30 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-08-09 05:49:23 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-08-09 06:01:18 +0200 | aforemny | (~aforemny@2001:9e8:6ccc:fd00:728:dd11:4e8c:d31a) |
| 2024-08-09 06:02:52 +0200 | aforemny_ | (~aforemny@2001:9e8:6cec:9200:56df:dd94:8882:31ea) (Ping timeout: 265 seconds) |
| 2024-08-09 06:02:56 +0200 | kupi | (uid212005@id-212005.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-08-09 06:29:32 +0200 | RedFlamingos | (~RedFlamin@user/RedFlamingos) (Quit: RedFlamingos) |
| 2024-08-09 06:40:44 +0200 | thailigur | (~thailigur@172.86.68.44) |
| 2024-08-09 06:42:14 +0200 | thailigur | (~thailigur@172.86.68.44) (Remote host closed the connection) |
| 2024-08-09 06:42:29 +0200 | thailigur | (~thailigur@5.211.73.48) |
| 2024-08-09 07:02:29 +0200 | monochrom | (trebla@216.138.220.146) (Quit: ZNC 1.9.0+deb2build3 - https://znc.in) |
| 2024-08-09 07:03:42 +0200 | tabaqui | (~root@87.200.123.114) (Quit: WeeChat 4.3.5) |
| 2024-08-09 07:05:57 +0200 | RedFlamingos | (~RedFlamin@user/RedFlamingos) |
| 2024-08-09 07:08:57 +0200 | monochrom | (trebla@216.138.220.146) |
| 2024-08-09 07:11:32 +0200 | itaipu | (~itaipu@168.121.98.135) (Ping timeout: 255 seconds) |
| 2024-08-09 07:30:05 +0200 | Sgeo_ | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-08-09 07:34:22 +0200 | michalz | (~michalz@185.246.207.193) |
| 2024-08-09 07:34:27 +0200 | bilegeek | (~bilegeek@2600:1008:b047:89f7:6723:6fe8:c1e7:6c2d) (Quit: Leaving) |
| 2024-08-09 07:35:03 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 244 seconds) |
| 2024-08-09 07:35:11 +0200 | thailigur | (~thailigur@5.211.73.48) (Ping timeout: 252 seconds) |
| 2024-08-09 07:36:02 +0200 | thailigur | (~thailigur@31.2.130.189) |
| 2024-08-09 07:36:08 +0200 | euleritian | (~euleritia@dynamic-176-006-128-242.176.6.pool.telefonica.de) |
| 2024-08-09 07:49:49 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2024-08-09 07:50:15 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2024-08-09 07:57:54 +0200 | danse-nr3 | (~danse-nr3@user/danse-nr3) |
| 2024-08-09 08:02:37 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Quit: xff0x) |
| 2024-08-09 08:12:39 +0200 | sawilagar | (~sawilagar@user/sawilagar) |
| 2024-08-09 08:14:53 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-08-09 08:17:43 +0200 | jinsun | Guest876 |
| 2024-08-09 08:17:43 +0200 | jinsun_ | (~jinsun@user/jinsun) |
| 2024-08-09 08:17:43 +0200 | Guest876 | (~jinsun@user/jinsun) (Killed (molybdenum.libera.chat (Nickname regained by services))) |
| 2024-08-09 08:17:43 +0200 | jinsun_ | jinsun |
| 2024-08-09 08:21:09 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-08-09 08:21:54 +0200 | ft | (~ft@p4fc2aa15.dip0.t-ipconnect.de) (Quit: leaving) |
| 2024-08-09 08:22:55 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 264 seconds) |
| 2024-08-09 08:22:56 +0200 | echoreply | (~echoreply@45.32.163.16) (Quit: WeeChat 2.8) |
| 2024-08-09 08:24:17 +0200 | echoreply | (~echoreply@45.32.163.16) |
| 2024-08-09 08:25:16 +0200 | Digitteknohippie | (~user@user/digit) |
| 2024-08-09 08:25:48 +0200 | Digit | (~user@user/digit) (Ping timeout: 245 seconds) |
| 2024-08-09 08:27:41 +0200 | euleritian | (~euleritia@dynamic-176-006-128-242.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-08-09 08:27:59 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-08-09 08:29:23 +0200 | CiaoSen | (~Jura@2a05:5800:2da:c00:e6b9:7aff:fe80:3d03) |
| 2024-08-09 08:35:25 +0200 | rosco | (~rosco@175.136.158.234) |
| 2024-08-09 08:38:30 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3317-c12e-59ca-c9f6-a2c0-ca17.rev.sfr.net) |
| 2024-08-09 08:42:19 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) |
| 2024-08-09 08:49:19 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2024-08-09 09:05:13 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2024-08-09 09:06:24 +0200 | acidjnk_new3 | (~acidjnk@p200300d6e72cfb71e8c7be36caf04b72.dip0.t-ipconnect.de) |
| 2024-08-09 09:13:24 +0200 | FragByte | (~christian@user/fragbyte) |
| 2024-08-09 09:14:51 +0200 | thailigur | (~thailigur@31.2.130.189) (Ping timeout: 252 seconds) |
| 2024-08-09 09:15:03 +0200 | thailigur | (~thailigur@5.211.226.57) |
| 2024-08-09 09:15:25 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 4.2.2) |
| 2024-08-09 09:17:15 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3317-c12e-59ca-c9f6-a2c0-ca17.rev.sfr.net) (Remote host closed the connection) |
| 2024-08-09 09:17:37 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3317-c12e-7182-1a68-9319-87e9.rev.sfr.net) |
| 2024-08-09 09:20:36 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2024-08-09 09:20:55 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3317-c12e-7182-1a68-9319-87e9.rev.sfr.net) (Remote host closed the connection) |
| 2024-08-09 09:21:49 +0200 | thailigur | (~thailigur@5.211.226.57) (Read error: Connection reset by peer) |
| 2024-08-09 09:22:30 +0200 | thailigur | (~thailigur@151.240.87.209) |
| 2024-08-09 09:24:40 +0200 | kuribas | (~user@2a02:1810:2825:6000:22f5:5d2b:a63a:1884) |
| 2024-08-09 09:26:18 +0200 | vpan | (~vpan@212.117.1.172) |
| 2024-08-09 09:26:36 +0200 | vpan | Guest6458 |
| 2024-08-09 09:27:27 +0200 | Guest6458 | vpan |
| 2024-08-09 09:32:11 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 4.2.2) |
| 2024-08-09 09:47:46 +0200 | thailigur | (~thailigur@151.240.87.209) (Read error: Connection reset by peer) |
| 2024-08-09 09:48:03 +0200 | thailigur | (~thailigur@172.86.68.44) |
| 2024-08-09 09:55:25 +0200 | Digitteknohippie | Digit |
| 2024-08-09 09:58:09 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-08-09 10:00:31 +0200 | thailigur | (~thailigur@172.86.68.44) (Remote host closed the connection) |
| 2024-08-09 10:00:57 +0200 | thailigur | (~thailigur@172.86.68.44) |
| 2024-08-09 10:01:49 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2024-08-09 10:02:14 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2024-08-09 10:03:38 +0200 | danse-nr3 | (~danse-nr3@user/danse-nr3) (Quit: on the move) |
| 2024-08-09 10:05:31 +0200 | thailigur | (~thailigur@172.86.68.44) (Ping timeout: 264 seconds) |
| 2024-08-09 10:06:08 +0200 | thailigur | (~thailigur@172.86.68.44) |
| 2024-08-09 10:11:41 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
| 2024-08-09 10:13:19 +0200 | thailigur | (~thailigur@172.86.68.44) (Ping timeout: 264 seconds) |
| 2024-08-09 10:14:33 +0200 | thailigur | (~thailigur@172.86.68.44) |
| 2024-08-09 10:15:44 +0200 | danse-nr3 | (~danse-nr3@user/danse-nr3) |
| 2024-08-09 10:18:44 +0200 | thailigur | (~thailigur@172.86.68.44) (Ping timeout: 252 seconds) |
| 2024-08-09 10:19:08 +0200 | thailigur | (~thailigur@172.86.68.44) |
| 2024-08-09 10:26:45 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-08-09 10:31:34 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-08-09 10:38:23 +0200 | abyxq | (~abyxq@user/abyxq) |
| 2024-08-09 10:52:22 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-08-09 10:52:47 +0200 | ubert | (~Thunderbi@178.165.184.113.wireless.dyn.drei.com) |
| 2024-08-09 10:56:45 +0200 | Inst | (~Inst@user/Inst) (Read error: Connection reset by peer) |
| 2024-08-09 10:57:45 +0200 | thailigur | (~thailigur@172.86.68.44) (Quit: Quit) |
| 2024-08-09 10:58:51 +0200 | danse-nr3 | (~danse-nr3@user/danse-nr3) (Quit: oops) |
| 2024-08-09 11:01:00 +0200 | Inst | (~Inst@user/Inst) |
| 2024-08-09 11:03:19 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2024-08-09 11:03:52 +0200 | gehmehgeh | gmg |
| 2024-08-09 11:11:31 +0200 | abyxq | (~abyxq@user/abyxq) (Ping timeout: 252 seconds) |
| 2024-08-09 11:12:32 +0200 | abyxq | (~abyxq@185.238.219.55) |
| 2024-08-09 11:14:19 +0200 | falafel | (~falafel@2a0c:5a87:3104:4c01::aa34) |
| 2024-08-09 11:14:21 +0200 | cpressey | (~weechat@176.254.71.203) |
| 2024-08-09 11:15:20 +0200 | abyxq | (~abyxq@185.238.219.55) (Changing host) |
| 2024-08-09 11:15:20 +0200 | abyxq | (~abyxq@user/abyxq) |
| 2024-08-09 11:22:48 +0200 | danse-nr3 | (~danse-nr3@user/danse-nr3) |
| 2024-08-09 11:26:34 +0200 | monochrom | (trebla@216.138.220.146) (Ping timeout: 252 seconds) |
| 2024-08-09 11:26:36 +0200 | monochrm | (trebla@216.138.220.146) |
| 2024-08-09 11:27:01 +0200 | monochrm | monochrom |
| 2024-08-09 11:31:11 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2024-08-09 11:36:51 +0200 | falafel | (~falafel@2a0c:5a87:3104:4c01::aa34) (Ping timeout: 265 seconds) |
| 2024-08-09 11:37:31 +0200 | tcard_ | (~tcard@2400:4051:5801:7500:1e90:74c3:2754:ce8a) (Quit: Leaving) |
| 2024-08-09 11:45:00 +0200 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2024-08-09 11:45:16 +0200 | tcard | (~tcard@2400:4051:5801:7500:1e90:74c3:2754:ce8a) |
| 2024-08-09 11:45:35 +0200 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) |
| 2024-08-09 11:47:03 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 4.2.2) |
| 2024-08-09 11:48:28 +0200 | dans37269 | (~danse-nr3@user/danse-nr3) |
| 2024-08-09 11:49:30 +0200 | thyriaen | (~thyriaen@2001:4bc9:1fb8:12d1:6245:cbff:fe9f:48b1) |
| 2024-08-09 11:50:34 +0200 | danse-nr3 | (~danse-nr3@user/danse-nr3) (Ping timeout: 260 seconds) |
| 2024-08-09 11:53:32 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-08-09 11:57:45 +0200 | driib3 | (~driib@vmi931078.contaboserver.net) (Quit: The Lounge - https://thelounge.chat) |
| 2024-08-09 11:58:23 +0200 | driib3 | (~driib@vmi931078.contaboserver.net) |
| 2024-08-09 12:04:30 +0200 | sp1ff | (~user@c-73-11-70-111.hsd1.wa.comcast.net) (Remote host closed the connection) |
| 2024-08-09 12:04:55 +0200 | CiaoSen | (~Jura@2a05:5800:2da:c00:e6b9:7aff:fe80:3d03) (Ping timeout: 264 seconds) |
| 2024-08-09 12:05:05 +0200 | thyriaen | (~thyriaen@2001:4bc9:1fb8:12d1:6245:cbff:fe9f:48b1) (Remote host closed the connection) |
| 2024-08-09 12:08:49 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 248 seconds) |
| 2024-08-09 12:11:08 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2024-08-09 12:12:42 +0200 | vpan | (~vpan@212.117.1.172) (Quit: Leaving.) |
| 2024-08-09 12:12:48 +0200 | Digit | (~user@user/digit) (Ping timeout: 276 seconds) |
| 2024-08-09 12:15:22 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2024-08-09 12:27:47 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.2.2) |
| 2024-08-09 12:39:19 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-08-09 12:41:09 +0200 | zero | (~z@user/zero) (Quit: quit) |
| 2024-08-09 12:42:32 +0200 | zero | (~z@user/zero) |
| 2024-08-09 12:46:50 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3317-c12e-1d26-3004-5564-597a.rev.sfr.net) |
| 2024-08-09 12:49:19 +0200 | Digit | (~user@179.67.90.146.dyn.plus.net) |
| 2024-08-09 12:49:35 +0200 | falafel | (~falafel@2a0c:5a87:3104:4c01::aa34) |
| 2024-08-09 12:54:58 +0200 | Digitteknohippie | (~user@179.67.90.146.dyn.plus.net) |
| 2024-08-09 12:57:08 +0200 | Digit | (~user@179.67.90.146.dyn.plus.net) (Ping timeout: 255 seconds) |
| 2024-08-09 12:58:32 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2024-08-09 13:09:31 +0200 | Digitteknohippie | (~user@179.67.90.146.dyn.plus.net) (Changing host) |
| 2024-08-09 13:09:31 +0200 | Digitteknohippie | (~user@user/digit) |
| 2024-08-09 13:09:55 +0200 | Digitteknohippie | Digit |
| 2024-08-09 13:11:18 +0200 | abyxq | (~abyxq@user/abyxq) (Ping timeout: 276 seconds) |
| 2024-08-09 13:13:06 +0200 | abyxq | (~abyxq@user/abyxq) |
| 2024-08-09 13:21:20 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3317-c12e-1d26-3004-5564-597a.rev.sfr.net) (Remote host closed the connection) |
| 2024-08-09 13:31:44 +0200 | CiaoSen | (~Jura@2a05:5800:2da:c00:e6b9:7aff:fe80:3d03) |
| 2024-08-09 13:46:21 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3317-c12e-6155-3ef4-109a-60a1.rev.sfr.net) |
| 2024-08-09 13:51:26 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-08-09 13:53:46 +0200 | falafel | (~falafel@2a0c:5a87:3104:4c01::aa34) (Ping timeout: 244 seconds) |
| 2024-08-09 14:02:07 +0200 | Unhammer | (~Unhammer@user/unhammer) (WeeChat 2.3) |
| 2024-08-09 14:05:50 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-08-09 14:06:12 +0200 | cpressey | (~weechat@176.254.71.203) (Ping timeout: 265 seconds) |
| 2024-08-09 14:15:27 +0200 | dans37269 | (~danse-nr3@user/danse-nr3) (Quit: meal) |
| 2024-08-09 14:15:54 +0200 | jvml | (~user@172.56.70.56) |
| 2024-08-09 14:19:16 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 252 seconds) |
| 2024-08-09 14:29:29 +0200 | Achylles | (~Achylles@45.182.57.106) |
| 2024-08-09 14:30:55 +0200 | abyxq | (~abyxq@user/abyxq) (Quit: leaving) |
| 2024-08-09 14:31:57 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3317-c12e-6155-3ef4-109a-60a1.rev.sfr.net) (Remote host closed the connection) |
| 2024-08-09 14:32:04 +0200 | falafel | (~falafel@2a0c:5a87:3104:4c01::aa34) |
| 2024-08-09 14:33:14 +0200 | danse-nr3 | (~danse-nr3@user/danse-nr3) |
| 2024-08-09 14:33:30 +0200 | machinedgod | (~machinedg@d50-99-47-73.abhsia.telus.net) |
| 2024-08-09 14:35:12 +0200 | krei-se | (~krei-se@p57af2d39.dip0.t-ipconnect.de) (Ping timeout: 265 seconds) |
| 2024-08-09 14:36:51 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-08-09 14:37:58 +0200 | falafel | (~falafel@2a0c:5a87:3104:4c01::aa34) (Ping timeout: 272 seconds) |
| 2024-08-09 14:39:18 +0200 | krei-se | (~krei-se@p57af2d39.dip0.t-ipconnect.de) |
| 2024-08-09 14:44:02 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-08-09 14:44:26 +0200 | Achylles | (~Achylles@45.182.57.106) (Quit: Leaving) |
| 2024-08-09 14:46:45 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) (Ping timeout: 248 seconds) |
| 2024-08-09 14:56:23 +0200 | jespada | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) (Ping timeout: 255 seconds) |
| 2024-08-09 14:58:08 +0200 | jespada | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) |
| 2024-08-09 14:59:49 +0200 | hseg | (~gesh@46.120.21.97) |
| 2024-08-09 15:05:56 +0200 | jvml | (~user@172.56.70.56) (Quit: ERC 5.4 (IRC client for GNU Emacs 28.2)) |
| 2024-08-09 15:07:19 +0200 | cpressey | (~weechat@176.254.71.203) |
| 2024-08-09 15:11:37 +0200 | cpressey | (~weechat@176.254.71.203) (Client Quit) |
| 2024-08-09 15:18:25 +0200 | abyxq | (~abyxq@user/abyxq) |
| 2024-08-09 15:22:18 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-08-09 15:26:55 +0200 | <Athas> | I have been working on some Haskell exercises: https://github.com/diku-dk/ap-e2024-pub/tree/main/week1 |
| 2024-08-09 15:27:00 +0200 | rosco | (~rosco@175.136.158.234) (Quit: Lost terminal) |
| 2024-08-09 15:27:06 +0200 | <Athas> | I think this is actually the first time I have written didactic material for Haskell. |
| 2024-08-09 15:31:14 +0200 | CiaoSen | (~Jura@2a05:5800:2da:c00:e6b9:7aff:fe80:3d03) (Ping timeout: 260 seconds) |
| 2024-08-09 15:31:45 +0200 | pointlessslippe1 | (~pointless@212.82.82.3) (Ping timeout: 265 seconds) |
| 2024-08-09 15:38:38 +0200 | pointlessslippe1 | (~pointless@212.82.82.3) |
| 2024-08-09 15:40:02 +0200 | ystael | (~ystael@user/ystael) |
| 2024-08-09 15:40:04 +0200 | <danse-nr3> | nice stuff |
| 2024-08-09 15:40:14 +0200 | <danse-nr3> | in a meeting will read better later |
| 2024-08-09 15:46:31 +0200 | pointlessslippe1 | (~pointless@212.82.82.3) (Ping timeout: 252 seconds) |
| 2024-08-09 15:48:15 +0200 | dans77453 | (~danse-nr3@user/danse-nr3) |
| 2024-08-09 15:50:09 +0200 | danse-nr3 | (~danse-nr3@user/danse-nr3) (Ping timeout: 248 seconds) |
| 2024-08-09 15:50:24 +0200 | <dans77453> | so, what's the plan about those Athas? |
| 2024-08-09 15:50:28 +0200 | <dans77453> | organized by weeks, they seem to hint at a course |
| 2024-08-09 15:50:34 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) |
| 2024-08-09 15:50:38 +0200 | <Athas> | dans77453: yes, it's a course. |
| 2024-08-09 15:51:13 +0200 | <Athas> | The didactive vision is that the students will do tutorial-style exercises (with solutions) where they write code from scratch, and then do take-home assignments where they have to add more functionality. |
| 2024-08-09 15:51:53 +0200 | <Athas> | I am trying to take a very concrete, code-oriented perspective, since my experience is that most students cannot understand the abstract principles in isolation. |
| 2024-08-09 15:53:30 +0200 | <dans77453> | maybe not for me but good initiative |
| 2024-08-09 16:01:14 +0200 | <sprout> | you should run the exercises through chatgpt :) |
| 2024-08-09 16:04:39 +0200 | <dans77453> | -.- |
| 2024-08-09 16:05:15 +0200 | pointlessslippe1 | (~pointless@212.82.82.3) |
| 2024-08-09 16:05:21 +0200 | <dans77453> | well actually, not a bad idea. Some student is definitely gonna do that |
| 2024-08-09 16:08:15 +0200 | <EvanR> | Athas, you haven't written a monad tutorial?? |
| 2024-08-09 16:10:32 +0200 | <Athas> | EvanR: I felt there were enough already. |
| 2024-08-09 16:10:38 +0200 | AlexNoo_ | AlexNoo |
| 2024-08-09 16:10:41 +0200 | <Athas> | sprout: why? They're exercises? |
| 2024-08-09 16:10:55 +0200 | zero | zzz |
| 2024-08-09 16:11:00 +0200 | <sprout> | Athas: because students are going to do that? |
| 2024-08-09 16:11:13 +0200 | <Athas> | They can also just not do the exercises. They're not mandatory. |
| 2024-08-09 16:11:16 +0200 | <Athas> | That's even easier. |
| 2024-08-09 16:11:47 +0200 | <sprout> | I would be interested anyway |
| 2024-08-09 16:11:51 +0200 | <sprout> | but ah well |
| 2024-08-09 16:12:28 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2024-08-09 16:12:47 +0200 | <EvanR> | sprout, you do it |
| 2024-08-09 16:12:53 +0200 | <sprout> | nah |
| 2024-08-09 16:12:56 +0200 | <EvanR> | lol |
| 2024-08-09 16:13:08 +0200 | <sprout> | I've got my own shitty interpreter to work on |
| 2024-08-09 16:13:27 +0200 | <EvanR> | I asked chat-gpt to make a shitty interpreter. It did |
| 2024-08-09 16:14:29 +0200 | <dans77453> | what's the interpreter about sprout? |
| 2024-08-09 16:14:47 +0200 | <sprout> | https://egel-lang.github.io/ |
| 2024-08-09 16:14:57 +0200 | <sprout> | cheap and dirty fuctional programs |
| 2024-08-09 16:15:07 +0200 | <sprout> | or small and dirty |
| 2024-08-09 16:15:20 +0200 | <dans77453> | i thought that was called javascript. But lemme peek |
| 2024-08-09 16:15:50 +0200 | <sprout> | this is the best example I have so far of what I want: https://egel.dev/self |
| 2024-08-09 16:16:07 +0200 | <sprout> | (fingers crossed that loads) |
| 2024-08-09 16:16:14 +0200 | <dans77453> | nice syntax |
| 2024-08-09 16:16:23 +0200 | <dans77453> | what's the 'import System' about? |
| 2024-08-09 16:16:27 +0200 | <sprout> | a gopher/www server in a few untidy lines |
| 2024-08-09 16:16:36 +0200 | <sprout> | dans77453: pull in the system namespace |
| 2024-08-09 16:17:01 +0200 | <sprout> | stuff like + and print |
| 2024-08-09 16:17:04 +0200 | <dans77453> | hmm pulling a namespace in a specific scope is cool |
| 2024-08-09 16:17:25 +0200 | <sprout> | it's probably overkill but for the moment I like to keep stuff clean |
| 2024-08-09 16:17:42 +0200 | <sprout> | users probably would want that namespace by default |
| 2024-08-09 16:18:18 +0200 | <sprout> | there's about a dozen lines of decorum I could cut by making it all more friendly |
| 2024-08-09 16:18:25 +0200 | <sprout> | but ah well |
| 2024-08-09 16:18:40 +0200 | <dans77453> | heh |
| 2024-08-09 16:19:48 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 276 seconds) |
| 2024-08-09 16:20:03 +0200 | euleritian | (~euleritia@dynamic-176-006-130-193.176.6.pool.telefonica.de) |
| 2024-08-09 16:24:49 +0200 | <dans77453> | some other day someone in #emacs was arguing devs like to keep bugs around in order to keep their jobs. Nonsense |
| 2024-08-09 16:25:29 +0200 | <dans77453> | for each development project there is an infinitely forking tree with infinite branches of stuff to be done |
| 2024-08-09 16:25:52 +0200 | <dans77453> | like an hydra :P |
| 2024-08-09 16:26:58 +0200 | <sprout> | it's just time management |
| 2024-08-09 16:27:21 +0200 | <sprout> | a lot of writing software or compilers boils down to: this will do for the moment |
| 2024-08-09 16:28:19 +0200 | hseg | (~gesh@46.120.21.97) (Ping timeout: 264 seconds) |
| 2024-08-09 16:28:20 +0200 | <dans77453> | of course, i've long learned minimalism, but... we all know there is so much more we would like to do |
| 2024-08-09 16:28:55 +0200 | <EvanR> | that conspiratorial thinking is so gross |
| 2024-08-09 16:31:36 +0200 | abyxq | (~abyxq@user/abyxq) (Quit: leaving) |
| 2024-08-09 16:31:38 +0200 | <dans77453> | i am more concerned about the "elitism" label to be honest |
| 2024-08-09 16:33:09 +0200 | <EvanR> | yeah wtf |
| 2024-08-09 16:33:58 +0200 | <EvanR> | we should select and promote people who are most qualified to do the job in question, but make sure they're not elite? lol |
| 2024-08-09 16:34:11 +0200 | <EvanR> | don't trust experts |
| 2024-08-09 16:35:11 +0200 | <dans77453> | you are talking meritocracy, but i saw that attached to free software devs in general, which are a chaotic crowd. Anyways, getting too offtopic i'm afraid |
| 2024-08-09 16:36:10 +0200 | <EvanR> | a common hottake against haskell is the people who know it are elitist which is bad |
| 2024-08-09 16:36:15 +0200 | BitByte | (~BitByte@2804:880:130e:5700:b184:6405:971d:7d3d) |
| 2024-08-09 16:37:53 +0200 | <zzz> | who holds that opinion? people who know haskell? |
| 2024-08-09 16:38:25 +0200 | <EvanR> | usually not xD |
| 2024-08-09 16:39:03 +0200 | <EvanR> | that would place you in your own crosshairs |
| 2024-08-09 16:39:19 +0200 | <zzz> | why should the opinion of people who don't know something count? |
| 2024-08-09 16:39:50 +0200 | <EvanR> | should not but often does anyway |
| 2024-08-09 16:39:53 +0200 | <sprout> | 'don't discuss the ignorant, people observing might not know the difference' |
| 2024-08-09 16:40:05 +0200 | <sprout> | Twain I think |
| 2024-08-09 16:40:08 +0200 | itaipu | (~itaipu@168.121.98.114) |
| 2024-08-09 16:40:36 +0200 | <dans77453> | i was trying to deepen the matter in #emacs but we didn't get too far. Someone pulled in generational divides, having "weird and uncommon" ways... i don't recall what else |
| 2024-08-09 16:40:43 +0200 | <dans77453> | good points zzz, sprout |
| 2024-08-09 16:41:14 +0200 | <EvanR> | conform to the common ways, it's safer. Use emacs! |
| 2024-08-09 16:41:27 +0200 | <dans77453> | that would be vscode actually |
| 2024-08-09 16:41:33 +0200 | <EvanR> | lol |
| 2024-08-09 16:41:44 +0200 | <zzz> | :wq! |
| 2024-08-09 16:42:12 +0200 | <dans77453> | but well, i think it matters how a community is perceived by the rest of the society |
| 2024-08-09 16:43:29 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-08-09 16:44:03 +0200 | <EvanR> | https://www.wired.com/story/inside-the-cult-of-the-haskell-programmer/ |
| 2024-08-09 16:44:20 +0200 | <zzz> | here's a wonderful phrase from http://ereserve.library.utah.edu/Annual/SOC/3568/Bench/myth.pdf : "Although I am tempted to give this response, I never do. This is because, although true, it never persuades." |
| 2024-08-09 16:44:34 +0200 | <dans77453> | =D |
| 2024-08-09 16:44:35 +0200 | <dans77453> | although facts shows the efforts haskellers make to increase the accessibility of their knowledge, i think haskell's values make it harder to fight "elitism" back. On the other hand i am concerned by seeing that applied to /all/ free dev |
| 2024-08-09 16:45:12 +0200 | jespada | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2024-08-09 16:46:40 +0200 | <EvanR> | haskell's values make it hard to mutate them |
| 2024-08-09 16:46:51 +0200 | <zzz> | i just got here and may be missing some context. in which ways is haskell being accused of elitism? |
| 2024-08-09 16:47:07 +0200 | <dans77453> | not haskell, free software development in general |
| 2024-08-09 16:47:23 +0200 | <dans77453> | #emacs, #linux |
| 2024-08-09 16:47:32 +0200 | <zzz> | can't anyone develop FOSS? |
| 2024-08-09 16:48:04 +0200 | <dans77453> | huh... i assume who comes from proprietary tech finds that harder |
| 2024-08-09 16:48:18 +0200 | <zzz> | why would that be? |
| 2024-08-09 16:48:29 +0200 | <dans77453> | just because they are used differently |
| 2024-08-09 16:48:39 +0200 | <dans77453> | *accustomed |
| 2024-08-09 16:49:17 +0200 | <zzz> | proprietary tech is less elitist than foss? |
| 2024-08-09 16:49:35 +0200 | <dans77453> | it's more ... statistically common for sure |
| 2024-08-09 16:49:58 +0200 | <zzz> | you think proprietary tech is more common? i seriously doubt that |
| 2024-08-09 16:50:03 +0200 | <EvanR> | yes, windows was always workingclass man's platform |
| 2024-08-09 16:50:17 +0200 | <EvanR> | regardless of how widely deployed |
| 2024-08-09 16:50:49 +0200 | dans77453 | (~danse-nr3@user/danse-nr3) (Remote host closed the connection) |
| 2024-08-09 16:50:59 +0200 | <EvanR> | linux was european communism cancer (according to steve ballmer) |
| 2024-08-09 16:51:03 +0200 | danse-nr3 | (~danse-nr3@user/danse-nr3) |
| 2024-08-09 16:51:12 +0200 | <Rembane> | EvanR: I need that on a t-shirt! |
| 2024-08-09 16:51:32 +0200 | <EvanR> | nevermind that contradiction |
| 2024-08-09 16:52:28 +0200 | <zzz> | i think we need to define our terms. what does elitist mean? what does beomg more common mean? the *vast* majority of servers in the world are running linux. the phone i'm writing this in is running linux |
| 2024-08-09 16:52:31 +0200 | <Rembane> | That the first slide in the Wired article isn't typeset with Comic Sans MS is just wrong |
| 2024-08-09 16:52:35 +0200 | <EvanR> | if you ever heard free software explained as, use this to really understand computing. Well that may come off as elitist. You actually know what you're doing? Leet |
| 2024-08-09 16:52:37 +0200 | <raehik> | I'm doing some low level bytestring manip where I poke bytes to a fresh ForeignPtr buffer which will eventually become a ByteString-- but it's failable, and if so we should free the buffer. Can I safely assume the garbage collector will do this for me if I simply discard the ForeignPtr? |
| 2024-08-09 16:53:14 +0200 | <danse-nr3> | hm i assume even communism can be considered elitist somehow... |
| 2024-08-09 16:53:26 +0200 | BitBitotabit5 | (~BitBitota@2804:880:130e:5700:b184:6405:971d:7d3d) |
| 2024-08-09 16:53:30 +0200 | <EvanR> | raehik, not unless you attached a finalizer |
| 2024-08-09 16:53:41 +0200 | <EvanR> | whcih explicitly frees the buffer |
| 2024-08-09 16:53:47 +0200 | <EvanR> | or used a bracket pattern which does it |
| 2024-08-09 16:54:14 +0200 | BitBitotabit5 | (~BitBitota@2804:880:130e:5700:b184:6405:971d:7d3d) (Write error: Broken pipe) |
| 2024-08-09 16:54:21 +0200 | <zzz> | danse-nr3: communist regimes tend to create elites, yes |
| 2024-08-09 16:54:29 +0200 | <zzz> | famously so |
| 2024-08-09 16:54:37 +0200 | <danse-nr3> | isn't that a contradiction in terms? |
| 2024-08-09 16:54:42 +0200 | <EvanR> | yes :) |
| 2024-08-09 16:54:42 +0200 | <zzz> | not at all |
| 2024-08-09 16:54:55 +0200 | <danse-nr3> | oligarchies, possibly. It's slightly different |
| 2024-08-09 16:55:30 +0200 | <danse-nr3> | 'cause some communism is very centralised |
| 2024-08-09 16:56:17 +0200 | <zzz> | communism is generally against class-based elitism, but because it's class based, not because it's elitism |
| 2024-08-09 16:56:30 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.2.2) |
| 2024-08-09 16:56:30 +0200 | <danse-nr3> | hmm |
| 2024-08-09 16:57:01 +0200 | <danse-nr3> | aren't you collapsing meritocracy and elitism again? |
| 2024-08-09 16:57:01 +0200 | <raehik> | EvanR: right I think I see, finalizeForeignPtr and withForeignPtr exist. thanks |
| 2024-08-09 16:57:02 +0200 | <EvanR> | raehik, a ForeignPtr points to something outside the haskell runtime, the gc doesn't know what to do with the foreign object. But there is a facility of finalizers |
| 2024-08-09 16:57:27 +0200 | <EvanR> | which let you specify |
| 2024-08-09 16:58:06 +0200 | <zzz> | danse-nr3: no |
| 2024-08-09 16:58:13 +0200 | Cbit | (~Cbit@2804:880:130e:5700:b184:6405:971d:7d3d) |
| 2024-08-09 16:58:25 +0200 | <danse-nr3> | i'll move to -offtopic |
| 2024-08-09 16:59:07 +0200 | <zzz> | i see how it can cause ambiguity though |
| 2024-08-09 16:59:47 +0200 | <zzz> | yes, better |
| 2024-08-09 17:02:20 +0200 | <EvanR> | one thing I heard about programming is that is it hard coming up with so many variable names. This was in context of an imperative language which encouraged a lot of local variables to hold the temporary results before doing the next action |
| 2024-08-09 17:02:36 +0200 | <EvanR> | do you find that this is more, less, or the same size problem in haskell |
| 2024-08-09 17:02:44 +0200 | <EvanR> | if any |
| 2024-08-09 17:03:01 +0200 | <int-e> | just know your a, b, c, and x, y, z and you'll be fine 80% of the time. |
| 2024-08-09 17:03:09 +0200 | <int-e> | f, g, h are also handy |
| 2024-08-09 17:03:38 +0200 | <EvanR> | great you don't need to name local variables lol |
| 2024-08-09 17:04:05 +0200 | <EvanR> | but what about top level bindings |
| 2024-08-09 17:04:21 +0200 | <int-e> | those are hard |
| 2024-08-09 17:05:57 +0200 | <int-e> | Unless you subscribe to the HT school of naming: Mod.f, Mod.T |
| 2024-08-09 17:06:03 +0200 | <EvanR> | lol |
| 2024-08-09 17:06:12 +0200 | <EvanR> | leverage hard the module names? |
| 2024-08-09 17:06:21 +0200 | <zzz> | what's in a name? would a rose by any other name not smell as sweet? |
| 2024-08-09 17:06:28 +0200 | <zzz> | paraphrasing the bard |
| 2024-08-09 17:06:43 +0200 | <EvanR> | I am inspired to great several cool and useful tools on hackage with that naming convention |
| 2024-08-09 17:07:33 +0200 | <int-e> | zzz: I'm sure a flumphrobble would not smell as sweet |
| 2024-08-09 17:08:19 +0200 | <danse-nr3> | after a bit working in haskell, i came to the conclusion that meaningless names stress me more than meaningful ones. And in haskell, often, i can avoid meaningless names |
| 2024-08-09 17:09:50 +0200 | <zzz> | danse-nr3: haskell is *very* good at letting you know what a function is, independently of which name you give it |
| 2024-08-09 17:10:21 +0200 | <danse-nr3> | well that depends how it's written i guess |
| 2024-08-09 17:10:22 +0200 | <EvanR> | by reading the source code? xD |
| 2024-08-09 17:10:29 +0200 | <int-e> | EvanR: actually this reminds me of one of the better bugs I've seen on haskell-cafe (ages ago): somebody produced a recursive binding because they had both a,b,c and r,g,b as variable names. |
| 2024-08-09 17:10:45 +0200 | <danse-nr3> | :P |
| 2024-08-09 17:10:46 +0200 | <zzz> | EvanR: yes but not only |
| 2024-08-09 17:10:55 +0200 | <zzz> | referential transparency is great |
| 2024-08-09 17:11:02 +0200 | <danse-nr3> | yeah i get what you mean zzz |
| 2024-08-09 17:11:09 +0200 | <danse-nr3> | but expressive types are not everywhere |
| 2024-08-09 17:11:15 +0200 | <EvanR> | I have been confused by binding the same variable multiple times xD |
| 2024-08-09 17:11:18 +0200 | <zzz> | navigating hoogle is a breeze compared to other languages |
| 2024-08-09 17:11:24 +0200 | <EvanR> | usually gets caught by the compiler because types don't match |
| 2024-08-09 17:11:27 +0200 | <danse-nr3> | (nor safe functions are) |
| 2024-08-09 17:11:59 +0200 | <danse-nr3> | i think a beginner could have a different opinion zzz |
| 2024-08-09 17:12:12 +0200 | <danse-nr3> | (about navigating hoogle or hackage) |
| 2024-08-09 17:12:19 +0200 | <zzz> | EvanR: overloading is discouraged, and ghc warns you about it |
| 2024-08-09 17:12:31 +0200 | <EvanR> | ? |
| 2024-08-09 17:12:37 +0200 | <danse-nr3> | yea we've got that as an error |
| 2024-08-09 17:12:47 +0200 | <danse-nr3> | and i'm glad about that |
| 2024-08-09 17:12:49 +0200 | <zzz> | danse-nr3: that applies to a beginner in anything |
| 2024-08-09 17:13:08 +0200 | <danse-nr3> | hmm... some are friendlier than others |
| 2024-08-09 17:13:10 +0200 | <zzz> | it's a poor argument |
| 2024-08-09 17:13:15 +0200 | <zzz> | danse-nr3: how so? |
| 2024-08-09 17:13:26 +0200 | <EvanR> | typeclasses is overloading, and multiple definitions with the wrong type is just wrong |
| 2024-08-09 17:13:57 +0200 | <danse-nr3> | zzz meant shadowing |
| 2024-08-09 17:14:01 +0200 | <EvanR> | oh yeah |
| 2024-08-09 17:14:15 +0200 | <EvanR> | call me the shadowmaster |
| 2024-08-09 17:14:21 +0200 | <danse-nr3> | XD |
| 2024-08-09 17:14:26 +0200 | <zzz> | EvanR: it's a mistake to equate class instances with overloading imo |
| 2024-08-09 17:14:44 +0200 | <EvanR> | sure |
| 2024-08-09 17:14:55 +0200 | <EvanR> | but you can undiscouragedly overload + in haskell |
| 2024-08-09 17:15:02 +0200 | <danse-nr3> | sure, one is derivation, the other is overloading |
| 2024-08-09 17:15:06 +0200 | <EvanR> | via some mechanism that's obviously not equated |
| 2024-08-09 17:16:03 +0200 | <EvanR> | meanwhile many languages actively discourage you from wanting to overload + |
| 2024-08-09 17:16:10 +0200 | <zzz> | EvanR: you can create a sum function in most languages and overload it |
| 2024-08-09 17:16:17 +0200 | <EvanR> | by not having that feature, or otherwise |
| 2024-08-09 17:16:38 +0200 | <EvanR> | creating a function called sum and overloading + isn't the same thing |
| 2024-08-09 17:16:46 +0200 | <zzz> | yes it is |
| 2024-08-09 17:16:47 +0200 | <EvanR> | no |
| 2024-08-09 17:16:56 +0200 | <zzz> | it just happens to be called + in haskell |
| 2024-08-09 17:16:57 +0200 | ft | (~ft@p4fc2aa15.dip0.t-ipconnect.de) |
| 2024-08-09 17:17:32 +0200 | <EvanR> | you were talking about shadowing anyway so this is a timeline which needs to get purged |
| 2024-08-09 17:18:12 +0200 | <zzz> | fair enough |
| 2024-08-09 17:26:29 +0200 | <EvanR> | and I think we were talking about this rogue phenomenon which isn't really shadowing because recursive bindings don't really have a seniority https://paste.tomsmeding.com/a43p42FI |
| 2024-08-09 17:36:51 +0200 | <zzz> | ah, i missed that |
| 2024-08-09 17:37:38 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 4.2.2) |
| 2024-08-09 17:38:34 +0200 | <zzz> | my mind keeps going back to this idea https://www.unison-lang.org/docs/the-big-idea/ |
| 2024-08-09 17:39:26 +0200 | <zzz> | i understand it's tangential to this discussion but still |
| 2024-08-09 17:39:50 +0200 | <danse-nr3> | no worries, discussion is dead anyways |
| 2024-08-09 17:39:57 +0200 | <zzz> | the less names matter in a language the happier i am |
| 2024-08-09 17:43:25 +0200 | <haskellbridge> | <mauke> This is why I only code in Brainfuck |
| 2024-08-09 17:44:47 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
| 2024-08-09 17:45:05 +0200 | ZharMeny | (~user@user/ZharMeny) |
| 2024-08-09 17:47:45 +0200 | euleritian | (~euleritia@dynamic-176-006-130-193.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-08-09 17:47:54 +0200 | <EvanR> | "naming things is hard", clearly the code should make reference using glowing strands of graphics. That don't get tangled up somehow |
| 2024-08-09 17:48:03 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-08-09 17:48:14 +0200 | <raehik> | bytestring's createFpAndTrim can potentially malloc 2 buffers and return the smaller one. I don't see an explicit free/finalizer call/bracketing for the larger buffer in such a case. How does this work? https://hackage.haskell.org/package/bytestring-0.12.1.0/docs/src/Data.ByteString.Internal.Type.htm… |
| 2024-08-09 17:49:16 +0200 | <raehik> | I ask because I've effectively reimplemented createFpAndTrim with a custom action and it works, but I wonder if I've aimed a gun at a foot |
| 2024-08-09 17:50:06 +0200 | <EvanR> | createFpAndTrim seems to be so low level that it has no guardrails at all |
| 2024-08-09 17:50:16 +0200 | <c_wraith> | It's using a ForeignPtr, not a Ptr |
| 2024-08-09 17:50:22 +0200 | <c_wraith> | that means there's a finalizer attached |
| 2024-08-09 17:50:23 +0200 | <EvanR> | if the thread crashes during or after, you leak the buffers |
| 2024-08-09 17:50:51 +0200 | <EvanR> | oh foreignpointer to malloc automatically has finalizers? |
| 2024-08-09 17:51:12 +0200 | <c_wraith> | You only use a ForeignPtr if you've got finalizers to attach |
| 2024-08-09 17:51:34 +0200 | <EvanR> | I don't see where it is attached in this case |
| 2024-08-09 17:51:34 +0200 | <c_wraith> | But you'd need to find an inspect mallocPlainForeignPtrBytes to be sure |
| 2024-08-09 17:52:04 +0200 | jespada | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) |
| 2024-08-09 17:52:34 +0200 | <c_wraith> | Oh dear. "an optimised ForeignPtr representation with no finalizer is used. Attempts to add a finalizer will cause an exception to be thrown." |
| 2024-08-09 17:53:13 +0200 | <haskellbridge> | <mauke> https://hackage.haskell.org/package/base-4.20.0.1/docs/GHC-ForeignPtr.html#v:mallocForeignPtr |
| 2024-08-09 17:53:21 +0200 | <raehik> | mallocByteString creates ForeignPtrs with PlainPtr |
| 2024-08-09 17:53:33 +0200 | <EvanR> | ok I'm wrong about "no guardrails" xD |
| 2024-08-09 17:53:51 +0200 | <EvanR> | mallocPlainForeignPtrBytes stops you from adding a finalizer |
| 2024-08-09 17:55:23 +0200 | <raehik> | mauke: looks like I can't select the buffer size there, it's down to the Storable instance |
| 2024-08-09 17:55:24 +0200 | <c_wraith> | Interestingly, PlainPtr looks like it still gets garbage collected - you just can't hook in a finalizer to run native code |
| 2024-08-09 17:55:49 +0200 | <c_wraith> | So there is no bracket to clean up the larger buffer immediately, but it's part of GHC's heap |
| 2024-08-09 17:55:56 +0200 | <c_wraith> | it gets cleaned up eventually. |
| 2024-08-09 17:55:58 +0200 | <haskellbridge> | <mauke> ? This is just for documentation |
| 2024-08-09 17:56:04 +0200 | <raehik> | I see! I wondered if that was the case |
| 2024-08-09 17:56:16 +0200 | <raehik> | mauke: oh apologies, I thought you were suggesting a different approach |
| 2024-08-09 17:56:59 +0200 | <haskellbridge> | <mauke> This is the function that the other variants are described as being similar to |
| 2024-08-09 17:57:00 +0200 | <raehik> | another thing, bytestring uses withForeignPtr instead of unsafeWithForeignPtr. that figures because the user passes in the IO action, which could fail |
| 2024-08-09 17:57:24 +0200 | <EvanR> | PlainForeignPtr or MallocPtr would do what you want, but it's not |
| 2024-08-09 17:57:35 +0200 | <raehik> | if I write an action that's just Haskell (no FFI) and can't obviously fail, am I clear to use unsafeWithForeignPtr? |
| 2024-08-09 17:57:49 +0200 | <haskellbridge> | <mauke> Where similar to = automatic memory management |
| 2024-08-09 17:58:17 +0200 | <EvanR> | can't obviously fail = obviously can't fail? xD |
| 2024-08-09 17:58:32 +0200 | <haskellbridge> | <mauke> Can I throwTo your thread? |
| 2024-08-09 17:59:09 +0200 | andrewchawk | (~andrewcha@170.52.55.98) |
| 2024-08-09 17:59:23 +0200 | <raehik> | mauke: I don't know of that function. if you can find the thread ID I imagine so |
| 2024-08-09 17:59:26 +0200 | jespada_ | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) |
| 2024-08-09 18:00:09 +0200 | <c_wraith> | raehik: throwTo only can introduce exceptions at specific points - those points being when an allocation happens |
| 2024-08-09 18:00:14 +0200 | <andrewchawk> | Good God. I just joined, and I already see a bit of activity. IRC really must still be alive. :-) |
| 2024-08-09 18:00:16 +0200 | <zzz> | raehik: you can. doesn't mean that you should |
| 2024-08-09 18:00:33 +0200 | <EvanR> | IRC never dies it just stands in the back |
| 2024-08-09 18:00:39 +0200 | jespada | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2024-08-09 18:00:45 +0200 | <haskellbridge> | <mauke> throwTo lets other people inject arbitrary exceptions into otherwise harmless IO actions |
| 2024-08-09 18:00:48 +0200 | <c_wraith> | You could safely use unsafeWithForeignPtr if the haskell code never allocates. |
| 2024-08-09 18:01:00 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-08-09 18:01:18 +0200 | <raehik> | I see. thanks c_wraith , it's a lot more finicky than I thought |
| 2024-08-09 18:01:23 +0200 | <EvanR> | I think raehik is trying to write to most unsafe haskell imaginable |
| 2024-08-09 18:01:36 +0200 | <EvanR> | because unsafe = speed |
| 2024-08-09 18:01:43 +0200 | kuribas | (~user@2a02:1810:2825:6000:22f5:5d2b:a63a:1884) (Quit: ERC (IRC client for Emacs 27.1)) |
| 2024-08-09 18:02:01 +0200 | <haskellbridge> | <mauke> Is that true even in the threaded runtime? The only at allocations part |
| 2024-08-09 18:02:05 +0200 | <c_wraith> | they haven't asked about accursedUnutterablePerformIO yet! |
| 2024-08-09 18:02:40 +0200 | <raehik> | EvanR: these libraries have exposed these functions, and I simply wish to understand them :) |
| 2024-08-09 18:03:09 +0200 | <andrewchawk> | EvanR: :-) |
| 2024-08-09 18:03:12 +0200 | <EvanR> | famous last words in lovecraft |
| 2024-08-09 18:03:18 +0200 | <c_wraith> | mauke: yes. Even the GC can't interrupt code that doesn't allocate. You can hang a program on the threaded runtime by starting a thread that runs forever and does no allocation |
| 2024-08-09 18:03:35 +0200 | <zzz> | pure $ unsafePerformIO $ peek nullPtr |
| 2024-08-09 18:04:13 +0200 | <EvanR> | that doesn't obviously fail depending on what pure means |
| 2024-08-09 18:04:22 +0200 | <zzz> | :: IO () |
| 2024-08-09 18:04:45 +0200 | <c_wraith> | so it's a segfault only if you force the () value |
| 2024-08-09 18:05:12 +0200 | <raehik> | the docs for unsafeWithForeignPtr seem lacking perhaps. no mention of how thread interrupts and allocations can impact soundness |
| 2024-08-09 18:06:08 +0200 | <EvanR> | that's documented in Control.Exception docs? And or Control.Concurrent |
| 2024-08-09 18:06:59 +0200 | <EvanR> | and or the paper on haskell's asynchronous exception system |
| 2024-08-09 18:07:08 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3317-c12e-b11a-79e1-1830-8594.rev.sfr.net) |
| 2024-08-09 18:09:12 +0200 | <zzz> | vs :: IO Word |
| 2024-08-09 18:09:31 +0200 | dsrt^ | (dsrt@c-98-242-74-66.hsd1.ga.comcast.net) (Ping timeout: 244 seconds) |
| 2024-08-09 18:15:00 +0200 | andrewchawk | (~andrewcha@170.52.55.98) (Changing host) |
| 2024-08-09 18:15:00 +0200 | andrewchawk | (~andrewcha@user/andrewchawk) |
| 2024-08-09 18:21:06 +0200 | machinedgod | (~machinedg@d50-99-47-73.abhsia.telus.net) (Ping timeout: 248 seconds) |
| 2024-08-09 18:30:17 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
| 2024-08-09 18:33:17 +0200 | <raehik> | I wonder if a library that assists buffer updates in ST-land would be work & be handy. my buffer filling action only calls writeXOffPtr which could be placed into IO. and if this helps me use unsafeWithForeignPtr safely (can't allocate in ST, as far as I understand?) it'd be useful |
| 2024-08-09 18:34:03 +0200 | <raehik> | s/which could be placed into IO/which could be placed into ST (currently in IO) |
| 2024-08-09 18:36:08 +0200 | <raehik> | wait maybe primitive already does this :o |
| 2024-08-09 18:36:53 +0200 | <geekosaur> | the alternative is something might allow local allocation in ST by tagging the result with the existential? not sure how safe that is |
| 2024-08-09 18:37:53 +0200 | spew | (~spew@201.141.102.132) |
| 2024-08-09 18:38:00 +0200 | <raehik> | being able to do both seems useful |
| 2024-08-09 18:38:45 +0200 | danse-nr3 | (~danse-nr3@user/danse-nr3) (Ping timeout: 248 seconds) |
| 2024-08-09 18:39:07 +0200 | <EvanR> | can't you allocate a buffer of unboxed Word8 in ST |
| 2024-08-09 18:39:10 +0200 | <raehik> | I think primitive does a lot of this, but the interfacing with bytestring is so messy because of the arbitrary internals exporting. some high-level things just, don't get exported |
| 2024-08-09 18:40:20 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) |
| 2024-08-09 18:41:02 +0200 | <raehik> | EvanR: not sure how to allocate in ST at all. all the malloc-likes I can find need IO |
| 2024-08-09 18:41:32 +0200 | <raehik> | I'm not _completely_ clear on what "allocate" refers to so might be looking in the wrong place |
| 2024-08-09 18:42:20 +0200 | <EvanR> | the Array and unboxed array library is parameterized on the prim monad either IO or ST |
| 2024-08-09 18:42:28 +0200 | <EvanR> | so it's the same API |
| 2024-08-09 18:43:01 +0200 | <raehik> | oh yup, you're right |
| 2024-08-09 18:43:23 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3317-c12e-b11a-79e1-1830-8594.rev.sfr.net) (Remote host closed the connection) |
| 2024-08-09 18:43:28 +0200 | <EvanR> | but an unboxed array is not what constitutes a ByteString so to get a ByteString in the end you need to make a copy, probably. |
| 2024-08-09 18:44:55 +0200 | <raehik> | ok, assuming that counts as an interruptible allocation I suppose unsafeWithForeignPtr should only be applied with the utmost caution |
| 2024-08-09 18:47:19 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3317-c12e-51f5-a487-8417-dd3a.rev.sfr.net) |
| 2024-08-09 18:47:43 +0200 | <raehik> | then really all I want is a library on top of Data.ByteString.Internal that makes it easier to initialize and manipulate bytestring buffers :) |
| 2024-08-09 18:48:47 +0200 | <EvanR> | there is malloc, peek and poke |
| 2024-08-09 18:48:48 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-08-09 18:48:53 +0200 | <EvanR> | go to town |
| 2024-08-09 18:50:03 +0200 | <EvanR> | you can't literally manipulate the buffer backing a ByteString because that type is supposed to be immutable |
| 2024-08-09 18:50:25 +0200 | <EvanR> | but when you're done you can logically "freeze" the buffer you were working with as long as it's not within the garbage collector |
| 2024-08-09 18:50:46 +0200 | <EvanR> | and wrap it in the ByteString secret constructors |
| 2024-08-09 18:50:49 +0200 | <raehik> | right I mean manipulating a buffer that will become a bytestring later |
| 2024-08-09 18:51:08 +0200 | <raehik> | primitive has tons of tools for manipulating regular buffers |
| 2024-08-09 18:51:27 +0200 | <EvanR> | regular buffer? |
| 2024-08-09 18:51:41 +0200 | <raehik> | arbitrary buffers |
| 2024-08-09 18:51:48 +0200 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) (Read error: Connection reset by peer) |
| 2024-08-09 18:52:00 +0200 | <EvanR> | malloced buffer? haskell managed buffers? |
| 2024-08-09 18:52:17 +0200 | <EvanR> | foreign buffer |
| 2024-08-09 18:52:18 +0200 | <raehik> | primitive mostly deals in Ptr and that's it |
| 2024-08-09 18:52:21 +0200 | <raehik> | (I think) |
| 2024-08-09 18:52:40 +0200 | <EvanR> | then it deals in pointers and not buffers xD |
| 2024-08-09 18:52:54 +0200 | <raehik> | oh sorry I use those interchangeably |
| 2024-08-09 18:53:03 +0200 | <raehik> | Ptr Word8 is a buffer to me |
| 2024-08-09 18:53:08 +0200 | <EvanR> | the C channel would have your head |
| 2024-08-09 18:53:08 +0200 | spew | (~spew@201.141.102.132) (Read error: Connection reset by peer) |
| 2024-08-09 18:53:22 +0200 | sawilagar | (~sawilagar@user/sawilagar) (Remote host closed the connection) |
| 2024-08-09 18:53:46 +0200 | sawilagar | (~sawilagar@user/sawilagar) |
| 2024-08-09 18:54:52 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2024-08-09 18:55:10 +0200 | <EvanR> | but if your buffer is somewhere stable and not subject to GC, you can make it a bytestring via ForeignPtr, after using that library |
| 2024-08-09 18:57:56 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2024-08-09 18:58:28 +0200 | danse-nr3 | (~danse-nr3@user/danse-nr3) |
| 2024-08-09 19:00:29 +0200 | <raehik> | yes my use case is these buffers will always be going to bytestrings eventually. bytestring lib has internals for this but 1/2 of them aren't exported. reimplementing unexported functions and a tiny bit of glue would greatly simplify it |
| 2024-08-09 19:02:06 +0200 | bo1 | (~bo1@2804:880:130e:5700:b184:6405:971d:7d3d) |
| 2024-08-09 19:02:08 +0200 | <EvanR> | there's been a string of packages which do 1 thing, convert an unboxed array of Word8 into ByteString using internal unsafe unstable stuff to avoid a copy |
| 2024-08-09 19:02:13 +0200 | krei-se | (~krei-se@p57af2d39.dip0.t-ipconnect.de) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2024-08-09 19:02:24 +0200 | <EvanR> | or maybe it was the other way around |
| 2024-08-09 19:04:26 +0200 | <EvanR> | whatever the wisdom of wanting to do this, it seems the simplest way to cooperate with existing haskell |
| 2024-08-09 19:06:00 +0200 | <raehik> | that's interesting. I don't think it would be the most performant approach |
| 2024-08-09 19:06:51 +0200 | <raehik> | I'm not averse to doing safe IO work for performance & don't think it should be "frowned upon". the vector pkg is excellent in this regard |
| 2024-08-09 19:08:41 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2024-08-09 19:11:29 +0200 | CiaoSen | (~Jura@2a05:5800:2da:c00:e6b9:7aff:fe80:3d03) |
| 2024-08-09 19:24:40 +0200 | <geekosaur> | there also used to be a patched ByteString that used unboxed vectors internally; sadly, it never caught on |
| 2024-08-09 19:25:30 +0200 | andrewchawk | (~andrewcha@user/andrewchawk) (Remote host closed the connection) |
| 2024-08-09 19:25:45 +0200 | andrewchawk | (~andrewcha@170.52.55.98) |
| 2024-08-09 19:26:52 +0200 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) (Remote host closed the connection) |
| 2024-08-09 19:27:13 +0200 | krei-se | (~krei-se@p57af2d39.dip0.t-ipconnect.de) |
| 2024-08-09 19:27:29 +0200 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) |
| 2024-08-09 19:27:29 +0200 | ChanServ | +v haskellbridge |
| 2024-08-09 19:30:14 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2024-08-09 19:32:02 +0200 | andrewchawk | (~andrewcha@170.52.55.98) (Ping timeout: 252 seconds) |
| 2024-08-09 19:33:48 +0200 | BitByte | (~BitByte@2804:880:130e:5700:b184:6405:971d:7d3d) (Quit: Client closed) |
| 2024-08-09 19:42:27 +0200 | CrunchyFlakes | (~CrunchyFl@146.52.130.128) (Read error: Connection reset by peer) |
| 2024-08-09 19:42:38 +0200 | andrewchawk | (~andrewcha@170.52.55.98) |
| 2024-08-09 19:43:13 +0200 | andrewchawk | (~andrewcha@170.52.55.98) (Changing host) |
| 2024-08-09 19:43:13 +0200 | andrewchawk | (~andrewcha@user/andrewchawk) |
| 2024-08-09 19:44:15 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-08-09 19:45:03 +0200 | CrunchyFlakes | (~CrunchyFl@ip92348280.dynamic.kabel-deutschland.de) |
| 2024-08-09 19:45:29 +0200 | Cbit | (~Cbit@2804:880:130e:5700:b184:6405:971d:7d3d) (Ping timeout: 256 seconds) |
| 2024-08-09 19:46:52 +0200 | <EvanR> | the filepath package is an implementation of the abstract filepath proposal. Does it get any use? Is it universally used now? |
| 2024-08-09 19:48:39 +0200 | dans41958 | (~danse-nr3@user/danse-nr3) |
| 2024-08-09 19:50:41 +0200 | danse-nr3 | (~danse-nr3@user/danse-nr3) (Ping timeout: 248 seconds) |
| 2024-08-09 19:51:43 +0200 | Buliarous | (~gypsydang@46.232.210.139) (Remote host closed the connection) |
| 2024-08-09 19:52:42 +0200 | <geekosaur> | the old filepath package (pre-proposal) got little use. the new one (implementing the proposal) gets a fair amount of use and more things are switching to it |
| 2024-08-09 19:56:37 +0200 | CiaoSen | (~Jura@2a05:5800:2da:c00:e6b9:7aff:fe80:3d03) (Ping timeout: 248 seconds) |
| 2024-08-09 19:58:57 +0200 | ubert | (~Thunderbi@178.165.184.113.wireless.dyn.drei.com) (Quit: ubert) |
| 2024-08-09 19:59:10 +0200 | ubert | (~Thunderbi@178.165.184.113.wireless.dyn.drei.com) |
| 2024-08-09 20:00:08 +0200 | <EvanR> | they are both called filepath? |
| 2024-08-09 20:00:48 +0200 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 245 seconds) |
| 2024-08-09 20:06:03 +0200 | ubert | (~Thunderbi@178.165.184.113.wireless.dyn.drei.com) (Ping timeout: 252 seconds) |
| 2024-08-09 20:14:44 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2024-08-09 20:17:53 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2024-08-09 20:19:59 +0200 | <geekosaur> | yes. the new one bumped the minor version to 100 |
| 2024-08-09 20:20:00 +0200 | andrewchawk | (~andrewcha@user/andrewchawk) (Remote host closed the connection) |
| 2024-08-09 20:20:19 +0200 | andrewchawk | (~andrewcha@170.52.55.98) |
| 2024-08-09 20:20:25 +0200 | <geekosaur> | so the last old version is 1.4.2.2 and the first new one is 1.4.100.0 |
| 2024-08-09 20:20:34 +0200 | <geekosaur> | (they do share API) |
| 2024-08-09 20:22:04 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2024-08-09 20:25:00 +0200 | <EvanR> | it looks cool but how do you like... open a file using an OsPath |
| 2024-08-09 20:27:11 +0200 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2024-08-09 20:27:47 +0200 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) |
| 2024-08-09 20:31:19 +0200 | andrewchawk | (~andrewcha@170.52.55.98) (Quit: Leaving) |
| 2024-08-09 20:31:45 +0200 | Cbit | (~Cbit@2804:880:130e:5700:b184:6405:971d:7d3d) |
| 2024-08-09 20:31:49 +0200 | bo1 | (~bo1@2804:880:130e:5700:b184:6405:971d:7d3d) (Quit: Client closed) |
| 2024-08-09 20:32:15 +0200 | Cbit | (~Cbit@2804:880:130e:5700:b184:6405:971d:7d3d) (Client Quit) |
| 2024-08-09 20:39:05 +0200 | skyesoss1 | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) |
| 2024-08-09 20:45:17 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-08-09 20:46:42 +0200 | skyesoss1 | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) (Quit: skyesoss1) |
| 2024-08-09 20:49:00 +0200 | Ellenor | (ellenor@callbox.trd.is) |
| 2024-08-09 20:54:59 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-08-09 21:00:32 +0200 | mesaoptimizer | (~mesaoptim@user/PapuaHardyNet) (Ping timeout: 244 seconds) |
| 2024-08-09 21:04:49 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-08-09 21:05:08 +0200 | sawilagar | (~sawilagar@user/sawilagar) |
| 2024-08-09 21:10:10 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-08-09 21:12:08 +0200 | mesaoptimizer | (~mesaoptim@user/PapuaHardyNet) |
| 2024-08-09 21:19:44 +0200 | thaumavorio | (~thaumavor@thaumavor.io) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-08-09 21:21:00 +0200 | thaumavorio | (~thaumavor@thaumavor.io) |
| 2024-08-09 21:22:22 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-08-09 21:25:55 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 264 seconds) |
| 2024-08-09 21:30:20 +0200 | kupi | (uid212005@id-212005.hampstead.irccloud.com) |
| 2024-08-09 21:35:39 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3317-c12e-51f5-a487-8417-dd3a.rev.sfr.net) (Remote host closed the connection) |
| 2024-08-09 21:47:43 +0200 | dans41958 | (~danse-nr3@user/danse-nr3) (Quit: good night) |
| 2024-08-09 21:52:33 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-08-09 21:56:01 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-08-09 22:02:49 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) |
| 2024-08-09 22:03:31 +0200 | falafel | (~falafel@2a0c:5a87:3104:4c01::aa34) |
| 2024-08-09 22:06:19 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-08-09 22:09:37 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-08-09 22:13:38 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) (Quit: skyesoss) |
| 2024-08-09 22:19:56 +0200 | <probie> | EvanR: https://hackage.haskell.org/package/file-io |
| 2024-08-09 22:21:15 +0200 | <EvanR> | noice |
| 2024-08-09 22:24:27 +0200 | falafel | (~falafel@2a0c:5a87:3104:4c01::aa34) (Ping timeout: 276 seconds) |
| 2024-08-09 22:27:47 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-08-09 22:28:38 +0200 | machinedgod | (~machinedg@d50-99-47-73.abhsia.telus.net) |
| 2024-08-09 22:33:05 +0200 | ubert | (~Thunderbi@178.165.184.113.wireless.dyn.drei.com) |
| 2024-08-09 22:33:06 +0200 | spew | (~spew@201.141.102.132) |
| 2024-08-09 22:33:23 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-08-09 22:33:45 +0200 | spew | (~spew@201.141.102.132) (Client Quit) |
| 2024-08-09 22:40:46 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 244 seconds) |
| 2024-08-09 22:42:15 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-08-09 22:43:18 +0200 | ubert | (~Thunderbi@178.165.184.113.wireless.dyn.drei.com) (Ping timeout: 276 seconds) |
| 2024-08-09 22:43:41 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-08-09 22:44:01 +0200 | hueso | (~root@user/hueso) (Quit: No Ping reply in 180 seconds.) |
| 2024-08-09 22:45:20 +0200 | hueso | (~root@user/hueso) |
| 2024-08-09 22:45:59 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-08-09 22:48:26 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Quit: WeeChat 4.3.5) |
| 2024-08-09 22:56:51 +0200 | hueso | (~root@user/hueso) (Quit: No Ping reply in 180 seconds.) |
| 2024-08-09 22:58:00 +0200 | hueso | (~root@user/hueso) |
| 2024-08-09 22:58:53 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2024-08-09 23:02:21 +0200 | kimiamania | (~65804703@user/kimiamania) (Quit: PegeLinux) |
| 2024-08-09 23:02:44 +0200 | kimiamania | (~65804703@user/kimiamania) |
| 2024-08-09 23:13:49 +0200 | ZharMeny` | (~user@user/ZharMeny) |
| 2024-08-09 23:17:19 +0200 | ZharMeny | (~user@user/ZharMeny) (Ping timeout: 260 seconds) |
| 2024-08-09 23:18:10 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) (Ping timeout: 248 seconds) |
| 2024-08-09 23:24:49 +0200 | michalz | (~michalz@185.246.207.193) (Remote host closed the connection) |
| 2024-08-09 23:40:36 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2024-08-09 23:47:26 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-08-09 23:53:16 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |