| 2023-08-30 00:00:45 +0200 | edwtjo | (~edwtjo@fsf/member/edwtjo) (Ping timeout: 248 seconds) |
| 2023-08-30 00:03:43 +0200 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection) |
| 2023-08-30 00:04:20 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-30 00:06:45 +0200 | ulysses4ever | (~artem@2601:408:c408:76fb:f474:e3f8:9806:671) |
| 2023-08-30 00:08:15 +0200 | <Inst> | beat python with point-free lambdas by 1 word, if you don't count _ or type sigs |
| 2023-08-30 00:08:44 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 248 seconds) |
| 2023-08-30 00:09:30 +0200 | Square2 | (~Square4@user/square) |
| 2023-08-30 00:09:49 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-30 00:11:00 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
| 2023-08-30 00:11:00 +0200 | artem | (~artem@73.145.241.185) |
| 2023-08-30 00:12:29 +0200 | ulysses4ever | (~artem@2601:408:c408:76fb:f474:e3f8:9806:671) (Ping timeout: 248 seconds) |
| 2023-08-30 00:14:16 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 255 seconds) |
| 2023-08-30 00:14:35 +0200 | danza_ | (~francesco@151.43.239.168) |
| 2023-08-30 00:16:46 +0200 | ulysses4ever | (~artem@73.145.241.185) |
| 2023-08-30 00:16:46 +0200 | artem | (~artem@73.145.241.185) (Read error: Connection reset by peer) |
| 2023-08-30 00:16:46 +0200 | danza | (~francesco@151.19.249.125) (Read error: Connection reset by peer) |
| 2023-08-30 00:17:13 +0200 | artem | (~artem@73.145.241.185) |
| 2023-08-30 00:17:13 +0200 | ulysses4ever | (~artem@73.145.241.185) (Read error: Connection reset by peer) |
| 2023-08-30 00:20:26 +0200 | ulysses4ever | (~artem@73.145.241.185) |
| 2023-08-30 00:20:26 +0200 | artem | (~artem@73.145.241.185) (Read error: Connection reset by peer) |
| 2023-08-30 00:20:43 +0200 | anselmschueler | (~anselmsch@user/schuelermine) (Quit: WeeChat 4.0.3) |
| 2023-08-30 00:23:13 +0200 | pavonia | (~user@user/siracusa) |
| 2023-08-30 00:24:44 +0200 | edwtjo | (~edwtjo@h-46-59-62-248.A213.priv.bahnhof.se) |
| 2023-08-30 00:24:44 +0200 | edwtjo | (~edwtjo@h-46-59-62-248.A213.priv.bahnhof.se) (Changing host) |
| 2023-08-30 00:24:44 +0200 | edwtjo | (~edwtjo@fsf/member/edwtjo) |
| 2023-08-30 00:26:17 +0200 | gatekempt | (~gatekempt@user/gatekempt) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2023-08-30 00:26:17 +0200 | ulysses4ever | (~artem@73.145.241.185) (Read error: Connection reset by peer) |
| 2023-08-30 00:26:22 +0200 | artem | (~artem@73.145.241.185) |
| 2023-08-30 00:33:01 +0200 | ulysses4ever | (~artem@2601:408:c408:6616:f474:e3f8:9806:671) |
| 2023-08-30 00:35:25 +0200 | artem | (~artem@73.145.241.185) (Ping timeout: 255 seconds) |
| 2023-08-30 00:35:45 +0200 | ulysses4ever | (~artem@2601:408:c408:6616:f474:e3f8:9806:671) (Read error: Connection reset by peer) |
| 2023-08-30 00:37:41 +0200 | ulysses4ever | (~artem@73.145.241.185) |
| 2023-08-30 00:39:17 +0200 | artem | (~artem@73.145.241.185) |
| 2023-08-30 00:40:19 +0200 | artem | (~artem@73.145.241.185) (Read error: Connection reset by peer) |
| 2023-08-30 00:42:41 +0200 | bitmapper | (uid464869@id-464869.lymington.irccloud.com) |
| 2023-08-30 00:42:47 +0200 | ulysses4ever | (~artem@73.145.241.185) |
| 2023-08-30 00:44:36 +0200 | sm | (~sm@plaintextaccounting/sm) (Ping timeout: 245 seconds) |
| 2023-08-30 00:45:19 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2023-08-30 00:47:59 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2023-08-30 00:48:00 +0200 | ulysses4ever | (~artem@73.145.241.185) (Read error: Connection reset by peer) |
| 2023-08-30 00:48:06 +0200 | artem | (~artem@73.145.241.185) |
| 2023-08-30 00:48:23 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2023-08-30 00:48:27 +0200 | artem | (~artem@73.145.241.185) (Read error: Connection reset by peer) |
| 2023-08-30 00:48:30 +0200 | ulysses4ever | (~artem@2601:408:c408:6616:f474:e3f8:9806:671) |
| 2023-08-30 00:56:27 +0200 | artem | (~artem@c-73-103-90-145.hsd1.in.comcast.net) |
| 2023-08-30 00:58:46 +0200 | CiaoSen | (~Jura@2a05:5800:284:a000:664b:f0ff:fe37:9ef) (Ping timeout: 260 seconds) |
| 2023-08-30 00:59:09 +0200 | sm | (~sm@plaintextaccounting/sm) (Quit: sm) |
| 2023-08-30 00:59:24 +0200 | ulysses4ever | (~artem@2601:408:c408:6616:f474:e3f8:9806:671) (Ping timeout: 248 seconds) |
| 2023-08-30 01:00:41 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-08-30 01:03:46 +0200 | shapr | (~user@2600:1700:c640:3100:147e:15c1:a149:186b) (Remote host closed the connection) |
| 2023-08-30 01:12:22 +0200 | caryhartline | (~caryhartl@168.182.58.169) (Quit: caryhartline) |
| 2023-08-30 01:13:51 +0200 | scholabl` | (~user@160.176.25.249) (Remote host closed the connection) |
| 2023-08-30 01:15:17 +0200 | fserucas_ | (~fserucas@46.50.115.39) (Ping timeout: 246 seconds) |
| 2023-08-30 01:23:41 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2023-08-30 01:34:53 +0200 | caryhartline | (~caryhartl@168.182.58.169) |
| 2023-08-30 01:38:06 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 246 seconds) |
| 2023-08-30 01:40:21 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2023-08-30 01:40:37 +0200 | SheRejoined | (haveident@libera/staff/she/her) |
| 2023-08-30 01:41:17 +0200 | She | Guest3872 |
| 2023-08-30 01:41:17 +0200 | Guest3872 | (haveident@libera/staff/she/her) (Killed (sodium.libera.chat (Nickname regained by services))) |
| 2023-08-30 01:41:17 +0200 | SheRejoined | she |
| 2023-08-30 01:41:17 +0200 | she | She |
| 2023-08-30 01:47:45 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2023-08-30 01:48:19 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 255 seconds) |
| 2023-08-30 01:49:04 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2023-08-30 01:50:30 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 245 seconds) |
| 2023-08-30 02:00:52 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::a840) (Remote host closed the connection) |
| 2023-08-30 02:01:12 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::a10) |
| 2023-08-30 02:02:17 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
| 2023-08-30 02:04:19 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-30 02:04:22 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-08-30 02:09:01 +0200 | fweht | (uid404746@id-404746.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-08-30 02:12:24 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-08-30 02:21:10 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 255 seconds) |
| 2023-08-30 02:23:06 +0200 | thegeekinside | (~thegeekin@189.180.81.59) |
| 2023-08-30 02:24:14 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-08-30 02:28:46 +0200 | Maxdamantus | (~Maxdamant@user/maxdamantus) (Ping timeout: 245 seconds) |
| 2023-08-30 02:29:18 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-08-30 02:30:46 +0200 | Maxdamantus | (~Maxdamant@user/maxdamantus) |
| 2023-08-30 02:35:34 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 255 seconds) |
| 2023-08-30 02:36:28 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2023-08-30 02:36:40 +0200 | Square2 | Square |
| 2023-08-30 02:39:58 +0200 | chromoblob | (~user@37.113.156.54) |
| 2023-08-30 02:42:28 +0200 | bratwurst | (~blaadsfa@S010610561191f5d6.lb.shawcable.net) |
| 2023-08-30 02:43:09 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 250 seconds) |
| 2023-08-30 02:44:52 +0200 | chromobl1b | (~user@37.113.172.116) |
| 2023-08-30 02:45:25 +0200 | caryhartline | (~caryhartl@168.182.58.169) (Quit: caryhartline) |
| 2023-08-30 02:45:26 +0200 | chromoblob | (~user@37.113.156.54) (Ping timeout: 245 seconds) |
| 2023-08-30 02:45:26 +0200 | shapr | (~user@2600:1700:c640:3100:6019:9d8e:9090:8797) |
| 2023-08-30 02:45:33 +0200 | chromobl1b | chromoblob |
| 2023-08-30 02:45:41 +0200 | <chromoblob> | has somebody ported the "standard set of Haskell structures" like F.,A.,M.,Alternative,MonadXXX,Foldable,Traversable,RWS,transformers,lenses, and such, including the functions outside typeclasses and common instances, to C++? |
| 2023-08-30 02:47:53 +0200 | <segfaultfizzbuzz> | how would that work? don't you need gc, naievely at least? |
| 2023-08-30 02:48:24 +0200 | <chromoblob> | for what do you need GC exactly? |
| 2023-08-30 02:49:04 +0200 | bilegeek | (~bilegeek@2600:1008:b004:e71b:f993:4604:698f:bf53) |
| 2023-08-30 02:49:12 +0200 | <segfaultfizzbuzz> | like, everything-ish, i think...? |
| 2023-08-30 02:49:20 +0200 | <chromoblob> | for example? |
| 2023-08-30 02:49:58 +0200 | <segfaultfizzbuzz> | maybe someone else can take the mic here |
| 2023-08-30 02:50:25 +0200 | <segfaultfizzbuzz> | chromoblob: i can say this, i have seen a lot of haskell abstractions written in rust, and so you can probably refer to those |
| 2023-08-30 02:51:12 +0200 | <chromoblob> | how to find? |
| 2023-08-30 02:51:47 +0200 | <segfaultfizzbuzz> | https://github.com/clintonmead/haskell_bits for example, you can find other stuff like this |
| 2023-08-30 02:52:26 +0200 | <segfaultfizzbuzz> | haskell is nonstrict, so it is often lazily evaluated,... it kinda makes a todo list as the evaluation proceeds and doesn't compute stuff unless it decides that it is necessary (or has been told to do so) |
| 2023-08-30 02:53:41 +0200 | <geekosaur> | I don't think that has much to do with replicating half of Haskell abstractions in C++. neither does GC |
| 2023-08-30 02:54:05 +0200 | <geekosaur> | what does is that C++'s type system will allow you to do things that are unsafe, whereas Haskell's will stop you |
| 2023-08-30 02:55:02 +0200 | <geekosaur> | (where "unsafe" here means will throw runtime exceptions or even crash because something is wrong that Haskell would have caught at compile time) |
| 2023-08-30 02:55:33 +0200 | <geekosaur> | ("crash" meaning dump core) |
| 2023-08-30 02:57:34 +0200 | chromoblob | (~user@37.113.172.116) (Ping timeout: 244 seconds) |
| 2023-08-30 02:57:43 +0200 | <geekosaur> | I also strongly suspect that mtl-style monad transformers … sigh |
| 2023-08-30 02:57:58 +0200 | <geekosaur> | ("are the wrong way to do it in C++") |
| 2023-08-30 02:59:58 +0200 | chromoblob | (~user@37.113.172.116) |
| 2023-08-30 03:00:37 +0200 | <chromoblob> | "clintonmead/haskell_bits" yeah lots of boilerstuff needed to use it |
| 2023-08-30 03:00:53 +0200 | <geekosaur> | https://ircbrowse.tomsmeding.com/browse/lchaskell?id=1064537#trid1064537 |
| 2023-08-30 03:00:57 +0200 | <geekosaur> | for what you missed |
| 2023-08-30 03:01:40 +0200 | <geekosaur> | not one you mentioned, but iirc rust has an STM implementation. there are a bunch of things you must not do if you want it to be reliable, but the compiler gives you zero help with that |
| 2023-08-30 03:01:53 +0200 | <geekosaur> | in Haskell you get type errors if you violate the STM contract |
| 2023-08-30 03:01:57 +0200 | <segfaultfizzbuzz> | yeah i recall seeing an STM somewhere,... i don't think it was production grade tho |
| 2023-08-30 03:02:36 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::a10) (Ping timeout: 248 seconds) |
| 2023-08-30 03:04:33 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-08-30 03:04:33 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-08-30 03:04:33 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-08-30 03:05:44 +0200 | xmachina | (~xmachina@modemcable048.127-56-74.mc.videotron.ca) |
| 2023-08-30 03:08:43 +0200 | caryhartline | (~caryhartl@168.182.58.169) |
| 2023-08-30 03:10:59 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2023-08-30 03:11:07 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 255 seconds) |
| 2023-08-30 03:12:57 +0200 | <davros1> | People get more done in Rust than Haskell. Agree/disagree ? (I'm asking in 3 places for balance) |
| 2023-08-30 03:14:00 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-08-30 03:17:06 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2023-08-30 03:17:41 +0200 | <chromoblob> | geekosaur: ok, how to do monad composition properly in C++? |
| 2023-08-30 03:20:16 +0200 | caryhartline | (~caryhartl@168.182.58.169) (Quit: caryhartline) |
| 2023-08-30 03:20:47 +0200 | <geekosaur> | ?? why are you asking me? |
| 2023-08-30 03:20:47 +0200 | <lambdabot> | Plugin `compose' failed with: user error (Unknown command: "") |
| 2023-08-30 03:21:50 +0200 | <geekosaur> | but your main problem is not that you can't write some kind of composition; it's that it will silently compose garbage that Haskell would correctly reject |
| 2023-08-30 03:22:00 +0200 | <geekosaur> | templates are not a substitute for a type system |
| 2023-08-30 03:22:45 +0200 | <geekosaur> | (I know generalities about C++; I am not a C++ programmer) |
| 2023-08-30 03:24:23 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-08-30 03:26:36 +0200 | gentauro | (~gentauro@user/gentauro) (Ping timeout: 246 seconds) |
| 2023-08-30 03:26:49 +0200 | gentauro | (~gentauro@user/gentauro) |
| 2023-08-30 03:27:03 +0200 | bratwurst | (~blaadsfa@S010610561191f5d6.lb.shawcable.net) (Remote host closed the connection) |
| 2023-08-30 03:27:28 +0200 | bratwurst | (~blaadsfa@2604:3d09:207f:f650:216:3eff:fe5a:a1f8) |
| 2023-08-30 03:29:26 +0200 | kupi | (uid212005@id-212005.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-08-30 03:29:31 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 250 seconds) |
| 2023-08-30 03:30:03 +0200 | <chromoblob> | geekosaur: because you said, "I also strongly suspect that mtl-style monad transformers", "are the wrong way to do it in C++", you don't remember? |
| 2023-08-30 03:31:03 +0200 | <geekosaur> | I said suspect, not that I'd tried it |
| 2023-08-30 03:31:17 +0200 | <geekosaur> | mostly because different languages are different |
| 2023-08-30 03:31:35 +0200 | <chromoblob> | you don't have to try, i just expect you to have an idea at least |
| 2023-08-30 03:31:46 +0200 | <chromoblob> | if you say "wrong way" |
| 2023-08-30 03:31:56 +0200 | <chromoblob> | but don't have an idea, it's weird |
| 2023-08-30 03:31:58 +0200 | <geekosaur> | you can write Haskell in C++. its performance will suck. C++ is C++, C++ idioms will work better than Haskell idioms |
| 2023-08-30 03:32:22 +0200 | <davros1> | c++ can actually do HKT right .. but it's probably not as usable or flawed in some way |
| 2023-08-30 03:32:28 +0200 | <Axman6> | davros1: If you're wondering why you aren't getting responses, it's likely because we have a pretty strong culture of not being too worried about the popularity of the language; Of course more Rust is written than Haskell, it's a language that has gained a lot popularity and has a large, active commercial backer in Mozilla. 'Avoid success at all costs' is something many of us take to heart, Haskell doesn't have to be a language for all people. |
| 2023-08-30 03:32:50 +0200 | <davros1> | Axman6, yeah I didn't mean to be confrontational, let me elaboraate |
| 2023-08-30 03:33:59 +0200 | <davros1> | For the record my apetite for Rust came from trying haskell :) but whilst it was fascinating and impressively elegant, I found it too difficult to use when dealing with IO & state; using gfx libraries was really hard; also I didn't believe a GC could handle game engines. |
| 2023-08-30 03:34:13 +0200 | <davros1> | I could see that it would have been really good at asset conditioning pipelines |
| 2023-08-30 03:34:41 +0200 | <davros1> | I had the Q in mind from someone else trash talking rust elsewhere |
| 2023-08-30 03:34:47 +0200 | <Axman6> | Not saying you're being confrontational, just that the question is kind of uninteresting, and not relevant to those of us who do (or in my case, did) write plenty of propduction code in haskell - it's popularity doesn't really affect out ability to do that |
| 2023-08-30 03:34:56 +0200 | <chromoblob> | davros1: which people, same or different? |
| 2023-08-30 03:35:04 +0200 | <geekosaur> | chromoblob, I expect that playing to the strengths of templates will work much better than trying to abuse them as typeclasses |
| 2023-08-30 03:35:09 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-08-30 03:35:29 +0200 | <davros1> | And yes Axman6 I strongly agree that popularity is not a measure of quality (I have to use that argument defending rust vs c++ alot lol) |
| 2023-08-30 03:35:30 +0200 | <geekosaur> | but playing to the strengths of templates will result in different code |
| 2023-08-30 03:36:08 +0200 | <geekosaur> | that won't really be directly comparable to the original Haskell |
| 2023-08-30 03:36:13 +0200 | <chromoblob> | geekosaur: implying templates have a narrow scope? |
| 2023-08-30 03:36:22 +0200 | <geekosaur> | implying they have a different scope |
| 2023-08-30 03:36:50 +0200 | <geekosaur> | if anything, Haskell is the narrower one, by design |
| 2023-08-30 03:38:35 +0200 | <probie> | I certainly get a lot more done in Haskell than in Rust, but it's not a fair comparison. I have a lot more experience writing Haskell than writing Rust |
| 2023-08-30 03:39:33 +0200 | <davros1> | There's times when rust might have ended up being a gateway drug to haskell (haskell did make more sense after rust) |
| 2023-08-30 03:40:39 +0200 | <davros1> | Currying is neat |
| 2023-08-30 03:41:18 +0200 | <chromoblob> | maybe there could be a deterministic, "good" GC |
| 2023-08-30 03:42:04 +0200 | <chromoblob> | also, could use some control over it |
| 2023-08-30 03:43:26 +0200 | <chromoblob> | geekosaur: so, do you use Haskell for performance? i like Haskell for very high ease and comfort of expression of code |
| 2023-08-30 03:43:49 +0200 | <chromoblob> | and i seek primarily that when i ponder Haskell-style stuff in C++ |
| 2023-08-30 03:44:01 +0200 | <chromoblob> | well OK, it's academic |
| 2023-08-30 03:44:42 +0200 | <chromoblob> | but the "performance sucking" may well be not there, at least in enough cases |
| 2023-08-30 03:44:59 +0200 | <chromoblob> | and i'm not talking about translating Haskell blindly |
| 2023-08-30 03:45:19 +0200 | <geekosaur> | most of my stuiff is in the "if it's faster than I can do it by hand then it's fast enough" category 🙂 |
| 2023-08-30 03:45:24 +0200 | <chromoblob> | but about replicating the interfaces, more closely or more roughly |
| 2023-08-30 03:47:31 +0200 | <davros1> | geekosaur If you want to write Haskell-inspired things in C++ .. maybe I could introduce you to this other language called Rust :) |
| 2023-08-30 03:47:35 +0200 | <EvanR> | this is a story I've heard before. I heard all about haskell then I couldn't figure out IO so went to rust |
| 2023-08-30 03:47:59 +0200 | <EvanR> | I looked at rust and found zero haskellisms |
| 2023-08-30 03:48:12 +0200 | <chromoblob> | really? |
| 2023-08-30 03:48:13 +0200 | <EvanR> | meanwhile I think IO is awesome |
| 2023-08-30 03:48:14 +0200 | <chromoblob> | i saw some |
| 2023-08-30 03:48:30 +0200 | <EvanR> | unfortunate that rust doesn't have IO |
| 2023-08-30 03:48:35 +0200 | <davros1> | More OOP, more imperative <--- C++ Rust Haskell --> more FP |
| 2023-08-30 03:48:36 +0200 | <chromoblob> | >:p |
| 2023-08-30 03:48:51 +0200 | <chromoblob> | Haskell is not "less imperative". |
| 2023-08-30 03:49:06 +0200 | <chromoblob> | and isn't "less OOP" as well |
| 2023-08-30 03:49:07 +0200 | <EvanR> | rust functional? lol |
| 2023-08-30 03:49:12 +0200 | <jackdk> | Haskell is my favourite imperative language. And my favourite dynamically-typed language. |
| 2023-08-30 03:49:37 +0200 | <chromoblob> | "dynamically-typed language" 😰 |
| 2023-08-30 03:49:41 +0200 | <davros1> | Remember that c++ doesnt have pattern matching, or HM inference, and that rust traits are closer to haskell type classes than c++ classes or c++ concepts |
| 2023-08-30 03:50:18 +0200 | <chromoblob> | "Remember that c++ doesnt have pattern matching" what about Visitor? >:D |
| 2023-08-30 03:50:22 +0200 | <davros1> | Its not pure functional, but its better at doing iterator chaining than C++ |
| 2023-08-30 03:50:30 +0200 | <davros1> | Thats an ugly mess IMO |
| 2023-08-30 03:50:46 +0200 | <jackdk> | The stuff you can do with `Typeable` and `Dynamic` is awesome. I'm rather proud of https://hackage.haskell.org/package/amazonka-2.0/docs/Amazonka-Env-Hooks.html |
| 2023-08-30 03:51:09 +0200 | <EvanR> | > fromDyn (toDyn "hoho!") ":(" :: String |
| 2023-08-30 03:51:10 +0200 | <lambdabot> | "hoho!" |
| 2023-08-30 03:51:40 +0200 | <EvanR> | iterator chaining is now a functional programming thing :'( |
| 2023-08-30 03:51:57 +0200 | <EvanR> | I guess python is functional |
| 2023-08-30 03:51:58 +0200 | <davros1> | Distinguish FP from PureFP |
| 2023-08-30 03:51:59 +0200 | <chromoblob> | stream fusion |
| 2023-08-30 03:52:11 +0200 | <davros1> | Many languages that aren't pure FP can do FP |
| 2023-08-30 03:52:23 +0200 | <davros1> | They can't do it to the extent of haskell |
| 2023-08-30 03:52:38 +0200 | <EvanR> | it's sad that like no language with a "fanbase" has actual function composition |
| 2023-08-30 03:52:44 +0200 | <chromoblob> | what do you mean? what's the difference? surely most languages have a pure subset? |
| 2023-08-30 03:52:48 +0200 | <EvanR> | esp when they are supposedly functional |
| 2023-08-30 03:52:52 +0200 | <probie> | What even is FP? |
| 2023-08-30 03:52:53 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
| 2023-08-30 03:52:58 +0200 | <monochrom> | My question would be how could you possibly translate "instance Functor []" (not "instance Functor [a]") to C++. Even for Haskell, someone had to write a paper ("constructor classes") before Haskell could do that. |
| 2023-08-30 03:53:04 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::4f8) |
| 2023-08-30 03:53:26 +0200 | <chromoblob> | finally, some concrete thoughts |
| 2023-08-30 03:53:31 +0200 | <EvanR> | easily, C++ has had Functors for a long time |
| 2023-08-30 03:53:36 +0200 | <monochrom> | hahahaha |
| 2023-08-30 03:53:57 +0200 | <monochrom> | I think they stopped saying "functor" a while ago |
| 2023-08-30 03:54:15 +0200 | <monochrom> | Stroustrup's book says "function object" or something now. |
| 2023-08-30 03:55:22 +0200 | otto_s | (~user@p4ff27e7b.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2023-08-30 03:56:16 +0200 | <monochrom> | That happened in 2013 or before. |
| 2023-08-30 03:57:27 +0200 | otto_s | (~user@p5de2f1e6.dip0.t-ipconnect.de) |
| 2023-08-30 03:57:55 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2023-08-30 03:58:51 +0200 | <segfaultfizzbuzz> | i am not paying close attention but also worth mentioning is that the rust and the C++ type systems are themselves (strict?) functional programming languages |
| 2023-08-30 03:59:24 +0200 | <segfaultfizzbuzz> | ...but,... i dont know, do they have like Map for rust types...? |
| 2023-08-30 04:01:14 +0200 | <monochrom> | Under that view, you only have a 1st-order language, i.e., you miss higher-order functions. |
| 2023-08-30 04:01:33 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer) |
| 2023-08-30 04:02:08 +0200 | <monochrom> | In Haskell parlance, you miss the kind * -> * |
| 2023-08-30 04:02:43 +0200 | grnman_ | (~michaelsc@c-66-176-3-51.hsd1.fl.comcast.net) |
| 2023-08-30 04:02:54 +0200 | <EvanR> | they have containers which can demand traits for the stuff you put in them, Ord or hashable or... |
| 2023-08-30 04:03:34 +0200 | <EvanR> | C++ stuff |
| 2023-08-30 04:04:33 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5185:af9c:1a37:ea21) (Remote host closed the connection) |
| 2023-08-30 04:04:48 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5185:af9c:1a37:ea21) |
| 2023-08-30 04:05:15 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-08-30 04:08:38 +0200 | <Axman6> | jackdk: we did pretty good on that hey, type safe dynamics FTW |
| 2023-08-30 04:09:16 +0200 | bratwurst | (~blaadsfa@2604:3d09:207f:f650:216:3eff:fe5a:a1f8) (Ping timeout: 248 seconds) |
| 2023-08-30 04:09:21 +0200 | <chromoblob> | so, a [].fmap takes some type parameters a and b, a function a -> b, a [a] and returns a [b]. at low level, it recreates the structure of [a], then enumerates a's, for each calls the function, and recreates the corresponding b in place by copy elision, and finally returns [b]. if one doesn't want new/malloc, then the caller should get the size of [b] by calling a static method of [], create the |
| 2023-08-30 04:09:27 +0200 | <chromoblob> | storage for [b] and pass the pointer to it to fmap so that it creates [b]'s structure in place |
| 2023-08-30 04:10:15 +0200 | <segfaultfizzbuzz> | chromoblob: btw check out kokalang |
| 2023-08-30 04:10:22 +0200 | <chromoblob> | for lazy []'s, though, ... |
| 2023-08-30 04:10:26 +0200 | <glguy> | C++ has "template template parameters" |
| 2023-08-30 04:10:48 +0200 | <chromoblob> | note that i nowhere mentioned templates in my description |
| 2023-08-30 04:10:58 +0200 | <jackdk> | Axman6: high five |
| 2023-08-30 04:11:17 +0200 | <chromoblob> | they can be used for the type parameters, but the fmap code is not templated |
| 2023-08-30 04:12:12 +0200 | <chromoblob> | so, i propose two steps, templateful type checking of calls and then templateless implementation |
| 2023-08-30 04:12:20 +0200 | <chromoblob> | best of both worlds |
| 2023-08-30 04:13:14 +0200 | <glguy> | I have no idea what you're talking about. I'm just reacting a bit to monochrom and EvanR above |
| 2023-08-30 04:13:14 +0200 | <chromoblob> | and type checking either gives compile error or passes straight to the templateless implementation, no duplication |
| 2023-08-30 04:13:58 +0200 | <EvanR> | was the original objective to have basically a list map HOF in C++ |
| 2023-08-30 04:14:11 +0200 | xff0x | (~xff0x@ai086045.d.east.v6connect.net) (Ping timeout: 260 seconds) |
| 2023-08-30 04:14:36 +0200 | danza__ | (~francesco@151.57.243.19) |
| 2023-08-30 04:17:01 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-08-30 04:17:11 +0200 | danza_ | (~francesco@151.43.239.168) (Ping timeout: 250 seconds) |
| 2023-08-30 04:17:36 +0200 | <chromoblob> | but yeah, bind is fuck |
| 2023-08-30 04:18:22 +0200 | <chromoblob> | in bind, you have to choose between sequential generation and parallel generation with subsequent copying |
| 2023-08-30 04:22:03 +0200 | <EvanR> | pretty sure this covers any FP you need to do in C https://github.com/AlexCeleste/C99-Lambda |
| 2023-08-30 04:27:39 +0200 | <hammond> | im worried about this. does having short variable names reduce readability? |
| 2023-08-30 04:28:08 +0200 | <monochrom> | It depends. |
| 2023-08-30 04:28:15 +0200 | <hammond> | i want to jst use 1 letter variables, and 1 letter functions, but im not sure. |
| 2023-08-30 04:28:38 +0200 | <EvanR> | when I use long variable names in haskell it becomes unreadable |
| 2023-08-30 04:28:46 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 260 seconds) |
| 2023-08-30 04:29:00 +0200 | <hammond> | monochrom: elucidate. I have seen haskell using a lot of one letters, but then I read these books and they say function names should be wordy and expressive. |
| 2023-08-30 04:29:15 +0200 | <hammond> | EvanR: I agree. |
| 2023-08-30 04:30:05 +0200 | ddellacosta | (~ddellacos@ool-44c738de.dyn.optonline.net) (Ping timeout: 245 seconds) |
| 2023-08-30 04:30:20 +0200 | <monochrom> | In the Java standard library there is a method "bool supportsMetadataOperationsAndDataOperations()" I very much doubt anyone actually read it. |
| 2023-08-30 04:30:33 +0200 | <hammond> | like ThisIsAVeryReadibleFunctionNameThatAddsOneIntegerToAnotherIntegerAndReturnsATotalInIntegerFormat. |
| 2023-08-30 04:30:53 +0200 | <monochrom> | I do not condone "this source says this so I follow". |
| 2023-08-30 04:31:02 +0200 | <hammond> | lol ok |
| 2023-08-30 04:31:28 +0200 | <monochrom> | If someone says "you should use long names", what is their reason? Does that reason apply to your situation? |
| 2023-08-30 04:31:33 +0200 | <EvanR> | (supportsMeta + 1)(DataOperations) |
| 2023-08-30 04:31:35 +0200 | <monochrom> | If someone says "you should use short names", what is their reason? Does that reason apply to your situation? |
| 2023-08-30 04:31:50 +0200 | <monochrom> | IOW stop worshipping idols and opinion leaders. |
| 2023-08-30 04:31:53 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 246 seconds) |
| 2023-08-30 04:32:04 +0200 | ddellacosta | (~ddellacos@ool-44c738de.dyn.optonline.net) |
| 2023-08-30 04:32:37 +0200 | falafel | (~falafel@216.68.6.51.dyn.plus.net) (Ping timeout: 246 seconds) |
| 2023-08-30 04:33:19 +0200 | <hammond> | well what if ur going to have to deal with these people at work someday you know. I'm obvs exxagerating. The thing is I noticed in Haskell they simply use very short var names, and I like that. |
| 2023-08-30 04:33:35 +0200 | <monochrom> | Here in #haskell most people will tell you why under certain contexts they should short names, and what those contexts are. |
| 2023-08-30 04:33:35 +0200 | <hammond> | verycontradictory. |
| 2023-08-30 04:33:57 +0200 | <monochrom> | No one here will say "always do X". We know it's wrong. |
| 2023-08-30 04:34:05 +0200 | <shapr> | short variable names are great when the "wiring pattern" is the important part |
| 2023-08-30 04:34:08 +0200 | <monochrom> | No one here even say "always use Haskell" for that matter. |
| 2023-08-30 04:34:26 +0200 | <shapr> | long variable names are better when you're writing "business logic" and it matters how you use the value. |
| 2023-08-30 04:34:50 +0200 | <EvanR> | swap (x,y) = (y,x) |
| 2023-08-30 04:35:03 +0200 | <shapr> | Yeah, that's a good example |
| 2023-08-30 04:36:28 +0200 | <monochrom> | Outside #haskell, the world is full of morons. Therefore they need a simple mechanical code to adhere to, blindly. |
| 2023-08-30 04:36:44 +0200 | <shapr> | I need that too when I'm learning something entirely new. |
| 2023-08-30 04:37:33 +0200 | <shapr> | I start out parroting exactly what the tutorial or introduction says to see if that works. |
| 2023-08-30 04:37:41 +0200 | <monochrom> | It also explains why those bird brains cannot understand more truthful than "big-O is for worst case, big-Omega is for best case, big-Theta is for average case". |
| 2023-08-30 04:37:47 +0200 | td_ | (~td@i5387092A.versanet.de) (Ping timeout: 246 seconds) |
| 2023-08-30 04:38:40 +0200 | <monochrom> | Unpopular opinion: "everyone needs to start somewhere" gets old quickly. It's where you end that matters. |
| 2023-08-30 04:38:55 +0200 | <hammond> | monochrom but they are trying to improve readability. |
| 2023-08-30 04:39:15 +0200 | <hammond> | "Code should read like a prose. Like a Novel." |
| 2023-08-30 04:39:26 +0200 | <monochrom> | COBOL reads like a novel. |
| 2023-08-30 04:39:35 +0200 | td_ | (~td@i53870918.versanet.de) |
| 2023-08-30 04:40:30 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 245 seconds) |
| 2023-08-30 04:40:33 +0200 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) |
| 2023-08-30 04:40:38 +0200 | <monochrom> | There is a reason why "sqrt(x + y^2) - sin (2^x - ln y)" is superior to the prose version. |
| 2023-08-30 04:41:18 +0200 | <monochrom> | or the three-address-instruction version. |
| 2023-08-30 04:41:53 +0200 | <hammond> | I understand what you are saying monochrom . I do like haskells math like syntax. |
| 2023-08-30 04:42:07 +0200 | <EvanR> | x y ^2 + sqrt 2 x ^ y ln - sin - |
| 2023-08-30 04:42:34 +0200 | <hammond> | but I'm trying to find if there is an industry standard when it comes to this. like a big blanket for all languages. |
| 2023-08-30 04:42:42 +0200 | <monochrom> | I don't even need Haskell. My anti-prose stance needs merely Fortran. |
| 2023-08-30 04:43:35 +0200 | <shapr> | hammond: I'd go with "wiring patterns are best with transparent variable names" and "business logic is best with descriptive variable names" |
| 2023-08-30 04:46:29 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-08-30 04:46:29 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2023-08-30 04:46:29 +0200 | finn_elija | FinnElija |
| 2023-08-30 04:46:35 +0200 | chromoblob | (~user@37.113.172.116) (Ping timeout: 244 seconds) |
| 2023-08-30 04:47:24 +0200 | <shapr> | if this ever becomes production hardware, it'll be perfect for graph reduction https://www.servethehome.com/intel-shows-8-core-528-thread-processor-with-silicon-photonics/ aka evaluating Haskell programs. |
| 2023-08-30 04:47:27 +0200 | <hammond> | shapr wiring patterns means what? |
| 2023-08-30 04:47:41 +0200 | <hammond> | I was making my way thru a burrito. |
| 2023-08-30 04:48:13 +0200 | <shapr> | hammond: EvanR said that "swap (x,y) = (y,x)" is a good example of a wiring pattern, and I agree. |
| 2023-08-30 04:48:34 +0200 | <shapr> | longer names for x and y would cover up the wiring pattern. |
| 2023-08-30 04:48:45 +0200 | <EvanR> | if someone says what the heck x is... tell them it's a variable |
| 2023-08-30 04:49:04 +0200 | <EvanR> | which might raise some ontological questions |
| 2023-08-30 04:49:56 +0200 | <hammond> | lol fair enough. |
| 2023-08-30 04:50:21 +0200 | <shapr> | hammond: håller du med? |
| 2023-08-30 04:53:05 +0200 | <hammond> | yeah. |
| 2023-08-30 04:53:30 +0200 | <hammond> | sure. I'm working my way thru the Refactoring book. |
| 2023-08-30 04:53:36 +0200 | <shapr> | Oh, Martin Fowler's book? |
| 2023-08-30 04:53:41 +0200 | <hammond> | yes. |
| 2023-08-30 04:53:51 +0200 | <shapr> | I might have that handy ... |
| 2023-08-30 04:54:36 +0200 | <hammond> | I like the part about making functions smaller and more concise. But it's jst the naming of things. |
| 2023-08-30 04:55:18 +0200 | <EvanR> | long naming suggestions also come from languages where you have to name more things because less composition |
| 2023-08-30 04:55:54 +0200 | <EvanR> | and naming things becomes such a chore, it starts to creep into the philosophy |
| 2023-08-30 04:56:01 +0200 | <hammond> | EvanR: are you saying you can't compose very well in OOP languages? |
| 2023-08-30 04:56:46 +0200 | <EvanR> | you're actively encouraged to do less stuff on a line and use temporaries |
| 2023-08-30 04:56:57 +0200 | <EvanR> | one action at a time |
| 2023-08-30 04:57:06 +0200 | <hammond> | heh. |
| 2023-08-30 04:57:35 +0200 | <EvanR> | the math expression is a good example of the benefits of not doing that |
| 2023-08-30 04:58:03 +0200 | <monochrom> | Merely 40 years ago "best practice" had "write more comments" leading to everyone, mostly students, writing "int i; /* this is an int variable */". |
| 2023-08-30 04:58:22 +0200 | thegeekinside | (~thegeekin@189.180.81.59) (Remote host closed the connection) |
| 2023-08-30 04:58:26 +0200 | <hammond> | yeah |
| 2023-08-30 04:58:36 +0200 | <monochrom> | It took about 30 years for the industry to finalize realize how silly it is. |
| 2023-08-30 04:58:44 +0200 | <hammond> | I mean now I jst saw somewhere don't write a lot of comments. |
| 2023-08-30 04:59:03 +0200 | <monochrom> | It may take another 30 years before the industry mature beyond "make long names". |
| 2023-08-30 04:59:26 +0200 | <hammond> | this is the stuff I never understand. which is it. |
| 2023-08-30 04:59:50 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2023-08-30 05:00:03 +0200 | sm | (~sm@plaintextaccounting/sm) (Client Quit) |
| 2023-08-30 05:02:31 +0200 | notzmv | (~zmv@user/notzmv) |
| 2023-08-30 05:06:57 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2023-08-30 05:09:50 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::4f8) (Ping timeout: 244 seconds) |
| 2023-08-30 05:13:06 +0200 | kimiamania600 | kimiamania |
| 2023-08-30 05:19:05 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 246 seconds) |
| 2023-08-30 05:19:56 +0200 | Angelz | (Angelz@Angelz.oddprotocol.org) |
| 2023-08-30 05:20:43 +0200 | libertyprime | (~libertypr@203.96.203.44) |
| 2023-08-30 05:27:07 +0200 | aforemny | (~aforemny@2001:9e8:6cd7:9700:69c9:4833:ea9a:b62d) |
| 2023-08-30 05:28:22 +0200 | aforemny_ | (~aforemny@i59F516D5.versanet.de) (Ping timeout: 255 seconds) |
| 2023-08-30 05:39:54 +0200 | razetime | (~quassel@49.207.213.87) |
| 2023-08-30 05:41:47 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
| 2023-08-30 05:42:26 +0200 | bitmapper | (uid464869@id-464869.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-08-30 05:43:19 +0200 | Jackneill_ | (~Jackneill@20014C4E1E04F90056592DA5D2139949.dsl.pool.telekom.hu) |
| 2023-08-30 05:45:47 +0200 | Jackneill | (~Jackneill@20014C4E1E1BB8003C546C11A7F363BB.dsl.pool.telekom.hu) (Ping timeout: 245 seconds) |
| 2023-08-30 05:46:30 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2023-08-30 05:55:22 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 255 seconds) |
| 2023-08-30 05:56:17 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-08-30 06:01:20 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2023-08-30 06:02:49 +0200 | bilegeek | (~bilegeek@2600:1008:b004:e71b:f993:4604:698f:bf53) (Quit: Leaving) |
| 2023-08-30 06:06:43 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2023-08-30 06:10:05 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2023-08-30 06:10:14 +0200 | hyvoid | (~hyenavoid@222-0-178-69.static.gci.net) (Remote host closed the connection) |
| 2023-08-30 06:10:18 +0200 | <shapr> | hammond: try all the way and see which one is best for reading comprehension six months from now? |
| 2023-08-30 06:10:45 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2023-08-30 06:11:56 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-08-30 06:15:10 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2023-08-30 06:15:51 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 245 seconds) |
| 2023-08-30 06:17:51 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-08-30 06:30:46 +0200 | aaronv | (~aaronv@user/aaronv) (Ping timeout: 245 seconds) |
| 2023-08-30 06:40:30 +0200 | aaronv | (~aaronv@user/aaronv) |
| 2023-08-30 06:40:37 +0200 | <haskellbridge> | <jade> monochrom: is there an inherent problem with long names? |
| 2023-08-30 06:43:41 +0200 | <Axman6> | I feel like there's an information theoretic argument to be made for the lenght of names, the more specific something is, the longer its name is allowed to be to describe that specificity, and the more general, the shorter. so foldr f z xs is totally fine, loadTriggersIntoMissles unloadedProximityTriggers delayTime postFuellingMissles is also fine |
| 2023-08-30 06:45:02 +0200 | <Axman6> | (No idea why the first specific example was missiles) |
| 2023-08-30 06:47:12 +0200 | <haskellbridge> | <jade> that's how I feel about it exactly |
| 2023-08-30 06:47:33 +0200 | <haskellbridge> | <jade> besides that, I think a lot of haskell names *could* be more descriptive |
| 2023-08-30 06:47:58 +0200 | <haskellbridge> | <jade> doesn't mean they have to be |
| 2023-08-30 06:49:04 +0200 | <monochrom> | As usual, there is no inherent problems with long names, short names, strongly encrypting your messages, weakly encrypting your messages, not encrypting your messages, ... |
| 2023-08-30 06:49:37 +0200 | <monochrom> | Human is the inherent problem of abusing those things. |
| 2023-08-30 06:50:16 +0200 | <monochrom> | I could add knives and guns, but that would morbidly be like bringing up missiles... |
| 2023-08-30 06:50:26 +0200 | <jackdk> | Axman6: we're in #haskell and there are only two haskell programs: computing fibonacci numbers with an exponential algorithm and firing the missiles |
| 2023-08-30 06:50:52 +0200 | <monochrom> | I thought we also sort and enumerate primes. :) |
| 2023-08-30 06:53:12 +0200 | <haskellbridge> | <jade> jackdk: I hate that that is always the introduction to haskell... |
| 2023-08-30 06:53:37 +0200 | <EvanR> | what about fork, read, write, exec unix API names. There's a lot to unpack there but they used 4 letter words for all the power |
| 2023-08-30 06:53:49 +0200 | <EvanR> | that's how to do it |
| 2023-08-30 06:53:53 +0200 | <monochrom> | Do you also hate using fibonacci to teach loops? |
| 2023-08-30 06:54:38 +0200 | <jackdk> | I've never had "firing the missiles" in an introduction to Haskell. It's talked about but never done |
| 2023-08-30 06:54:45 +0200 | <monochrom> | https://docs.python.org/3.5/tutorial/controlflow.html#defining-functions |
| 2023-08-30 06:54:57 +0200 | <monochrom> | @quote monochrom fibonacci |
| 2023-08-30 06:54:57 +0200 | <lambdabot> | monochrom says: the fibonacci sequence is everywhere in nature, for example haskell tutorials and python tutorials |
| 2023-08-30 06:55:05 +0200 | <haskellbridge> | <jade> oh, I've seen it |
| 2023-08-30 06:57:53 +0200 | <probie> | Has anyone used Haskell to fire missiles? |
| 2023-08-30 06:58:15 +0200 | <Axman6> | Who's responsible for haskellbridge btw? |
| 2023-08-30 07:01:19 +0200 | acidjnk | (~acidjnk@p200300d6e7072f02ccbbb6636abe1529.dip0.t-ipconnect.de) |
| 2023-08-30 07:02:52 +0200 | <jackdk> | > matterbridge operated by geekosaur |
| 2023-08-30 07:02:53 +0200 | <lambdabot> | error: |
| 2023-08-30 07:02:54 +0200 | <lambdabot> | Variable not in scope: matterbridge :: t0 -> t1 -> t2 -> terror: |
| 2023-08-30 07:02:54 +0200 | <lambdabot> | • Variable not in scope: operated |
| 2023-08-30 07:03:00 +0200 | <jackdk> | @botsnack sorry! |
| 2023-08-30 07:03:00 +0200 | <lambdabot> | :) |
| 2023-08-30 07:07:34 +0200 | <Axman6> | geekosaur: is there a reason haskellbridge adds a space after the first character of user's nicks? I get lines like "haskellbridge: <jade>oh, I've seen it" (acutally I suspect unicode sahenanigans, ssince posting that looks different form what I copied [Iand I have a feeling this will have typos I can't see until sending...])) |
| 2023-08-30 07:09:35 +0200 | <Axman6> | shapr: I'm not sure I see how that intel CPU is particularly well suited for Haskell? the STH link is very hardware focused I guess |
| 2023-08-30 07:12:01 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2023-08-30 07:13:49 +0200 | <geekosaur[c]> | It adds a zeroid space so that it doesn't pink people on both sides of the bridge |
| 2023-08-30 07:15:01 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 255 seconds) |
| 2023-08-30 07:15:57 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-08-30 07:17:57 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-08-30 07:18:58 +0200 | <glguy> | If anyone's using glirc, it has native support for rewriting matterbridge to look native |
| 2023-08-30 07:19:45 +0200 | <glguy> | add this to your server settings: message-hooks: [["matterbridge", "haskellbridge"]] |
| 2023-08-30 07:20:14 +0200 | <glguy> | (and I'm sure other clients have something similar) |
| 2023-08-30 07:20:44 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 248 seconds) |
| 2023-08-30 07:28:33 +0200 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) |
| 2023-08-30 07:32:04 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
| 2023-08-30 07:33:47 +0200 | monochrom | (trebla@216.138.220.146) (Quit: NO CARRIER) |
| 2023-08-30 07:34:15 +0200 | <Axman6> | glguy: <3 |
| 2023-08-30 07:35:46 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht) |
| 2023-08-30 07:37:16 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 248 seconds) |
| 2023-08-30 07:41:01 +0200 | <Axman6> | glguy: is a restart or glirc needed to make it work? |
| 2023-08-30 07:42:01 +0200 | son0p | (~ff@152.203.98.110) (Ping timeout: 255 seconds) |
| 2023-08-30 07:42:24 +0200 | <Axman6> | of* |
| 2023-08-30 07:42:35 +0200 | grnman_ | (~michaelsc@c-66-176-3-51.hsd1.fl.comcast.net) (Ping timeout: 246 seconds) |
| 2023-08-30 07:43:05 +0200 | son0p | (~ff@152.203.98.110) |
| 2023-08-30 07:44:36 +0200 | monochrom | (trebla@216.138.220.146) |
| 2023-08-30 07:46:14 +0200 | [Leary] | (~Leary]@user/Leary/x-0910699) (Remote host closed the connection) |
| 2023-08-30 07:46:32 +0200 | [Leary] | (~Leary]@user/Leary/x-0910699) |
| 2023-08-30 07:46:55 +0200 | <glguy> | Hmm, I think it picks up hooks when you start that connection |
| 2023-08-30 07:47:10 +0200 | <Axman6> | I'll try reconnecting |
| 2023-08-30 07:47:13 +0200 | Axman6 | (~Axman6@user/axman6) (Remote host closed the connection) |
| 2023-08-30 07:47:28 +0200 | Axman6 | (~Axman6@user/axman6) |
| 2023-08-30 07:50:04 +0200 | michalz | (~michalz@185.246.207.203) |
| 2023-08-30 07:50:54 +0200 | lzszt | (~lzszt@ip-037-024-119-190.um08.pools.vodafone-ip.de) |
| 2023-08-30 07:52:30 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-30 07:53:01 +0200 | idgaen | (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-08-30 07:54:29 +0200 | aaronv | (~aaronv@user/aaronv) (Ping timeout: 246 seconds) |
| 2023-08-30 07:55:05 +0200 | lzszt | (~lzszt@ip-037-024-119-190.um08.pools.vodafone-ip.de) (Client Quit) |
| 2023-08-30 07:57:01 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 260 seconds) |
| 2023-08-30 07:57:15 +0200 | mima | (~mmh@net-93-67-213-89.cust.vodafonedsl.it) |
| 2023-08-30 07:57:56 +0200 | td_ | (~td@i53870918.versanet.de) (Quit: waking up from the american dream ...) |
| 2023-08-30 08:00:53 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-30 08:06:19 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2023-08-30 08:06:34 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-08-30 08:07:01 +0200 | MQ-17J | (~MQ-17J@104.28.248.165) |
| 2023-08-30 08:07:09 +0200 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection) |
| 2023-08-30 08:07:59 +0200 | MajorBiscuit | (~MajorBisc@62-137-46.netrun.cytanet.com.cy) |
| 2023-08-30 08:10:07 +0200 | echoreply | (~echoreply@2001:19f0:9002:1f3b:5400:ff:fe6f:8b8d) (Quit: WeeChat 2.8) |
| 2023-08-30 08:10:14 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 246 seconds) |
| 2023-08-30 08:10:25 +0200 | MajorBiscuit | (~MajorBisc@62-137-46.netrun.cytanet.com.cy) (Client Quit) |
| 2023-08-30 08:10:59 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-08-30 08:11:01 +0200 | echoreply | (~echoreply@45.32.163.16) |
| 2023-08-30 08:13:45 +0200 | gmg | (~user@user/gehmehgeh) |
| 2023-08-30 08:14:05 +0200 | danza__ | (~francesco@151.57.243.19) (Read error: Connection reset by peer) |
| 2023-08-30 08:14:25 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 255 seconds) |
| 2023-08-30 08:14:35 +0200 | danza__ | (~francesco@151.19.250.182) |
| 2023-08-30 08:14:53 +0200 | MQ-17J | (~MQ-17J@104.28.248.165) (Quit: Quit) |
| 2023-08-30 08:18:35 +0200 | phma | (~phma@2001:5b0:211b:8ab8:276e:326e:f44c:81b4) |
| 2023-08-30 08:20:09 +0200 | Maeda | (~Maeda@91-161-10-149.subs.proxad.net) (Quit: done!) |
| 2023-08-30 08:22:46 +0200 | chele | (~chele@user/chele) |
| 2023-08-30 08:22:59 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-30 08:26:04 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-08-30 08:27:01 +0200 | Square | (~Square4@user/square) (Ping timeout: 255 seconds) |
| 2023-08-30 08:27:24 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 248 seconds) |
| 2023-08-30 08:27:52 +0200 | <phma> | If I just say "stack run", what optimization does ghc do? |
| 2023-08-30 08:30:41 +0200 | <haskellbridge> | <sm> the default I'd guess, adding -v may show the ghc command |
| 2023-08-30 08:31:24 +0200 | <sm> | davros1: |
| 2023-08-30 08:31:33 +0200 | <sm> | > <davros1> People get more done in Rust than Haskell. Agree/disagree ? (I'm asking in 3 places for balance) |
| 2023-08-30 08:31:33 +0200 | <sm> | It's |
| 2023-08-30 08:31:35 +0200 | <lambdabot> | <hint>:1:1: error: parse error on input ‘<’ |
| 2023-08-30 08:31:43 +0200 | <sm> | darnit irc. |
| 2023-08-30 08:33:06 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:3f4f:3d1f:233a:c3d3) |
| 2023-08-30 08:34:58 +0200 | <sm> | davros1: it's a reasonable question to think about. It needs a bit of clarifying, as it can be interpreted in a few ways. Eg "has the rust community got more done than the haskell community".. "does an average rust user get more done than an average haskell user as of today".. define "get more done".. etc. |
| 2023-08-30 08:35:33 +0200 | <phma> | sm: I don't know, but I'm writing the program in both Rust and Haskell and checking that the outputs match. |
| 2023-08-30 08:36:59 +0200 | <sm> | nice |
| 2023-08-30 08:36:59 +0200 | <phma> | Using stack, how can I compile the program and see the compiled code? I'm not sure whether I should look at Core, STG, or what. |
| 2023-08-30 08:39:13 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-08-30 08:39:19 +0200 | <sm> | phma: are you trying to check how your code was optimised ? |
| 2023-08-30 08:39:39 +0200 | <probie> | Personally, I add {-# OPTIONS_GHC -ddump-simpl #-} to the source files I want to see the core of, since it's pretty much never the case that I want it for an entire project |
| 2023-08-30 08:41:36 +0200 | <phma> | sm: yes. I have four operations that transform an unboxed array of bytes into another unboxed array of bytes, and one is taking a lot longer than the others (and than the Rust version), and I want to see why. |
| 2023-08-30 08:42:56 +0200 | <probie> | You may also want -ddump-rule-firings if you're doing something "fancy" like writing your own fusion framework |
| 2023-08-30 08:42:59 +0200 | <phma> | probie: before or after "module", before or after the imports? |
| 2023-08-30 08:43:13 +0200 | <phma> | what's a fusion framework? |
| 2023-08-30 08:43:58 +0200 | aaronv | (~aaronv@user/aaronv) |
| 2023-08-30 08:43:58 +0200 | fweht | (uid404746@id-404746.lymington.irccloud.com) |
| 2023-08-30 08:44:29 +0200 | <probie> | Before module. Where you'd put `{-# LANGUAGE ... #-}` |
| 2023-08-30 08:45:54 +0200 | <phma> | where do I find the output of --dump-simpl? |
| 2023-08-30 08:46:21 +0200 | <probie> | It'll be written to stdout |
| 2023-08-30 08:48:56 +0200 | aeroplane | (~user@user/aeroplane) |
| 2023-08-30 08:49:09 +0200 | <phma> | found it and pasted into a text editor |
| 2023-08-30 08:51:49 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-30 08:52:55 +0200 | td_ | (~td@i5387090D.versanet.de) |
| 2023-08-30 08:53:34 +0200 | <phma> | can't make sense of it though |
| 2023-08-30 08:54:26 +0200 | <probie> | sad |
| 2023-08-30 08:56:44 +0200 | <davros1> | Sm for context I was venting after a haskeller was trash talking rust. I'm not hostile to haskell, infact initially tinkering with haskell is exactly what made me want rust ("closer to haskell but still suitable for game engines") |
| 2023-08-30 08:56:58 +0200 | <davros1> | Anyway I dont want to derail the room etc |
| 2023-08-30 08:57:10 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 255 seconds) |
| 2023-08-30 08:57:52 +0200 | <haskellbridge> | <sm> you're not.. it's topical right now with recent blogosphere discussion |
| 2023-08-30 08:58:09 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2023-08-30 08:58:33 +0200 | <haskellbridge> | <sm> what's getting more done to you ? delivering useful end-user apps ? delivering useful programming tools ? advancing the state of the art ? |
| 2023-08-30 08:58:52 +0200 | paul_j | (~user@67.26.169.217.in-addr.arpa) |
| 2023-08-30 08:59:20 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-08-30 09:02:33 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5185:af9c:1a37:ea21) (Remote host closed the connection) |
| 2023-08-30 09:02:45 +0200 | <phma> | probie: https://gist.github.com/phma/04d8a493eb1d96e68739e4d989e51042 |
| 2023-08-30 09:03:51 +0200 | chromoblob | (~user@37.113.172.116) |
| 2023-08-30 09:03:52 +0200 | <phma> | and here's the source: https://github.com/phma/wring-twistree/blob/master/src/Cryptography/WringTwistree/RotBitcount.hs |
| 2023-08-30 09:08:32 +0200 | chromoblob | (~user@37.113.172.116) (Ping timeout: 244 seconds) |
| 2023-08-30 09:09:15 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
| 2023-08-30 09:11:00 +0200 | aaronv | (~aaronv@user/aaronv) (Ping timeout: 246 seconds) |
| 2023-08-30 09:19:31 +0200 | fendor | (~fendor@2a02:8388:1640:be00:29b8:807b:7fa6:1bcf) |
| 2023-08-30 09:25:05 +0200 | oo_miguel | (~Thunderbi@78-11-179-96.static.ip.netia.com.pl) (Quit: oo_miguel) |
| 2023-08-30 09:25:48 +0200 | <davros1> | haskellbridge, right even if people dont use haskell.. it proved some ideas that have made their way out into other languages |
| 2023-08-30 09:31:22 +0200 | danza__ | (~francesco@151.19.250.182) (Ping timeout: 255 seconds) |
| 2023-08-30 09:32:30 +0200 | danse-nr3 | (~francesco@151.19.250.182) |
| 2023-08-30 09:34:06 +0200 | aeroplane | (~user@user/aeroplane) (Ping timeout: 246 seconds) |
| 2023-08-30 09:34:13 +0200 | CiaoSen | (~Jura@2a05:5800:2a1:b500:664b:f0ff:fe37:9ef) |
| 2023-08-30 09:38:49 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5185:af9c:1a37:ea21) |
| 2023-08-30 09:47:59 +0200 | <danse-nr3> | :t Map |
| 2023-08-30 09:48:00 +0200 | <lambdabot> | error: |
| 2023-08-30 09:48:00 +0200 | <lambdabot> | • Data constructor not in scope: Map |
| 2023-08-30 09:48:00 +0200 | <lambdabot> | • Perhaps you meant one of these: |
| 2023-08-30 09:48:12 +0200 | <danse-nr3> | % import Data.Map |
| 2023-08-30 09:48:12 +0200 | <yahb2> | <no output> |
| 2023-08-30 09:48:16 +0200 | <danse-nr3> | :t Map |
| 2023-08-30 09:48:17 +0200 | <lambdabot> | error: |
| 2023-08-30 09:48:17 +0200 | <lambdabot> | • Data constructor not in scope: Map |
| 2023-08-30 09:48:17 +0200 | <lambdabot> | • Perhaps you meant one of these: |
| 2023-08-30 09:48:25 +0200 | <danse-nr3> | % :t Map |
| 2023-08-30 09:48:25 +0200 | <yahb2> | <interactive>:1:1: error: ; • Illegal term-level use of the type constructor ‘Map’ ; imported from ‘Data.Map’ ; (and originally defined in ‘Data.Map.Internal’) ; • In the ex... |
| 2023-08-30 09:48:34 +0200 | <danse-nr3> | %:t Map |
| 2023-08-30 09:49:10 +0200 | <danse-nr3> | % :k Map |
| 2023-08-30 09:49:10 +0200 | <yahb2> | Map :: * -> * -> * |
| 2023-08-30 09:50:51 +0200 | <danse-nr3> | yesterday i stumbled upon a problem that seemed harder than expected, but hopefully there is a trivial solution i had not thought about |
| 2023-08-30 09:51:22 +0200 | <danse-nr3> | % data P = P { i :: Map Int String, c :: Map Char String } |
| 2023-08-30 09:51:22 +0200 | <yahb2> | <no output> |
| 2023-08-30 09:51:22 +0200 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2023-08-30 09:52:02 +0200 | gmg | (~user@user/gehmehgeh) |
| 2023-08-30 09:52:08 +0200 | <danse-nr3> | if i have got `Either Int Char`, how to write a function that abstract over the Either and P in order to have an index and corresponding map to be passed to other functions? |
| 2023-08-30 09:52:49 +0200 | <danse-nr3> | i am afraid i cannot solve it without a class |
| 2023-08-30 09:54:13 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-08-30 09:55:47 +0200 | robosexual | (~spaceoyst@5.165.11.54) |
| 2023-08-30 09:55:58 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-08-30 09:56:21 +0200 | <danse-nr3> | (a -> Map a String -> c) -> Either Int Char -> c |
| 2023-08-30 09:56:38 +0200 | <danse-nr3> | would not work, for instance, because `a` cannot be both Int and Char i think |
| 2023-08-30 09:56:59 +0200 | razetime | (~quassel@49.207.213.87) (Ping timeout: 246 seconds) |
| 2023-08-30 09:58:05 +0200 | <ncf> | i'm confused |
| 2023-08-30 09:58:18 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2023-08-30 09:58:55 +0200 | <danse-nr3> | yeah the latter signature is a bit confusing |
| 2023-08-30 09:59:10 +0200 | <ncf> | \ e -> case e of Left ii -> i Map.! ii; Right ic -> c Map.! ic |
| 2023-08-30 09:59:43 +0200 | <danse-nr3> | i am not familiar with this syntax ... .! |
| 2023-08-30 09:59:43 +0200 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2023-08-30 10:00:09 +0200 | <ncf> | i ! ii except you usually import Data.Map qualified as Map |
| 2023-08-30 10:00:28 +0200 | gmg | (~user@user/gehmehgeh) |
| 2023-08-30 10:00:46 +0200 | <danse-nr3> | yeah, so, let us say sometimes we want to use lookup, other times insert, basically all Map functions, we want to abstract over them |
| 2023-08-30 10:01:10 +0200 | <ncf> | sounds like you should have a Map (Either Int Char) String then? |
| 2023-08-30 10:01:21 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) |
| 2023-08-30 10:01:28 +0200 | <danse-nr3> | yes, cannot do that in this context |
| 2023-08-30 10:01:35 +0200 | <sm> | davros1: I'm not trying to push back on your question, but to think about the answer(s). I don't know rust well enough, but my guesses would be: for advancing the state of the art: haskell, more so; as a vehicle for further research: haskell; for learning FP (haskell); programming tools (not sure); end user apps (still not sure; rust has matrix, haskell has cardano); use in industry (presumably rust ?); learning |
| 2023-08-30 10:02:26 +0200 | <sm> | as a first programming language: haskell |
| 2023-08-30 10:02:29 +0200 | apteryx | (~maxim@dsl-10-132-204.b2b2c.ca) (Ping timeout: 246 seconds) |
| 2023-08-30 10:02:37 +0200 | MajorBiscuit | (~MajorBisc@c-001-010-057.client.tudelft.eduvpn.nl) |
| 2023-08-30 10:02:43 +0200 | <ncf> | danse-nr3: why not? |
| 2023-08-30 10:02:57 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-30 10:03:20 +0200 | <sm> | as a productive personal computing language/ecosystem: not sure, depends what you've learned |
| 2023-08-30 10:03:29 +0200 | <danse-nr3> | let us say we cannot change P, or anyways that the problem is interesting in theory besides this instance |
| 2023-08-30 10:03:31 +0200 | <ncf> | Map.fromList $ [(Left k, v) | (k, v) <- Map.assocs i] <> [(Right k, v) | (k, v) <- Map.assocs c] |
| 2023-08-30 10:03:33 +0200 | <davros1> | Yeah really it depends on domain |
| 2023-08-30 10:03:43 +0200 | <danse-nr3> | in an wrongly typed mind we would like to return `Either Int Char -> P -> (a, Map a String)`, but that does not compile |
| 2023-08-30 10:04:42 +0200 | <ncf> | that could work with existentials |
| 2023-08-30 10:04:55 +0200 | <danse-nr3> | interesting! |
| 2023-08-30 10:05:59 +0200 | fserucas_ | (~fserucas@46.50.115.39) |
| 2023-08-30 10:06:57 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2023-08-30 10:07:11 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 246 seconds) |
| 2023-08-30 10:08:14 +0200 | <ncf> | like data Ex = forall k. Ex k (Map k String) or whatever. but i really don't see what this brings you |
| 2023-08-30 10:09:16 +0200 | remexre | (~remexre@user/remexre) (Ping timeout: 248 seconds) |
| 2023-08-30 10:11:16 +0200 | <danse-nr3> | it does not happen often to me that the type system gets on the way of a very simple solution, so it is an opportunity to deepen |
| 2023-08-30 10:12:07 +0200 | <[Leary]> | I could perhaps see some use in something like `Functor f => Either Int Char -> P -> (forall k. k -> Map k String -> f (Map k String)) -> f P`. |
| 2023-08-30 10:12:36 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2023-08-30 10:12:49 +0200 | <danse-nr3> | yeah that would be one of the use cases |
| 2023-08-30 10:13:12 +0200 | <danse-nr3> | but i tried to shrink to the simplest case |
| 2023-08-30 10:13:59 +0200 | <lortabac> | danse-nr3: I don't understand what you are trying to achieve |
| 2023-08-30 10:14:33 +0200 | <danse-nr3> | data P = P { i :: Map Int String, c :: Map Char String } and Either Int Char, abstract to be able to apply Map functions with Either as a key |
| 2023-08-30 10:14:37 +0200 | <lortabac> | lookupIC :: Ord a => Either Int Char -> P -> Maybe String |
| 2023-08-30 10:14:49 +0200 | <lortabac> | can't you just define something like that? ↑ |
| 2023-08-30 10:15:07 +0200 | <danse-nr3> | yes, and one for each Map function. Is there a way to abstract? |
| 2023-08-30 10:15:42 +0200 | <danse-nr3> | i think there is with a class, but seems overkill |
| 2023-08-30 10:15:55 +0200 | apteryx | (~maxim@dsl-10-128-23.b2b2c.ca) |
| 2023-08-30 10:16:22 +0200 | <lortabac> | danse-nr3: ok I see, let me think |
| 2023-08-30 10:16:29 +0200 | <ncf> | i honestly don't think there is a better abstraction here than making an Iso P (Maybe (Either Int Char) String) as i described |
| 2023-08-30 10:17:11 +0200 | <danse-nr3> | if this was untyped, the solution would be trivial |
| 2023-08-30 10:17:38 +0200 | <danse-nr3> | but we cannot have `(a, Map a String)` as a result |
| 2023-08-30 10:18:15 +0200 | <tomsmeding> | in order to abstract here, you need to have information about P in whatever framework of generic programming that you're going to use |
| 2023-08-30 10:18:24 +0200 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) |
| 2023-08-30 10:18:28 +0200 | <danse-nr3> | just plain haskell |
| 2023-08-30 10:18:39 +0200 | <tomsmeding> | as-is, the fact that P has two fields doesn't help |
| 2023-08-30 10:18:54 +0200 | <tomsmeding> | if P had a Generic instance, for example, one could write some GHC Generics code to generate lookupIC for you |
| 2023-08-30 10:19:07 +0200 | <tomsmeding> | one could also use TemplateHaskell to generate the function for you |
| 2023-08-30 10:19:48 +0200 | <tomsmeding> | I'm not familiar with optics/lens, or uniplate or what have you, but I'd expect there to be some generation utilities there as well -- as long as P implements a particular class provided by those frameworks |
| 2023-08-30 10:19:57 +0200 | <tomsmeding> | (which can probably be automatically derived using more utilities from the frameworks) |
| 2023-08-30 10:20:17 +0200 | tv | (~tv@user/tv) (Read error: Connection reset by peer) |
| 2023-08-30 10:20:20 +0200 | <danse-nr3> | too complicated for such a trivial problem, i am just trying to understand the limitations of the type system really. We cannot return an `a`, usually in similar cases i try to pass functions that consume the `a` and return an homogeneous case |
| 2023-08-30 10:20:41 +0200 | <danse-nr3> | (a -> Map a String -> c) -> Either Int Char -> P -> c |
| 2023-08-30 10:20:54 +0200 | <danse-nr3> | would not work though because `a` cannot be of two different types |
| 2023-08-30 10:21:06 +0200 | <[Leary]> | danse-nr3: This is exactly what my suggestion addressed. |
| 2023-08-30 10:21:14 +0200 | <[Leary]> | Note the forall. |
| 2023-08-30 10:21:16 +0200 | <tomsmeding> | that would need to be (forall a. a -> Map a String -> c) -> Either Int Char -> P -> c |
| 2023-08-30 10:21:29 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2023-08-30 10:21:40 +0200 | <danse-nr3> | wow, that simple? Awesome, let me try |
| 2023-08-30 10:21:59 +0200 | <tomsmeding> | without the forall, we choose the 'a'; with the forall, the '(forall ...) -> E -> P -> c' function can choose the 'a' |
| 2023-08-30 10:22:20 +0200 | <tomsmeding> | because you declare that the (a -> Map a String -> c) function doesn't only work with a particular 'a' that the caller chose, but with _all_ 'a' |
| 2023-08-30 10:22:21 +0200 | <ncf> | exists a. (a, Map a String) ~ forall c. (exists a. (a, Map a String) -> c) -> c ~ forall c. (forall a. a -> Map a String -> c) -> c |
| 2023-08-30 10:22:40 +0200 | <tomsmeding> | but you didn't do anything, because that a -> Map a String -> c is just Map.lookup |
| 2023-08-30 10:22:51 +0200 | <danse-nr3> | it can also be insert |
| 2023-08-30 10:23:01 +0200 | <tomsmeding> | oh that's true |
| 2023-08-30 10:23:11 +0200 | <tomsmeding> | but the information about P is still contained in your hand-coded implementation of this function |
| 2023-08-30 10:23:28 +0200 | <danse-nr3> | yeah that is fine |
| 2023-08-30 10:23:39 +0200 | <ncf> | (shouldn't that be String -> Map a String -> c, if you want to be able to look up values?) |
| 2023-08-30 10:23:58 +0200 | <tomsmeding> | (don't you need a key to be able to do a lookup) |
| 2023-08-30 10:24:19 +0200 | <ncf> | well you pass the key as an Either IIUC |
| 2023-08-30 10:24:31 +0200 | <ncf> | a key, and a continuation that takes a value and the surrounding map |
| 2023-08-30 10:24:33 +0200 | <tomsmeding> | ncf: which will then be passed on to the forall-qualified callback |
| 2023-08-30 10:24:49 +0200 | <danse-nr3> | a -> Map a String, `a` is a key that gets filled from the Either |
| 2023-08-30 10:24:59 +0200 | <[Leary]> | Note that it actually can't be `insert`, because then `a` would escape the scope. |
| 2023-08-30 10:25:02 +0200 | <ncf> | but that's silly, you already have the key if you passed it to the function |
| 2023-08-30 10:25:24 +0200 | <tomsmeding> | if the whole thing is f, then valid uses might be 1. f Map.lookup someKey someP, or 2. f (flip Map.insert value) someKey someP |
| 2023-08-30 10:25:30 +0200 | <danse-nr3> | [Leary], the value can be filled before passing to the abstracting function |
| 2023-08-30 10:25:54 +0200 | <tomsmeding> | I mean, I agree that this is a lot of work for little benefit, but it _is_ consistent :p |
| 2023-08-30 10:26:16 +0200 | <ncf> | ah, i see |
| 2023-08-30 10:26:27 +0200 | <ncf> | well insert won't work for the reason [Leary] says |
| 2023-08-30 10:26:35 +0200 | <[Leary]> | No, my point is that if you use `forall c. ... (forall a. a -> Map a String -> c)`, then you're not allowed to instantiate `c` as anything with `a` in it, like `Map a String`. |
| 2023-08-30 10:26:46 +0200 | <tomsmeding> | [Leary]: but 'a' is the key? |
| 2023-08-30 10:26:56 +0200 | <tomsmeding> | oh |
| 2023-08-30 10:26:58 +0200 | <tomsmeding> | sneaky |
| 2023-08-30 10:27:04 +0200 | <danse-nr3> | really? Why would `c` not possibly contain `a`, that is odd |
| 2023-08-30 10:27:08 +0200 | <[Leary]> | The signature I wrote above will let you do insert, however. |
| 2023-08-30 10:27:18 +0200 | <danse-nr3> | oh |
| 2023-08-30 10:27:20 +0200 | <tomsmeding> | danse-nr3: because f is now choosing 'a', and the caller has no access to it |
| 2023-08-30 10:27:35 +0200 | jespada | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) (Ping timeout: 244 seconds) |
| 2023-08-30 10:27:49 +0200 | <tomsmeding> | [Leary]: with the lens-style-ish Functor? |
| 2023-08-30 10:28:03 +0200 | <[Leary]> | Yeah. |
| 2023-08-30 10:28:11 +0200 | <danse-nr3> | is the `forall c` necessary? |
| 2023-08-30 10:28:28 +0200 | <danse-nr3> | after resolving the Either, the rest is homogeneous |
| 2023-08-30 10:28:51 +0200 | <tomsmeding> | after resolving the Either _and_ matching it to a field of the P |
| 2023-08-30 10:29:16 +0200 | <tomsmeding> | the only abstraction contained in f at this point is "do some unknown operation on a Map" |
| 2023-08-30 10:29:32 +0200 | <tomsmeding> | uh, awkward phrasing -- the only abstraction we're using here |
| 2023-08-30 10:29:34 +0200 | <danse-nr3> | "on the right Map for the valid value" |
| 2023-08-30 10:29:42 +0200 | <tomsmeding> | f is providing the information about P, in a sense |
| 2023-08-30 10:29:58 +0200 | <tomsmeding> | but sure |
| 2023-08-30 10:30:36 +0200 | rachelambda | (~rachelamb@78-67-128-99-no247.tbcn.telia.com) (Ping timeout: 248 seconds) |
| 2023-08-30 10:30:40 +0200 | tomsmeding | would just write lookupP :: Either Int Char -> P -> String and insertP :: EitherIntChar -> String -> P -> P and call it a day |
| 2023-08-30 10:30:48 +0200 | jespada | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) |
| 2023-08-30 10:31:13 +0200 | <danse-nr3> | yes, i think the core of the problem was relaxing `a` with `forall`, i will work on that path, thanks everyone! |
| 2023-08-30 10:31:42 +0200 | briandaed | (~briandaed@185.234.210.211.r.toneticgroup.pl) |
| 2023-08-30 10:32:00 +0200 | razetime | (~quassel@49.207.213.87) |
| 2023-08-30 10:32:08 +0200 | <danse-nr3> | also curious to check about `exists`, could be a key for a different approach |
| 2023-08-30 10:32:52 +0200 | <lortabac> | I don't think you would gain much with existentials |
| 2023-08-30 10:33:08 +0200 | <lortabac> | because you would have to pattern-match on the result anyway |
| 2023-08-30 10:33:13 +0200 | <tomsmeding> | they're a bit awkward in haskell, so they really need to carry their weight to be useful |
| 2023-08-30 10:36:12 +0200 | tv | (~tv@user/tv) |
| 2023-08-30 10:36:33 +0200 | <danse-nr3> | yes, that was the solution, thanks [Leary] for pointing to it. I kept it simple without the functor. `forall a` was all i needed, no `forall c` and no problems with that |
| 2023-08-30 10:36:58 +0200 | <[Leary]> | The forall c. is still there, it's just implicit. |
| 2023-08-30 10:37:17 +0200 | <[Leary]> | And the functor needs to be there if you want to extract information from the Map. |
| 2023-08-30 10:37:19 +0200 | <lortabac> | how can you define 'insert' without the functor? |
| 2023-08-30 10:38:25 +0200 | <lortabac> | probably the simplest solution is to distinguish lookup-like functions and insert-like functions (which return a map) |
| 2023-08-30 10:39:21 +0200 | <danse-nr3> | f :: (forall a . a -> (P -> Map a String) -> c) -> Either Int Char -> c |
| 2023-08-30 10:39:24 +0200 | <danse-nr3> | f g (Left v) = f v i |
| 2023-08-30 10:39:27 +0200 | <danse-nr3> | f g (Right v) = f v c |
| 2023-08-30 10:39:31 +0200 | <danse-nr3> | compiles and works |
| 2023-08-30 10:40:01 +0200 | <danse-nr3> | sorry, the `g` is also on the right side |
| 2023-08-30 10:40:26 +0200 | <danse-nr3> | had to simplify from my specific example on the fly |
| 2023-08-30 10:41:22 +0200 | <[Leary]> | That will let you lookup, but not insert. |
| 2023-08-30 10:45:04 +0200 | <danse-nr3> | it might take a while for me to verify and report back ... |
| 2023-08-30 10:48:31 +0200 | <danse-nr3> | yes it works with insert as well, i just have to include the value before passing the function |
| 2023-08-30 10:51:57 +0200 | <danse-nr3> | not the best abstraction, but what matters is understanding how the usage of `forall` enables us to solve a problem |
| 2023-08-30 11:01:06 +0200 | sm | (~sm@plaintextaccounting/sm) (Quit: sm) |
| 2023-08-30 11:02:37 +0200 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Remote host closed the connection) |
| 2023-08-30 11:02:56 +0200 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) |
| 2023-08-30 11:03:35 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
| 2023-08-30 11:03:44 +0200 | renegade | (~renegade@bcdcac82.skybroadband.com) (Ping timeout: 246 seconds) |
| 2023-08-30 11:03:50 +0200 | rachelambda | (~rachelamb@78-67-128-99-no247.tbcn.telia.com) |
| 2023-08-30 11:04:09 +0200 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) (Remote host closed the connection) |
| 2023-08-30 11:04:51 +0200 | chromoblob | (~user@37.113.172.116) |
| 2023-08-30 11:07:44 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::4f8) |
| 2023-08-30 11:09:39 +0200 | renegade | (~renegade@bcdcac82.skybroadband.com) |
| 2023-08-30 11:10:21 +0200 | chromoblob | (~user@37.113.172.116) (Ping timeout: 245 seconds) |
| 2023-08-30 11:11:08 +0200 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) |
| 2023-08-30 11:13:04 +0200 | remexre | (~remexre@user/remexre) |
| 2023-08-30 11:16:14 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2023-08-30 11:17:11 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-08-30 11:17:17 +0200 | Feuermagier | (~Feuermagi@user/feuermagier) (Quit: Leaving) |
| 2023-08-30 11:22:31 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 245 seconds) |
| 2023-08-30 11:25:01 +0200 | qqq | (~qqq@92.43.167.61) (Remote host closed the connection) |
| 2023-08-30 11:27:11 +0200 | danse-nr3 | (~francesco@151.19.250.182) (Remote host closed the connection) |
| 2023-08-30 11:27:33 +0200 | danse-nr3 | (~francesco@151.19.250.182) |
| 2023-08-30 11:27:44 +0200 | <danse-nr3> | [Leary], if you meant that i cannot modify P.i or P.c in place, you are right. Was using selectors here for simplicity, but had lenses in the original code |
| 2023-08-30 11:30:55 +0200 | chromoblob | (~user@37.113.172.116) |
| 2023-08-30 11:37:52 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2023-08-30 11:41:23 +0200 | <danse-nr3> | so yeah you had guessed right with the functor providing a better abstraction |
| 2023-08-30 11:45:36 +0200 | idgaen | (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.0.2) |
| 2023-08-30 11:46:54 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
| 2023-08-30 11:47:52 +0200 | <Inst> | what's wrong with |
| 2023-08-30 11:48:10 +0200 | <Inst> | swap (aFirst, aSecond) = (aSecond, aFirst) |
| 2023-08-30 11:48:52 +0200 | <ncf> | you tell us |
| 2023-08-30 11:51:19 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz) |
| 2023-08-30 11:51:41 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2023-08-30 11:54:06 +0200 | razetime | (~quassel@49.207.213.87) (Ping timeout: 246 seconds) |
| 2023-08-30 11:54:57 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-30 11:58:35 +0200 | ft | (~ft@p508db658.dip0.t-ipconnect.de) (Quit: leaving) |
| 2023-08-30 11:59:34 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 246 seconds) |
| 2023-08-30 12:01:17 +0200 | CiaoSen | (~Jura@2a05:5800:2a1:b500:664b:f0ff:fe37:9ef) (Ping timeout: 246 seconds) |
| 2023-08-30 12:01:21 +0200 | <chromoblob> | <s>when good GC is here, tho, what's wrong with "always use Haskell" lul</s> |
| 2023-08-30 12:01:55 +0200 | <chromoblob> | well, that and granular inclusion of the runtime and std libs by only needed code |
| 2023-08-30 12:03:42 +0200 | ubert | (~Thunderbi@77.119.173.8.wireless.dyn.drei.com) (Ping timeout: 245 seconds) |
| 2023-08-30 12:03:42 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 246 seconds) |
| 2023-08-30 12:05:30 +0200 | ubert | (~Thunderbi@77.119.173.8.wireless.dyn.drei.com) |
| 2023-08-30 12:05:35 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2023-08-30 12:06:10 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 255 seconds) |
| 2023-08-30 12:07:31 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 255 seconds) |
| 2023-08-30 12:09:16 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::4f8) (Ping timeout: 248 seconds) |
| 2023-08-30 12:09:53 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
| 2023-08-30 12:14:34 +0200 | danse-nr3_ | (~francesco@151.37.129.27) |
| 2023-08-30 12:14:37 +0200 | danse-nr3 | (~francesco@151.19.250.182) (Read error: Connection reset by peer) |
| 2023-08-30 12:19:35 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) (Ping timeout: 246 seconds) |
| 2023-08-30 12:25:03 +0200 | anselmschueler | (~anselmsch@user/schuelermine) |
| 2023-08-30 12:27:26 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2023-08-30 12:33:45 +0200 | sm | (~sm@plaintextaccounting/sm) (Quit: sm) |
| 2023-08-30 12:44:40 +0200 | pieguy128 | (~pieguy128@65.93.194.136) (Ping timeout: 245 seconds) |
| 2023-08-30 12:45:35 +0200 | __monty__ | (~toonn@user/toonn) |
| 2023-08-30 12:49:39 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-30 12:49:52 +0200 | lottaquestions_ | (~nick@modemcable010.180-202-24.mc.videotron.ca) |
| 2023-08-30 12:51:44 +0200 | lottaquestions | (~nick@modemcable010.180-202-24.mc.videotron.ca) (Ping timeout: 244 seconds) |
| 2023-08-30 12:52:48 +0200 | lottaquestions_ | (~nick@modemcable010.180-202-24.mc.videotron.ca) (Read error: Connection reset by peer) |
| 2023-08-30 12:53:13 +0200 | lottaquestions_ | (~nick@2607:fa49:503d:b200:d5e6:66af:52b4:3a41) |
| 2023-08-30 12:53:17 +0200 | anselmschueler | (~anselmsch@user/schuelermine) (Ping timeout: 245 seconds) |
| 2023-08-30 12:54:05 +0200 | pieguy128 | (~pieguy128@bras-base-mtrlpq5031w-grc-46-67-70-100-114.dsl.bell.ca) |
| 2023-08-30 12:54:19 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 255 seconds) |
| 2023-08-30 12:58:01 +0200 | hiyori | (~hiyori@user/hiyori) |
| 2023-08-30 12:58:03 +0200 | <hiyori> | https://bpa.st/BGQ2M |
| 2023-08-30 12:59:38 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-08-30 13:02:05 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-08-30 13:02:27 +0200 | libertyprime | (~libertypr@203.96.203.44) (Quit: leaving) |
| 2023-08-30 13:02:51 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2023-08-30 13:08:21 +0200 | sm | (~sm@plaintextaccounting/sm) (Remote host closed the connection) |
| 2023-08-30 13:08:41 +0200 | blue_aeroplane | (~user@user/aeroplane) |
| 2023-08-30 13:09:02 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2023-08-30 13:12:29 +0200 | blue_aeroplane | (~user@user/aeroplane) () |
| 2023-08-30 13:13:34 +0200 | xff0x | (~xff0x@2405:6580:b080:900:9c90:a654:eded:3f9a) |
| 2023-08-30 13:14:34 +0200 | danse-nr3_ | (~francesco@151.37.129.27) (Ping timeout: 255 seconds) |
| 2023-08-30 13:14:47 +0200 | vglfr | (~vglfr@188.239.201.89) (Ping timeout: 246 seconds) |
| 2023-08-30 13:15:20 +0200 | vglfr | (~vglfr@2a0d:3344:148d:7a00:fdd5:1482:7428:6489) |
| 2023-08-30 13:15:47 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-30 13:18:44 +0200 | ulysses4ever | (~artem@c-73-103-90-145.hsd1.in.comcast.net) |
| 2023-08-30 13:18:44 +0200 | artem | (~artem@c-73-103-90-145.hsd1.in.comcast.net) (Read error: Connection reset by peer) |
| 2023-08-30 13:20:25 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 255 seconds) |
| 2023-08-30 13:28:05 +0200 | vglfr | (~vglfr@2a0d:3344:148d:7a00:fdd5:1482:7428:6489) (Ping timeout: 246 seconds) |
| 2023-08-30 13:28:14 +0200 | vglfr | (~vglfr@188.239.201.89) |
| 2023-08-30 13:30:21 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-08-30 13:33:07 +0200 | <haskellbridge> | <jade> im being fed copious amounts of OOP propaganda at work |
| 2023-08-30 13:33:28 +0200 | sm | (~sm@plaintextaccounting/sm) (Ping timeout: 255 seconds) |
| 2023-08-30 13:34:07 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 245 seconds) |
| 2023-08-30 13:35:36 +0200 | haritz | (~hrtz@user/haritz) (Remote host closed the connection) |
| 2023-08-30 13:36:13 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2023-08-30 13:36:43 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2023-08-30 13:37:25 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) |
| 2023-08-30 13:37:31 +0200 | tv | (~tv@user/tv) (Ping timeout: 255 seconds) |
| 2023-08-30 13:38:30 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-08-30 13:46:21 +0200 | danse-nr3_ | (~francesco@151.37.129.27) |
| 2023-08-30 13:48:45 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2023-08-30 13:50:15 +0200 | xmachina | (~xmachina@modemcable048.127-56-74.mc.videotron.ca) (Quit: WeeChat 4.0.4) |
| 2023-08-30 13:52:07 +0200 | hiyori | (~hiyori@user/hiyori) (Quit: Client closed) |
| 2023-08-30 13:52:07 +0200 | tv | (~tv@user/tv) |
| 2023-08-30 13:53:20 +0200 | xmachina | (~xmachina@modemcable048.127-56-74.mc.videotron.ca) |
| 2023-08-30 13:57:32 +0200 | <danse-nr3_> | strange, the compiler tells me to propagate the `Show` constraint to `f`, while that seems specific to `h` to me https://paste.tomsmeding.com/ebY6LQh7 |
| 2023-08-30 14:00:16 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-30 14:01:51 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 246 seconds) |
| 2023-08-30 14:01:54 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2023-08-30 14:02:26 +0200 | <robosexual> | f :: (forall a . (Show a) => a -> c) -> Either Int Char -> c |
| 2023-08-30 14:06:28 +0200 | <lortabac> | danse-nr3_: yes, but with rank-n types you can't pass a more specific function |
| 2023-08-30 14:09:01 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 255 seconds) |
| 2023-08-30 14:10:11 +0200 | <lortabac> | so GHC suggests you to add the constraint to the first argument of 'h' |
| 2023-08-30 14:10:14 +0200 | <danse-nr3_> | interesting, thanks lortabac |
| 2023-08-30 14:10:30 +0200 | <lortabac> | sorry my explanation was awful |
| 2023-08-30 14:10:50 +0200 | <lortabac> | but I hope you got the point |
| 2023-08-30 14:10:58 +0200 | <danse-nr3_> | seems clear to me. With rank-n types one cannot pass a more specific function |
| 2023-08-30 14:11:43 +0200 | <lortabac> | for example if the signature says 'forall a. a -> a' you can't pass 'forall a. Show a => a -> a' |
| 2023-08-30 14:11:54 +0200 | <lortabac> | nor 'Int -> Int' |
| 2023-08-30 14:11:58 +0200 | <danse-nr3_> | what about Int -> Int? |
| 2023-08-30 14:12:04 +0200 | <danse-nr3_> | oh, not even |
| 2023-08-30 14:12:18 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::4f8) |
| 2023-08-30 14:12:33 +0200 | <danse-nr3_> | i guess this is not a design decision but rather some other kind of limitation |
| 2023-08-30 14:13:15 +0200 | <lortabac> | no, it's a theoretical feature of polymorphism |
| 2023-08-30 14:13:31 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::4f8) (Remote host closed the connection) |
| 2023-08-30 14:15:47 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) (Remote host closed the connection) |
| 2023-08-30 14:19:09 +0200 | <ncf> | f expects a first argument that works with any choice of a. if you give it a function that expects a to be Int, or have a Show instance, that can't work |
| 2023-08-30 14:20:49 +0200 | <ncf> | what you've written is basically Either Int Char -> exists a. a, which doesn't seem very useful: if you know nothing about a, you can't do anything with it |
| 2023-08-30 14:21:51 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-08-30 14:21:57 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::4f8) |
| 2023-08-30 14:22:00 +0200 | <Inst> | i just checked Hoogle |
| 2023-08-30 14:22:31 +0200 | <Inst> | we don't have an unchunk function? unchunk :: [a] -> [[b]] -> [[a]] |
| 2023-08-30 14:23:23 +0200 | <ncf> | you could add constraints on a that specify what the continuation is allowed to do with it; you could take the intersection of all classes that Int and Char have in common, for example (forall a. (Show a, Enum a, Eq a, Ord a, ...) -> ...) |
| 2023-08-30 14:23:52 +0200 | <ncf> | or you know, just be explicit and use Either Int Char. there's no reason to mess with polymorphism here |
| 2023-08-30 14:24:24 +0200 | <ncf> | (and (Either Int Char -> c) -> Either Int Char -> c is of course just Either Int Char -> Either Int Char) |
| 2023-08-30 14:24:50 +0200 | <robosexual> | Inst: what is expected behaviour of unchunk function? |
| 2023-08-30 14:24:58 +0200 | <drewjose> | Inst not sure about your type definition but from the name it seems you want concat? |
| 2023-08-30 14:25:04 +0200 | <Inst> | unconcat, tbh |
| 2023-08-30 14:25:28 +0200 | <Inst> | Foldable t => t a -> t (t b) -> t (t a) |
| 2023-08-30 14:25:41 +0200 | <ncf> | what should it do? show examples |
| 2023-08-30 14:25:53 +0200 | <Inst> | ummm, back to trying to beat Jose Valim's problem |
| 2023-08-30 14:26:03 +0200 | <danse-nr3_> | i see, makes more sense now ncf, i guess it is a matter of getting acquainted with rank-n types. Coming from simpler polymorphism, more specific types satisfy more generic parameters, but here the semantic seems different. The Either example was just a way to explain the case |
| 2023-08-30 14:26:06 +0200 | <danse-nr3_> | thanks |
| 2023-08-30 14:26:11 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-08-30 14:26:13 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-30 14:26:20 +0200 | <Inst> | given [1..] and a [[a, b],[c,d]... etc], I want to get a list of [[1,2], [3,4]...] |
| 2023-08-30 14:27:55 +0200 | <drewjose> | what is the significance of a,b,c,d |
| 2023-08-30 14:28:36 +0200 | <ncf> | > [[a, b], [c, d]] & partsOf (traversed . traversed) .~ [1..] |
| 2023-08-30 14:28:40 +0200 | <lambdabot> | [[1,2],[3,4]] |
| 2023-08-30 14:28:49 +0200 | <Inst> | this problem |
| 2023-08-30 14:29:08 +0200 | <Inst> | ah, lens <3 |
| 2023-08-30 14:29:20 +0200 | <Inst> | but there's no dedicated function for this, no? |
| 2023-08-30 14:29:25 +0200 | <Inst> | https://discourse.haskell.org/t/beautiful-functional-programming/7411/49 |
| 2023-08-30 14:29:31 +0200 | <ncf> | why would there be? this seems extremely niche |
| 2023-08-30 14:29:51 +0200 | <Inst> | the strategy i'm going to use now, because apparently i failed to beat python again |
| 2023-08-30 14:30:07 +0200 | <Inst> | first, store the data structure as a keymap via aeson, or an equivalent, giving me an easy way to add stuff |
| 2023-08-30 14:30:37 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 258 seconds) |
| 2023-08-30 14:30:39 +0200 | <Inst> | second, zip the list provided to [1..], map the keymap insert in |
| 2023-08-30 14:31:12 +0200 | <Inst> | third, use groupby to split the list into the appropriate groupings for continuations |
| 2023-08-30 14:31:23 +0200 | <Inst> | not continuation, i mean, continuing the zip |
| 2023-08-30 14:31:54 +0200 | <Inst> | fourth, extract the lesson lists, zip them with [1..], unconcat, then zip the result with the objects |
| 2023-08-30 14:31:59 +0200 | <Inst> | then map some kind of insert again |
| 2023-08-30 14:33:41 +0200 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) (Ping timeout: 258 seconds) |
| 2023-08-30 14:35:51 +0200 | hyvoid | (~hyenavoid@222-0-178-69.static.gci.net) |
| 2023-08-30 14:36:59 +0200 | <Inst> | thank you so much ncf! |
| 2023-08-30 14:47:41 +0200 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) |
| 2023-08-30 14:50:38 +0200 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) |
| 2023-08-30 14:50:38 +0200 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) (Changing host) |
| 2023-08-30 14:50:38 +0200 | haritz | (~hrtz@user/haritz) |
| 2023-08-30 14:51:25 +0200 | <fendor> | What does `@(*)` mean? Getting a type error ` m -> Ix.do |
| 2023-08-30 14:51:25 +0200 | <fendor> | (x, _q) <- runner (f p) m |
| 2023-08-30 14:51:26 +0200 | <fendor> | runner p (runIKleisliTupled k x)` |
| 2023-08-30 14:51:41 +0200 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) (Ping timeout: 246 seconds) |
| 2023-08-30 14:51:41 +0200 | <fendor> | typo, sorry, I meant `PrEff @(*) eff (IVoid @{*} @{*} @{*}) () () (a, q)` |
| 2023-08-30 14:53:31 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::4f8) (Remote host closed the connection) |
| 2023-08-30 14:53:35 +0200 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) |
| 2023-08-30 14:53:49 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::6d40) |
| 2023-08-30 14:58:24 +0200 | famubu | (~julinuser@61.0.251.1) |
| 2023-08-30 14:58:36 +0200 | falafel | (~falafel@216.68.6.51.dyn.plus.net) |
| 2023-08-30 14:58:49 +0200 | <famubu> | Hi is there a way to duplicate a list n times in haskell? Like `[1,3] * 2` giving [1,3,1,3]`? |
| 2023-08-30 15:01:18 +0200 | <Axman6> | > [[a,b],[c,d]] & (traverse . traverse) (const $ id <<+= 1) & flip runState 1 |
| 2023-08-30 15:01:19 +0200 | <lambdabot> | ([[1,2],[3,4]],5) |
| 2023-08-30 15:01:35 +0200 | <Axman6> | > [1,3] >>= replicate 2 |
| 2023-08-30 15:01:36 +0200 | <lambdabot> | [1,1,3,3] |
| 2023-08-30 15:01:45 +0200 | <Axman6> | uh, hmm |
| 2023-08-30 15:02:01 +0200 | <Axman6> | concat . replicate n will do it |
| 2023-08-30 15:02:11 +0200 | <lortabac> | > concat $ replicate 2 [1, 3] |
| 2023-08-30 15:02:12 +0200 | <lambdabot> | [1,3,1,3] |
| 2023-08-30 15:02:27 +0200 | <lortabac> | (>>=) is concatMap |
| 2023-08-30 15:02:38 +0200 | <famubu> | Thanks folks! |
| 2023-08-30 15:03:44 +0200 | <lortabac> | there is also 'cycle' which does infinite repetitions of the list |
| 2023-08-30 15:03:57 +0200 | <lortabac> | > take 4 $ cycle [1, 3] |
| 2023-08-30 15:03:58 +0200 | <lambdabot> | [1,3,1,3] |
| 2023-08-30 15:04:45 +0200 | haritz | (~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb2 - https://znc.in) |
| 2023-08-30 15:05:01 +0200 | <Inst> | btw, if there were a -XLetLambda extension, would you oppose it? |
| 2023-08-30 15:05:23 +0200 | <lortabac> | please no more syntactic extensions!!! |
| 2023-08-30 15:05:27 +0200 | <Axman6> | lambdas are already allowed, no need to let us use them. Fight the power! |
| 2023-08-30 15:05:38 +0200 | <Inst> | wherein: the foo\bar -> bar syntax evaluates to let foo bar = bar in foo |
| 2023-08-30 15:06:08 +0200 | <lortabac> | personally I oppose all extensions that introduce new syntax |
| 2023-08-30 15:06:08 +0200 | <famubu> | lortabac: +1 |
| 2023-08-30 15:06:23 +0200 | <Axman6> | I couldn't agree less |
| 2023-08-30 15:07:01 +0200 | <Inst> | so are you a syntactical extension enthusiast, then, axman6? implying your level of agreement is zero or infinitely negative? |
| 2023-08-30 15:07:39 +0200 | <Inst> | :) |
| 2023-08-30 15:07:40 +0200 | <Axman6> | lambda case should've been there from the beginning, and adding it as an extension is totally fine; one day it should part of the base language because its so obvious |
| 2023-08-30 15:07:42 +0200 | razetime | (~quassel@49.207.213.87) |
| 2023-08-30 15:07:54 +0200 | <Axman6> | Inst: i have no idea what LetLambda would do |
| 2023-08-30 15:08:20 +0200 | <Inst> | equivalent to python walrus operator, i.e, use on declare |
| 2023-08-30 15:08:27 +0200 | mysl | (~mysl@user/mysl) (Remote host closed the connection) |
| 2023-08-30 15:08:31 +0200 | <Axman6> | Inst: i have no idea what LetLambda would do |
| 2023-08-30 15:08:43 +0200 | <Inst> | since there are declarative programming nuts who don't believe in lambdas |
| 2023-08-30 15:08:58 +0200 | <Inst> | at the same time, it seems that lambdas do improve readability, but are undeclarative |
| 2023-08-30 15:08:58 +0200 | <Axman6> | show me what it would look like |
| 2023-08-30 15:09:15 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2023-08-30 15:09:29 +0200 | <Inst> | foo\bar -> bar desugars to let foo = \bar -> bar in foo |
| 2023-08-30 15:10:13 +0200 | <Axman6> | not sure I see the point of that |
| 2023-08-30 15:10:35 +0200 | <Inst> | having cake and eating it too, i.e, ergonomic named anonymous functions, and i can see why you wouldn't see the point of that |
| 2023-08-30 15:10:54 +0200 | <Axman6> | "named anonymous functions" |
| 2023-08-30 15:11:23 +0200 | <Inst> | yeah, this is just a scam for me to trivially become a GHC contributor |
| 2023-08-30 15:11:39 +0200 | <Inst> | i think it's a good idea, as in, even a conventional imperative language should have a similar facility |
| 2023-08-30 15:12:06 +0200 | <Axman6> | it'a not too hard, though that said I have three PRs that I haven't found the time to finish off for the last month or so |
| 2023-08-30 15:12:36 +0200 | <Axman6> | how does that example differ from just \bar -> bar? |
| 2023-08-30 15:13:05 +0200 | <Inst> | I mean, with conventional lambda use, you don't have a name |
| 2023-08-30 15:13:07 +0200 | <Inst> | (\bar -> bar) |
| 2023-08-30 15:13:33 +0200 | <Inst> | the benefit is that it's terse, ergonomic, etc, but on the other hand, there is no name there, it's like certain people complaining about use of go |
| 2023-08-30 15:13:48 +0200 | <Axman6> | but in that example you don't either, it's gone outside the scope of the let |
| 2023-08-30 15:14:19 +0200 | <Inst> | i mean, in a more conventional language, you might want to hoist the term out, at least optionally |
| 2023-08-30 15:14:36 +0200 | <Inst> | the need is already fulfilled by comments, tbh |
| 2023-08-30 15:15:24 +0200 | <Inst> | but there is an advantage to using this over comments |
| 2023-08-30 15:15:55 +0200 | <Inst> | insofar as it's a first-class syntactical construct, and means that people won't comment with -- asinine comment here |
| 2023-08-30 15:15:57 +0200 | <ncf> | Inst: do you mean this as a shorthand for building fixed points? |
| 2023-08-30 15:16:11 +0200 | <Inst> | nope, but i suppose we could do so! |
| 2023-08-30 15:16:13 +0200 | <Axman6> | if you're going to make a proposal or s PR, you're going to have to do a much better job explaining what this actually does, I feel like I understand less than before I asked |
| 2023-08-30 15:16:16 +0200 | <ncf> | like fact\n -> n * fact (n - 1) |
| 2023-08-30 15:16:33 +0200 | <ncf> | anyway that's terrible please forget it now |
| 2023-08-30 15:16:48 +0200 | <Inst> | ncf: iirc, we already have short-hand for building fixed points, no? |
| 2023-08-30 15:17:00 +0200 | <Inst> | I forgot about it, and I could just hijack it for this purpose |
| 2023-08-30 15:17:05 +0200 | <lortabac> | maybe you want something like named lambdas (basically syntactic sugar for fix) |
| 2023-08-30 15:17:11 +0200 | <ncf> | well there's fix. not exactly shorthand, more of a definition |
| 2023-08-30 15:17:18 +0200 | <ncf> | fix \ fact n -> n * fact (n - 1) |
| 2023-08-30 15:17:18 +0200 | <Inst> | it is basically just named lambdas |
| 2023-08-30 15:17:25 +0200 | <lortabac> | I don't remember which language has them, maybe Clojure? |
| 2023-08-30 15:17:31 +0200 | <Axman6> | a.k.a functions |
| 2023-08-30 15:17:38 +0200 | <lortabac> | Axman6: inline functions |
| 2023-08-30 15:17:50 +0200 | <Inst> | bleh, w/e, i have other things to do, i'd rather waste my time on trying to beat jose valim instead |
| 2023-08-30 15:18:42 +0200 | <Inst> | https://paste.tomsmeding.com/qckPcWI6 |
| 2023-08-30 15:18:55 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-08-30 15:19:57 +0200 | <Axman6> | :t partsOf |
| 2023-08-30 15:19:58 +0200 | <lambdabot> | Functor f => Traversing (->) f s t a a -> LensLike f s t [a] [a] |
| 2023-08-30 15:20:28 +0200 | <Inst> | i really, really need to learn optics, I mean, I have monad tutorials ALMOST down |
| 2023-08-30 15:20:50 +0200 | robosexual | (~spaceoyst@5.165.11.54) (Quit: Konversation terminated!) |
| 2023-08-30 15:21:09 +0200 | <Inst> | https://hasura.io/blog/parser-combinators-walkthrough/#fn1 |
| 2023-08-30 15:21:31 +0200 | <Inst> | in the sense that it should be possible to teach someone monads in 15-30 minutes, 1 hour at worst, we're just pedagogically challenged here |
| 2023-08-30 15:21:45 +0200 | <Axman6> | > ("Hello", ("there", ["are","several"]),Left "Strings", "in", "here") & partsOf template %~ (reverse :: [String] -> [String]) |
| 2023-08-30 15:21:47 +0200 | <lambdabot> | ("here",("in",["Strings","several"]),Left "are","there","Hello") |
| 2023-08-30 15:21:48 +0200 | <Inst> | and no, before you ask, i've taken a year or more to try to figure it out properly |
| 2023-08-30 15:22:44 +0200 | <Axman6> | > ("Hello", ("there", ["are","several"]),Left "Strings", "in", "here") & partsOf template %~ (reverse :: String -> String) |
| 2023-08-30 15:22:45 +0200 | <lambdabot> | ("erehn",("isgni",["rtS","lareves"]),Left "eraereh","to","lleH") |
| 2023-08-30 15:24:05 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 250 seconds) |
| 2023-08-30 15:24:24 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-08-30 15:24:24 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-08-30 15:24:24 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-08-30 15:25:09 +0200 | <ncf> | lol |
| 2023-08-30 15:25:22 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-08-30 15:29:04 +0200 | <Inst> | also, btw, my project goal right now, besides messing around, not getting ready to leave the country for medical care, is to build the cabal GUI wrapper |
| 2023-08-30 15:29:13 +0200 | <Inst> | but, since bricks is adding windows support in 6-24 months |
| 2023-08-30 15:29:26 +0200 | <Inst> | would it be worthwhile to try to repackage ghci with a simple IDE? |
| 2023-08-30 15:29:34 +0200 | ulysses4ever | (~artem@c-73-103-90-145.hsd1.in.comcast.net) (Read error: Connection reset by peer) |
| 2023-08-30 15:29:48 +0200 | ulysses4ever | (~artem@c-73-103-90-145.hsd1.in.comcast.net) |
| 2023-08-30 15:30:09 +0200 | famubu | (~julinuser@61.0.251.1) () |
| 2023-08-30 15:30:59 +0200 | fserucas__ | (~fserucas@46.50.115.39) |
| 2023-08-30 15:31:17 +0200 | mysl | (~mysl@user/mysl) |
| 2023-08-30 15:31:42 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) |
| 2023-08-30 15:31:50 +0200 | <haskellbridge> | <jean-paul.> What does "worthwhile" mean? |
| 2023-08-30 15:33:20 +0200 | <Axman6> | what would the IDE offer? |
| 2023-08-30 15:33:36 +0200 | fserucas_ | (~fserucas@46.50.115.39) (Ping timeout: 255 seconds) |
| 2023-08-30 15:34:04 +0200 | <Axman6> | I wouldnt mind habing something like pythons pudb package |
| 2023-08-30 15:35:23 +0200 | CiaoSen | (~Jura@2a05:5800:2a1:b500:664b:f0ff:fe37:9ef) |
| 2023-08-30 15:36:12 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
| 2023-08-30 15:37:27 +0200 | gatekempt | (~gatekempt@user/gatekempt) |
| 2023-08-30 15:40:51 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2023-08-30 15:45:14 +0200 | <Inst> | Axman6: I guess, a more GHCI-centric workflow? |
| 2023-08-30 15:45:30 +0200 | <Inst> | GHCI is good, relative to Python, but terrible relative to other interpreters in the FP space, so I'm told |
| 2023-08-30 15:46:22 +0200 | ddellacosta | (~ddellacos@ool-44c738de.dyn.optonline.net) (Quit: WeeChat 4.0.3) |
| 2023-08-30 15:46:28 +0200 | <Inst> | also, providing Haskell developers the embarrassment of using CUDDLES |
| 2023-08-30 15:47:07 +0200 | <Inst> | probably a bad idea right now, given that Cabal according to sclv is understaffed |
| 2023-08-30 15:47:21 +0200 | <Inst> | existing tooling needs improvement before new tooling can be developed |
| 2023-08-30 15:48:55 +0200 | ddellacosta | (~ddellacos@ool-44c738de.dyn.optonline.net) |
| 2023-08-30 15:49:25 +0200 | sm | (~sm@plaintextaccounting/sm) (Quit: sm) |
| 2023-08-30 15:53:08 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
| 2023-08-30 15:57:51 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2023-08-30 15:57:55 +0200 | MajorBiscuit | (~MajorBisc@c-001-010-057.client.tudelft.eduvpn.nl) (Ping timeout: 255 seconds) |
| 2023-08-30 15:59:43 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 255 seconds) |
| 2023-08-30 15:59:44 +0200 | MajorBiscuit | (~MajorBisc@62-137-46.netrun.cytanet.com.cy) |
| 2023-08-30 16:04:08 +0200 | razetime | (~quassel@49.207.213.87) (Ping timeout: 246 seconds) |
| 2023-08-30 16:07:47 +0200 | mima | (~mmh@net-93-67-213-89.cust.vodafonedsl.it) (Ping timeout: 246 seconds) |
| 2023-08-30 16:07:52 +0200 | billchenchina | (~billchenc@103.152.35.21) |
| 2023-08-30 16:08:37 +0200 | <bwe> | how do I get the list of files with Turtle? `fs <- _ $ ls "."` |
| 2023-08-30 16:09:42 +0200 | razetime | (~quassel@49.207.213.87) |
| 2023-08-30 16:10:17 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
| 2023-08-30 16:10:18 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:3f4f:3d1f:233a:c3d3) (Quit: WeeChat 2.8) |
| 2023-08-30 16:13:43 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-30 16:14:40 +0200 | danse-nr3__ | (~francesco@151.37.176.153) |
| 2023-08-30 16:15:12 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2023-08-30 16:15:51 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 245 seconds) |
| 2023-08-30 16:17:08 +0200 | tv | (~tv@user/tv) (Ping timeout: 246 seconds) |
| 2023-08-30 16:17:10 +0200 | danse-nr3_ | (~francesco@151.37.129.27) (Ping timeout: 245 seconds) |
| 2023-08-30 16:18:23 +0200 | thyriaen | (~thyriaen@2a01:aea0:dd4:6de3:6245:cbff:fe9f:48b1) |
| 2023-08-30 16:18:41 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 260 seconds) |
| 2023-08-30 16:18:51 +0200 | <thyriaen> | does haskell have a preprocessor like in c ? |
| 2023-08-30 16:18:52 +0200 | notzmv | (~zmv@user/notzmv) (Ping timeout: 248 seconds) |
| 2023-08-30 16:21:33 +0200 | <geekosaur> | you can use the C preprocessor but with some caveats since it expects C instead of Haskell |
| 2023-08-30 16:22:19 +0200 | <geekosaur> | you can use your own preprocessor with `-pgmF`; there are no standard ones |
| 2023-08-30 16:23:15 +0200 | <geekosaur> | there is a literate preprocessor that is run automatically on `.lhs` files; you don't have any control over this aside from replacing the `unlit` program in the GHC distribution |
| 2023-08-30 16:23:44 +0200 | anselmschueler | (~anselmsch@user/schuelermine) |
| 2023-08-30 16:24:25 +0200 | thegeekinside | (~thegeekin@189.180.81.59) |
| 2023-08-30 16:25:42 +0200 | razetime | (~quassel@49.207.213.87) (Ping timeout: 246 seconds) |
| 2023-08-30 16:27:46 +0200 | bratwurst | (~blaadsfa@2604:3d09:207f:f650:216:3eff:fe5a:a1f8) |
| 2023-08-30 16:31:07 +0200 | tv | (~tv@user/tv) |
| 2023-08-30 16:32:42 +0200 | <Inst> | gah, lens is powerful enoguh to make this trivial |
| 2023-08-30 16:32:48 +0200 | <Inst> | so this is really a problem for lens |
| 2023-08-30 16:33:20 +0200 | zer0bitz | (~zer0bitz@user/zer0bitz) (Ping timeout: 246 seconds) |
| 2023-08-30 16:34:12 +0200 | anselmschueler | (~anselmsch@user/schuelermine) (Ping timeout: 240 seconds) |
| 2023-08-30 16:35:38 +0200 | <chromoblob> | thyriaen: also, see Template Haskell |
| 2023-08-30 16:36:05 +0200 | bratwurst | (~blaadsfa@2604:3d09:207f:f650:216:3eff:fe5a:a1f8) (Remote host closed the connection) |
| 2023-08-30 16:36:38 +0200 | bratwurst | (~blaadsfa@2604:3d09:207f:f650:216:3eff:fe5a:a1f8) |
| 2023-08-30 16:38:02 +0200 | thyriaen | (~thyriaen@2a01:aea0:dd4:6de3:6245:cbff:fe9f:48b1) (Quit: Leaving) |
| 2023-08-30 16:41:04 +0200 | thyriaen | (~thyriaen@2a01:aea0:dd4:6de3:6245:cbff:fe9f:48b1) |
| 2023-08-30 16:43:38 +0200 | fendor | (~fendor@2a02:8388:1640:be00:29b8:807b:7fa6:1bcf) (Remote host closed the connection) |
| 2023-08-30 16:44:00 +0200 | zer0bitz | (~zer0bitz@user/zer0bitz) |
| 2023-08-30 16:46:29 +0200 | bratwurst | (~blaadsfa@2604:3d09:207f:f650:216:3eff:fe5a:a1f8) (Ping timeout: 246 seconds) |
| 2023-08-30 16:47:24 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-08-30 16:48:19 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
| 2023-08-30 16:49:59 +0200 | ripspin | (~chatzilla@1.145.152.77) |
| 2023-08-30 16:51:26 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 246 seconds) |
| 2023-08-30 16:53:36 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 258 seconds) |
| 2023-08-30 16:57:00 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-30 17:00:38 +0200 | CiaoSen | (~Jura@2a05:5800:2a1:b500:664b:f0ff:fe37:9ef) (Ping timeout: 246 seconds) |
| 2023-08-30 17:01:17 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 244 seconds) |
| 2023-08-30 17:02:41 +0200 | yoyofreeman | (~yoyofreem@47.254.237.126) |
| 2023-08-30 17:03:27 +0200 | ripspin | (~chatzilla@1.145.152.77) (Remote host closed the connection) |
| 2023-08-30 17:06:15 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-30 17:07:01 +0200 | <bwe> | (so, it's actually sth. like ` |
| 2023-08-30 17:07:14 +0200 | <bwe> | `fold (find (suffix "Browser.py") "/usr/lib") Fold.head`) |
| 2023-08-30 17:10:04 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-08-30 17:10:59 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-08-30 17:11:16 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 255 seconds) |
| 2023-08-30 17:12:19 +0200 | gatekempt | (~gatekempt@user/gatekempt) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2023-08-30 17:14:06 +0200 | <danse-nr3__> | bwe, how are you liking Turtle? I experimented with similar libs time ago, then gave up and resorted to more common functions available in base |
| 2023-08-30 17:14:26 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5185:af9c:1a37:ea21) (Remote host closed the connection) |
| 2023-08-30 17:14:41 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5185:af9c:1a37:ea21) |
| 2023-08-30 17:16:46 +0200 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) |
| 2023-08-30 17:20:25 +0200 | shapr | (~user@2600:1700:c640:3100:6019:9d8e:9090:8797) (Remote host closed the connection) |
| 2023-08-30 17:22:02 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-08-30 17:25:11 +0200 | thegeekinside | (~thegeekin@189.180.81.59) (Ping timeout: 260 seconds) |
| 2023-08-30 17:25:40 +0200 | ripspin | (~chatzilla@1.145.152.77) |
| 2023-08-30 17:26:23 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 246 seconds) |
| 2023-08-30 17:27:59 +0200 | zer0bitz | (~zer0bitz@user/zer0bitz) (Read error: Connection reset by peer) |
| 2023-08-30 17:28:22 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2023-08-30 17:30:41 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 4.0.4) |
| 2023-08-30 17:31:01 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::6d40) (Remote host closed the connection) |
| 2023-08-30 17:31:21 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::4f8) |
| 2023-08-30 17:31:33 +0200 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2023-08-30 17:33:02 +0200 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 246 seconds) |
| 2023-08-30 17:37:05 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5185:af9c:1a37:ea21) (Read error: Connection reset by peer) |
| 2023-08-30 17:39:27 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-08-30 17:40:55 +0200 | MajorBiscuit | (~MajorBisc@62-137-46.netrun.cytanet.com.cy) (Ping timeout: 245 seconds) |
| 2023-08-30 17:43:09 +0200 | bratwurst | (~blaadsfa@2604:3d09:207f:f650:216:3eff:fe5a:a1f8) |
| 2023-08-30 17:43:47 +0200 | thegeekinside | (~thegeekin@189.180.81.59) |
| 2023-08-30 17:44:26 +0200 | thyriaen | (~thyriaen@2a01:aea0:dd4:6de3:6245:cbff:fe9f:48b1) (Remote host closed the connection) |
| 2023-08-30 17:45:39 +0200 | yoyofreeman | (~yoyofreem@47.254.237.126) (Remote host closed the connection) |
| 2023-08-30 17:46:14 +0200 | ubert | (~Thunderbi@77.119.173.8.wireless.dyn.drei.com) (Ping timeout: 244 seconds) |
| 2023-08-30 17:49:29 +0200 | thegeekinside | (~thegeekin@189.180.81.59) (Remote host closed the connection) |
| 2023-08-30 17:49:52 +0200 | shapr | (~user@2600:1700:c640:3100:c5b6:6d9c:4fa1:59ed) |
| 2023-08-30 17:50:19 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2023-08-30 17:54:32 +0200 | bratwurst | (~blaadsfa@2604:3d09:207f:f650:216:3eff:fe5a:a1f8) (Ping timeout: 246 seconds) |
| 2023-08-30 17:54:43 +0200 | ripspin | (~chatzilla@1.145.152.77) (Remote host closed the connection) |
| 2023-08-30 17:55:05 +0200 | falafel | (~falafel@216.68.6.51.dyn.plus.net) (Ping timeout: 246 seconds) |
| 2023-08-30 17:55:34 +0200 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) |
| 2023-08-30 17:55:34 +0200 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) (Changing host) |
| 2023-08-30 17:55:34 +0200 | haritz | (~hrtz@user/haritz) |
| 2023-08-30 17:56:36 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-08-30 17:56:53 +0200 | anselmschueler | (~anselmsch@user/schuelermine) |
| 2023-08-30 17:58:14 +0200 | billchenchina | (~billchenc@103.152.35.21) (Remote host closed the connection) |
| 2023-08-30 17:58:48 +0200 | anselmschueler | (~anselmsch@user/schuelermine) (Client Quit) |
| 2023-08-30 17:59:04 +0200 | grnman_ | (~michaelsc@c-66-176-3-51.hsd1.fl.comcast.net) |
| 2023-08-30 17:59:06 +0200 | anselmschueler | (~anselmsch@user/schuelermine) |
| 2023-08-30 18:00:51 +0200 | Guest71 | (~Guest50@189.176.241.47) |
| 2023-08-30 18:02:09 +0200 | Guest71 | (~Guest50@189.176.241.47) (Client Quit) |
| 2023-08-30 18:02:55 +0200 | Guest94 | (~Guest50@189.176.241.47) |
| 2023-08-30 18:03:57 +0200 | <nyc> | Is there a shorter predicate to test for a case than \case { MyCase _ _ _ -> True ; _ -> False } ? |
| 2023-08-30 18:03:59 +0200 | anselmschueler | (~anselmsch@user/schuelermine) (Client Quit) |
| 2023-08-30 18:04:13 +0200 | anselmschueler | (~anselmsch@user/schuelermine) |
| 2023-08-30 18:04:27 +0200 | anselmschueler | (~anselmsch@user/schuelermine) () |
| 2023-08-30 18:05:59 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2023-08-30 18:06:04 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
| 2023-08-30 18:06:05 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 246 seconds) |
| 2023-08-30 18:06:38 +0200 | <geekosaur> | only if you write it yourself (cf. `isNothing`/`isJust`) |
| 2023-08-30 18:06:43 +0200 | <int-e> | nyc: you can write MyCase{} |
| 2023-08-30 18:07:04 +0200 | <int-e> | (not much shorter but it saves you from counting arguments which is nice) |
| 2023-08-30 18:07:40 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 248 seconds) |
| 2023-08-30 18:08:09 +0200 | <nyc> | int-e: I'm hoping to use it for a break (\case { MyCase _ _ _ -> True ; _ -> False }) blahblah sort of affair. |
| 2023-08-30 18:08:13 +0200 | <mauke> | \case MyCase{} -> True; _ -> False |
| 2023-08-30 18:08:29 +0200 | <mauke> | or possibly something involving Data.Data.Data |
| 2023-08-30 18:08:44 +0200 | <nyc> | Ah, I see wrt. counting args. |
| 2023-08-30 18:09:13 +0200 | thegeekinside | (~thegeekin@189.180.81.59) |
| 2023-08-30 18:10:11 +0200 | <nyc> | Thanks on that one. |
| 2023-08-30 18:11:00 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5185:af9c:1a37:ea21) |
| 2023-08-30 18:11:56 +0200 | caryhartline | (~caryhartl@168.182.58.169) |
| 2023-08-30 18:12:29 +0200 | Guest94 | (~Guest50@189.176.241.47) (Ping timeout: 246 seconds) |
| 2023-08-30 18:12:56 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2023-08-30 18:16:10 +0200 | <Inst> | i'm a freaking imbecile |
| 2023-08-30 18:16:21 +0200 | <Inst> | i've been raging this entire time that aeson can't decode to object |
| 2023-08-30 18:16:23 +0200 | <Inst> | turns out it can |
| 2023-08-30 18:16:26 +0200 | <Inst> | decode @Value |
| 2023-08-30 18:16:29 +0200 | <Inst> | i'm so, so stupid |
| 2023-08-30 18:16:49 +0200 | <geekosaur> | you should have asked, even I know that one |
| 2023-08-30 18:17:12 +0200 | <Inst> | i'm so, so stupid |
| 2023-08-30 18:17:30 +0200 | <Inst> | typeclasses, man, how do they work? |
| 2023-08-30 18:17:54 +0200 | <Inst> | i kept on searching the freaking API, turns out it's using value API to decode to object |
| 2023-08-30 18:18:02 +0200 | <Inst> | erm, type API to do so |
| 2023-08-30 18:18:04 +0200 | <mauke> | do you even need the explicit type argument? |
| 2023-08-30 18:18:25 +0200 | <mauke> | if you just use the result as Value, it should all work out |
| 2023-08-30 18:22:37 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 250 seconds) |
| 2023-08-30 18:24:17 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5185:af9c:1a37:ea21) (Remote host closed the connection) |
| 2023-08-30 18:24:18 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-08-30 18:24:32 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2023-08-30 18:25:59 +0200 | <Inst> | yeah, I don't, but it's not obvious how to do so |
| 2023-08-30 18:27:35 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-08-30 18:29:19 +0200 | Guest9 | (~Guest36@2800:200:f690:145:5e87:9cff:fed5:e94f) |
| 2023-08-30 18:29:34 +0200 | Guest9 | (~Guest36@2800:200:f690:145:5e87:9cff:fed5:e94f) (Client Quit) |
| 2023-08-30 18:29:53 +0200 | <Inst> | btw, just curious, i have a weird discovery |
| 2023-08-30 18:29:57 +0200 | <Inst> | haskell is beating C by 10x here |
| 2023-08-30 18:30:15 +0200 | <Inst> | i don't think anything is optimized, but for reference, the Python is running at 10x C |
| 2023-08-30 18:30:28 +0200 | <Inst> | https://rosettacode.org/wiki/Factorions#Haskell |
| 2023-08-30 18:31:23 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-08-30 18:31:53 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2023-08-30 18:32:33 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 246 seconds) |
| 2023-08-30 18:33:22 +0200 | <Inst> | the Haskell might be just using a more efficient algorithm |
| 2023-08-30 18:34:40 +0200 | <int-e> | did you compile the program? |
| 2023-08-30 18:36:20 +0200 | <int-e> | and how are you running the python code... it's slow for me |
| 2023-08-30 18:37:03 +0200 | <Inst> | Haskell is running in about 19 seconds |
| 2023-08-30 18:37:05 +0200 | <Inst> | erm, 19 ms |
| 2023-08-30 18:37:17 +0200 | <Inst> | well, around 26 ms, C around 260 ms, Python 2600 ms |
| 2023-08-30 18:37:17 +0200 | <Inst> | weird |
| 2023-08-30 18:37:21 +0200 | <Inst> | -O2 |
| 2023-08-30 18:38:08 +0200 | idgaen | (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-08-30 18:38:52 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 240 seconds) |
| 2023-08-30 18:39:14 +0200 | <int-e> | ...ah wait, the Haskell code is cheating. It's supposed to *verify* up to 1500000, not print the known number of results. |
| 2023-08-30 18:39:56 +0200 | <mauke> | right |
| 2023-08-30 18:40:28 +0200 | <mauke> | the haskell code basically checks that there are *at least* n factorions in base b |
| 2023-08-30 18:40:37 +0200 | <mauke> | and then it just stops early |
| 2023-08-30 18:42:20 +0200 | <int-e> | https://paste.tomsmeding.com/PgIbNFXa takes quite a bit longer, about 4x the time of the C program for me |
| 2023-08-30 18:42:49 +0200 | <Inst> | ah, nice |
| 2023-08-30 18:43:12 +0200 | lzszt | (~lzszt@2001:9e8:2dea:5800:d0b7:7b8a:c9f4:ac3c) |
| 2023-08-30 18:43:27 +0200 | <int-e> | not too shabby |
| 2023-08-30 18:44:25 +0200 | <mauke> | the haskell version doesn't use a factorial cache |
| 2023-08-30 18:44:34 +0200 | <mauke> | would that make it faster? |
| 2023-08-30 18:44:34 +0200 | <int-e> | yeah |
| 2023-08-30 18:44:42 +0200 | <int-e> | it probably would? |
| 2023-08-30 18:44:49 +0200 | <Inst> | also, is the filter actually efficient? |
| 2023-08-30 18:44:55 +0200 | <Inst> | is stream fusion actually kicking off? |
| 2023-08-30 18:45:19 +0200 | <Inst> | since i get antsy around lists for high performance data |
| 2023-08-30 18:46:32 +0200 | <Inst> | oof, list variant is actually faster |
| 2023-08-30 18:46:54 +0200 | <mauke> | what do you want to fuse here? |
| 2023-08-30 18:47:46 +0200 | <int-e> | everything |
| 2023-08-30 18:48:09 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-08-30 18:51:04 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-08-30 18:52:24 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
| 2023-08-30 18:52:31 +0200 | danse-nr3__ | (~francesco@151.37.176.153) (Ping timeout: 255 seconds) |
| 2023-08-30 18:52:51 +0200 | <EvanR> | haskell reached 0.25c, well within the bounds of relativity |
| 2023-08-30 18:53:02 +0200 | <int-e> | Tabulating the factorial does help a bit, 20-30% depending on boxed vector, unboxed vector, and safe or unsafe indexing |
| 2023-08-30 18:53:43 +0200 | danza | (~francesco@151.37.176.153) |
| 2023-08-30 18:53:56 +0200 | gatekempt | (~gatekempt@user/gatekempt) |
| 2023-08-30 18:55:37 +0200 | ursa-major | (~ursa-majo@37.19.210.10) |
| 2023-08-30 18:56:58 +0200 | <nyc> | Weirdly ~ isn't silencing a -Wincomplete-uni-patterns warning. I know it shouldn't fail, but if there's a way to shut it up for -Werror that'd be great. |
| 2023-08-30 18:57:01 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2023-08-30 18:57:29 +0200 | razetime | (~quassel@49.207.213.87) |
| 2023-08-30 18:57:48 +0200 | <int-e> | a bit faster, 1.63x C for me: https://paste.tomsmeding.com/SteZjLR6 |
| 2023-08-30 18:58:09 +0200 | <int-e> | but of course far less idiomatic |
| 2023-08-30 18:58:15 +0200 | <int-e> | (and slightly unsafe) |
| 2023-08-30 18:59:15 +0200 | <EvanR> | a numeric program using quotRem is faster than C ? |
| 2023-08-30 18:59:30 +0200 | <int-e> | Err, I forgot to change the import back to Data.Vector.Unboxed, that would be 1.4x |
| 2023-08-30 18:59:39 +0200 | <int-e> | EvanR: that's time, not speed |
| 2023-08-30 18:59:43 +0200 | <int-e> | so it's slower |
| 2023-08-30 18:59:47 +0200 | <EvanR> | oh |
| 2023-08-30 19:00:14 +0200 | <EvanR> | kind of like kessel run in 1.63 parsecs |
| 2023-08-30 19:00:22 +0200 | grnman_ | (~michaelsc@c-66-176-3-51.hsd1.fl.comcast.net) (Ping timeout: 245 seconds) |
| 2023-08-30 19:00:53 +0200 | <int-e> | Though quotRem should be okay compared to C? It *is* the operation that matches the CPU instruction. |
| 2023-08-30 19:02:23 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2023-08-30 19:02:27 +0200 | <EvanR> | yes but there's this check on each call for zero right |
| 2023-08-30 19:02:43 +0200 | <EvanR> | to avoid using that instruction on zero |
| 2023-08-30 19:03:07 +0200 | <mauke> | f n s | ... = f n s |
| 2023-08-30 19:03:55 +0200 | <int-e> | sure but it should be predicted perfectly; heck a smart enough compiler could optimize it out in this case, it just would have to recognize that 9..12 never triggers those checks |
| 2023-08-30 19:04:21 +0200 | <EvanR> | sounds nice xD |
| 2023-08-30 19:04:26 +0200 | <int-e> | mauke: I like imperative code |
| 2023-08-30 19:04:36 +0200 | <int-e> | (I don't think ghc is smart enoguh but I haven't checked) |
| 2023-08-30 19:04:43 +0200 | <mauke> | now I want to see a version that rebinds f in the ... partr |
| 2023-08-30 19:04:47 +0200 | <mauke> | s/r$// |
| 2023-08-30 19:05:35 +0200 | oo_miguel | (~Thunderbi@78-11-179-96.static.ip.netia.com.pl) |
| 2023-08-30 19:06:22 +0200 | <int-e> | mauke: Am I a terrible person for genuinely liking this semi-imperative style? |
| 2023-08-30 19:06:48 +0200 | <mauke> | :shrug: |
| 2023-08-30 19:06:56 +0200 | <mauke> | makes sense to me :-) |
| 2023-08-30 19:07:01 +0200 | <int-e> | (when appropriate... which doesn't happen a lot) |
| 2023-08-30 19:07:34 +0200 | <int-e> | Basically I prefer it to adding a bunch of primes to identifiers. |
| 2023-08-30 19:07:38 +0200 | <EvanR> | i did not understand the code, was like how are you recursing on f n s unchanged xD |
| 2023-08-30 19:08:06 +0200 | <mauke> | the power of in-place updates, baby! |
| 2023-08-30 19:09:35 +0200 | <Inst> | okay, some small optimizations, got it to 3x c |
| 2023-08-30 19:10:02 +0200 | <mauke> | is printf a bottleneck at all? |
| 2023-08-30 19:10:21 +0200 | <mauke> | probably not enough output for that |
| 2023-08-30 19:10:48 +0200 | <Inst> | ugh, this is ugly, hgmp only accepts integer? :( |
| 2023-08-30 19:10:59 +0200 | <nyc> | I'm using ~(x:xs) but -Wincomplete-uni-patterns is still warning me. How do I stop it? |
| 2023-08-30 19:11:03 +0200 | <Inst> | tried modding it to hgmp with predicatable results |
| 2023-08-30 19:12:47 +0200 | <erisco> | use the FFI and get 1x C |
| 2023-08-30 19:12:55 +0200 | zer0bitz | (~zer0bitz@user/zer0bitz) |
| 2023-08-30 19:13:01 +0200 | <geekosaur> | inline-c |
| 2023-08-30 19:13:34 +0200 | <Inst> | actually, would be funny to do so |
| 2023-08-30 19:14:31 +0200 | <int-e> | mauke: printf a bottleneck for this amount of output? No way... and it isn't; it would start to be noticable at around 10k lines of output. |
| 2023-08-30 19:17:47 +0200 | razetime | (~quassel@49.207.213.87) (Remote host closed the connection) |
| 2023-08-30 19:17:48 +0200 | vpan | (~0@212.117.1.172) |
| 2023-08-30 19:17:52 +0200 | vpan | (~0@212.117.1.172) (Client Quit) |
| 2023-08-30 19:18:53 +0200 | jespada | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) (Quit: Textual IRC Client: www.textualapp.com) |
| 2023-08-30 19:20:41 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-08-30 19:22:50 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2023-08-30 19:25:26 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 245 seconds) |
| 2023-08-30 19:34:06 +0200 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) (Ping timeout: 260 seconds) |
| 2023-08-30 19:35:01 +0200 | bratwurst | (~blaadsfa@2604:3d09:207f:f650:216:3eff:fe5a:a1f8) |
| 2023-08-30 19:35:44 +0200 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) |
| 2023-08-30 19:38:19 +0200 | gawen | (~gawen@user/gawen) (Quit: cya) |
| 2023-08-30 19:39:28 +0200 | <Inst> | le sigh |
| 2023-08-30 19:39:32 +0200 | <Inst> | @int-e |
| 2023-08-30 19:39:32 +0200 | <lambdabot> | Unknown command, try @list |
| 2023-08-30 19:39:42 +0200 | <Inst> | julia got to 36 ms |
| 2023-08-30 19:39:46 +0200 | <Inst> | vs 460 ms on Haskell |
| 2023-08-30 19:40:12 +0200 | <Inst> | very pretty code, too |
| 2023-08-30 19:40:13 +0200 | <Inst> | isfactorian(n, base) = sum(factorial,digits(n,base=base)) == n |
| 2023-08-30 19:41:24 +0200 | <Inst> | not sure if they're auto-parallelizing |
| 2023-08-30 19:42:26 +0200 | <erisco> | never heard of Julia |
| 2023-08-30 19:42:39 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 258 seconds) |
| 2023-08-30 19:42:51 +0200 | <EvanR> | it has a fancy GUI front end |
| 2023-08-30 19:43:12 +0200 | <EvanR> | and can barf LLVM output at you on command so you can inspect it |
| 2023-08-30 19:43:28 +0200 | <erisco> | it is progressively typed? |
| 2023-08-30 19:43:48 +0200 | <EvanR> | what is that |
| 2023-08-30 19:44:07 +0200 | <EvanR> | the opposite of conservatively typed? |
| 2023-08-30 19:44:30 +0200 | <erisco> | you choose how much you want to statically type, everything else is effectively Dynamic |
| 2023-08-30 19:44:40 +0200 | <EvanR> | no, not really |
| 2023-08-30 19:45:32 +0200 | gawen | (~gawen@user/gawen) |
| 2023-08-30 19:47:01 +0200 | falafel | (~falafel@216.68.6.51.dyn.plus.net) |
| 2023-08-30 19:47:28 +0200 | <erisco> | they make it sound like it |
| 2023-08-30 19:47:52 +0200 | <EvanR> | there's a pretty slick way it makes you feel like everything is dynamic but it's not |
| 2023-08-30 19:48:16 +0200 | <EvanR> | as evidenced by the barfed LLVM output xD |
| 2023-08-30 19:48:28 +0200 | <int-e> | Inst: hmm the code at https://rosettacode.org/wiki/Factorions#Julia is different and only testing up to 100k |
| 2023-08-30 19:48:38 +0200 | <int-e> | cheaters all around |
| 2023-08-30 19:48:58 +0200 | <erisco> | looks like the kind of language you'd have for game modding or something, in place of Lua |
| 2023-08-30 19:49:27 +0200 | <EvanR> | it's more marketed as a replacement for fortran |
| 2023-08-30 19:49:52 +0200 | <carbolymer> | is there a function like when, but for alternative i.e.: Alternative f => Bool -> f a -> f a |
| 2023-08-30 19:49:56 +0200 | <EvanR> | (but would not be surprised if it web people take and run with it anyway) |
| 2023-08-30 19:50:18 +0200 | <carbolymer> | basically `whenA cond x = if cond then x else empty` |
| 2023-08-30 19:50:19 +0200 | <erisco> | nah, web people are still building the wasm utopia |
| 2023-08-30 19:51:01 +0200 | <erisco> | maybe Julia can also fight Python |
| 2023-08-30 19:51:34 +0200 | <EvanR> | julia -> llvm -> wasm |
| 2023-08-30 19:52:03 +0200 | <erisco> | yeah now if only wasm didn't suck for building web applications, lol |
| 2023-08-30 19:52:23 +0200 | <int-e> | it's only fair; web applications suck |
| 2023-08-30 19:52:47 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2023-08-30 19:52:49 +0200 | <briandaed> | carbolymer you probably found the one from Agda... |
| 2023-08-30 19:56:21 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2023-08-30 19:58:30 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2023-08-30 19:58:57 +0200 | fendor | (~fendor@2a02:8388:1640:be00:29b8:807b:7fa6:1bcf) |
| 2023-08-30 20:01:17 +0200 | sm | (~sm@plaintextaccounting/sm) (Quit: sm) |
| 2023-08-30 20:01:51 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2023-08-30 20:04:33 +0200 | <Inst> | int-e: very nice implementation |
| 2023-08-30 20:04:43 +0200 | <Inst> | guess how this works? |
| 2023-08-30 20:04:43 +0200 | <Inst> | isfactorian(n, base) = sum(factorial,digits(n,base=base)) == n |
| 2023-08-30 20:04:53 +0200 | <Inst> | this is the 37 ms version |
| 2023-08-30 20:05:30 +0200 | <int-e> | no, that's a microseconds building block in that implementation |
| 2023-08-30 20:06:17 +0200 | <Inst> | factorial is cached up until bigInt results, then gmp |
| 2023-08-30 20:08:31 +0200 | <Inst> | digits is somehow fast |
| 2023-08-30 20:08:31 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::4f8) (Remote host closed the connection) |
| 2023-08-30 20:08:49 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::ccb7) |
| 2023-08-30 20:09:38 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-08-30 20:13:09 +0200 | barzo | (~hd@31.223.52.142) |
| 2023-08-30 20:14:35 +0200 | danza_ | (~francesco@151.19.244.206) |
| 2023-08-30 20:16:18 +0200 | <nyc> | Can I just rm -rf ~/.cabal/store/ or do I have to rm -rf ~/.cabal/ as a whole? |
| 2023-08-30 20:16:28 +0200 | sm | (~sm@plaintextaccounting/sm) (Quit: sm) |
| 2023-08-30 20:16:30 +0200 | <int-e> | Inst: if it is clever about digits() in a loop it could be doing something like this: http://paste.debian.net/1290511/ |
| 2023-08-30 20:16:34 +0200 | hpc | (~juzz@ip98-169-35-163.dc.dc.cox.net) (Ping timeout: 246 seconds) |
| 2023-08-30 20:16:55 +0200 | <geekosaur> | nyc, just the store is fine |
| 2023-08-30 20:17:06 +0200 | danza | (~francesco@151.37.176.153) (Ping timeout: 244 seconds) |
| 2023-08-30 20:17:27 +0200 | <geekosaur> | I wouldn't remove all of ~/.cabal because you also lose cached sources and your config |
| 2023-08-30 20:17:42 +0200 | grnman_ | (~michaelsc@c-66-176-3-51.hsd1.fl.comcast.net) |
| 2023-08-30 20:20:44 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-08-30 20:20:52 +0200 | <Inst> | digits is a built-in afaik |
| 2023-08-30 20:22:50 +0200 | <int-e> | Inst: which is why it's easy to believe that the compiler is clever about the case where it's used in a loop |
| 2023-08-30 20:23:01 +0200 | abrantesasf | (~abrantesa@179.217.48.72) |
| 2023-08-30 20:23:28 +0200 | hpc | (~juzz@ip98-169-35-163.dc.dc.cox.net) |
| 2023-08-30 20:23:28 +0200 | <int-e> | Inst: however I still haven't seen the *complete* program you're testing. |
| 2023-08-30 20:24:03 +0200 | <int-e> | Also rosetta code is annoying because they tend to compare stupid algorithms. |
| 2023-08-30 20:24:15 +0200 | <Inst> | i'm serious, the complete program i'm testing is just that |
| 2023-08-30 20:24:21 +0200 | caryhartline | (~caryhartl@168.182.58.169) (Quit: caryhartline) |
| 2023-08-30 20:24:29 +0200 | <Inst> | isfactorian(n, base) = sum(factorial,digits(n,base=base)) == n |
| 2023-08-30 20:24:35 +0200 | <Inst> | + the rosetta code base |
| 2023-08-30 20:24:39 +0200 | <dolio> | That isn't a complete program. |
| 2023-08-30 20:24:58 +0200 | <Inst> | printallfactorian(base) = println("Factorians for base $base: ", [n for n in 1:100000 if isfactorian(n, base)]) |
| 2023-08-30 20:25:04 +0200 | <int-e> | so you're only testing up to 100k |
| 2023-08-30 20:25:18 +0200 | <int-e> | and you're wondering why it's much faster than a program that tests up to 1.5M |
| 2023-08-30 20:25:20 +0200 | <Inst> | foreach(printallfactorian, 9:12) |
| 2023-08-30 20:25:27 +0200 | <Inst> | ;_; |
| 2023-08-30 20:25:37 +0200 | <Inst> | so, let me try again |
| 2023-08-30 20:26:38 +0200 | <monochrom> | I love it when askers say "you can recover my complete program by composing these 10 fragments from these 10 URLs plus the following 3 patches". |
| 2023-08-30 20:26:40 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-08-30 20:27:04 +0200 | aaronv | (~aaronv@user/aaronv) |
| 2023-08-30 20:27:18 +0200 | <int-e> | I mean I pointed out earlier that the Julia program from the Rosetta page cheats |
| 2023-08-30 20:27:29 +0200 | <monochrom> | Shows a whole lot of entitlement attitude where they think they are entitled to make you do the legwork. |
| 2023-08-30 20:27:38 +0200 | <int-e> | so apparently that didn't connect |
| 2023-08-30 20:27:40 +0200 | <Inst> | "single result which took 6.529 seconds to complete |
| 2023-08-30 20:27:41 +0200 | <Inst> | hmmm |
| 2023-08-30 20:27:41 +0200 | <Inst> | nice |
| 2023-08-30 20:27:53 +0200 | <Inst> | nah, it was pointed out that it cheats in other ays as well |
| 2023-08-30 20:28:07 +0200 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) |
| 2023-08-30 20:28:17 +0200 | <int-e> | Inst: but this particular cheat made it into your test |
| 2023-08-30 20:28:37 +0200 | <monochrom> | And BTW why are we regressing to 20 years ago when these stupid microbenchmarks were a fad? |
| 2023-08-30 20:29:15 +0200 | <monochrom> | I suggest that everyone to not perpetuate any microbenchmarking discussions. |
| 2023-08-30 20:29:16 +0200 | <dolio> | Microbenchmarks are always popular. |
| 2023-08-30 20:29:29 +0200 | <Inst> | because it's fun |
| 2023-08-30 20:29:30 +0200 | <Inst> | it's a toy |
| 2023-08-30 20:29:36 +0200 | <monochrom> | Well yeah but I mean just #haskell. |
| 2023-08-30 20:30:04 +0200 | <monochrom> | There was like a 15-year period of peace when people stopped doing that. |
| 2023-08-30 20:30:45 +0200 | <EvanR> | yeah lets stop and go back to comparing how much industry dollars is spent / made with language X |
| 2023-08-30 20:30:52 +0200 | <monochrom> | pax non benchmarca |
| 2023-08-30 20:30:53 +0200 | <EvanR> | what really matters |
| 2023-08-30 20:31:21 +0200 | <davros1> | It was many years ago that I last looked at haskell.. what kind of backends does it have these days? Is it still mostly that "c--" ; was there interest in LLVM, and do people compile it to WASM aswell or what |
| 2023-08-30 20:31:24 +0200 | <EvanR> | at least it's not if programming language was a car or something |
| 2023-08-30 20:31:27 +0200 | <mauke> | let's go back to code golf |
| 2023-08-30 20:31:44 +0200 | <Inst> | WASM backend is now being supported by GHC team, JS backend as well |
| 2023-08-30 20:31:52 +0200 | <mauke> | early stages, though |
| 2023-08-30 20:31:58 +0200 | <Inst> | yeah :( |
| 2023-08-30 20:32:11 +0200 | <monochrom> | -fllvm exists. Not sure about interest. |
| 2023-08-30 20:32:25 +0200 | <Inst> | there's apparently vector instruction optimizations in fllvm, not sure if it's in the main backend |
| 2023-08-30 20:33:25 +0200 | <EvanR> | it's good we're moving toward targeting relevant platforms like the web. I also recommend preparing for the metafuture VR platform that runs on a platform that people will have forgotten runs on web, need to keep up |
| 2023-08-30 20:34:00 +0200 | <Inst> | IIRC there were a few firms using Haskell for VR, no? |
| 2023-08-30 20:34:15 +0200 | <Inst> | Someone here mentioned their Haskell for AR |
| 2023-08-30 20:34:25 +0200 | <segfaultfizzbuzz> | write haskell in vr, using a browser-based wysiwyg word processor |
| 2023-08-30 20:34:41 +0200 | <erisco> | VR is like game dev, and I think there was like, one grad who did that one time long ago. Last I knew anyways |
| 2023-08-30 20:34:55 +0200 | <dolio> | I seem to recall ghc maintainers kind of complaining about the llvm stuff, as well. |
| 2023-08-30 20:35:13 +0200 | <monochrom> | c-- and llvm are orthogonal. |
| 2023-08-30 20:35:15 +0200 | <Inst> | actually i'm curious, i wonder if the Verse bindings to Unreal can be hijacked |
| 2023-08-30 20:35:26 +0200 | <dolio> | I think llvm as a project is just not aimed at being particularly usable by something like ghc. |
| 2023-08-30 20:35:52 +0200 | <monochrom> | GHC always goes through c--. Afterwards, the choice is x86 or ARM or llvm or js or ... |
| 2023-08-30 20:37:03 +0200 | <monochrom> | OK nevermind, I don't know how early/late js happens in the pipeline. But x86/arm/llvm are definitely after c--. |
| 2023-08-30 20:37:36 +0200 | <dolio> | Going all the way to c-- for JS seems like it'd be weird, but I guess it might happen. |
| 2023-08-30 20:37:41 +0200 | <Rembane> | I want a shortcut to js! |
| 2023-08-30 20:38:34 +0200 | <Inst> | sort of funny trying to troll Julians with the benchmark, though, because we'd consider losing to Haskell a bug, and they're now non-plussed they can't figure out how to optimize past Haskell |
| 2023-08-30 20:38:40 +0200 | <monochrom> | I have found the ultimate shortcut. I wrote js myself. :) |
| 2023-08-30 20:39:10 +0200 | hpc | (~juzz@ip98-169-35-163.dc.dc.cox.net) (Ping timeout: 255 seconds) |
| 2023-08-30 20:39:33 +0200 | <monochrom> | Why are you trolling Julians what's wrong with you |
| 2023-08-30 20:40:09 +0200 | <mauke> | they invented the day |
| 2023-08-30 20:40:17 +0200 | <monochrom> | haha |
| 2023-08-30 20:40:20 +0200 | <int-e> | Inst-igator |
| 2023-08-30 20:40:52 +0200 | hpc | (~juzz@ip98-169-35-163.dc.dc.cox.net) |
| 2023-08-30 20:41:23 +0200 | <Inst> | nah, we're sort of friends, mostly, it just turns out to be trolling since if they end up being slower than Haskell, it beats their language design targets, not really that different than SPJ reposting Jose Valim |
| 2023-08-30 20:41:42 +0200 | <erisco> | it sounds like their language design targets are to be the best at all the things |
| 2023-08-30 20:42:03 +0200 | <int-e> | talk about setting yourself up for failure |
| 2023-08-30 20:42:05 +0200 | <Inst> | they have a nice foothold in machine learning and scientific compute, and i think many of them are happy with that |
| 2023-08-30 20:42:07 +0200 | <monochrom> | I'm going to change subject. |
| 2023-08-30 20:42:11 +0200 | <Inst> | sorry then |
| 2023-08-30 20:42:30 +0200 | <dolio> | erisco: No, this kind of array arithmetic microbenchmark is exactly what Julia is designed for, I think. |
| 2023-08-30 20:42:59 +0200 | <monochrom> | I want to prove that from parametricity the type "f :: (a->b) -> [a] -> [b]" together with "f id = id" implies that f satisfies the functor laws. |
| 2023-08-30 20:43:23 +0200 | <monochrom> | I ended up proving nothing weaker than "f = map". Is this normal? |
| 2023-08-30 20:44:07 +0200 | <dolio> | Yes, that's normal. |
| 2023-08-30 20:44:13 +0200 | <monochrom> | Nice thanks. |
| 2023-08-30 20:44:20 +0200 | <mauke> | no, proving properties of software is not normal |
| 2023-08-30 20:44:55 +0200 | <mauke> | @free f :: (a->b) -> [a] -> [b] |
| 2023-08-30 20:44:55 +0200 | <lambdabot> | h . k = p . g => $map h . f k = f p . $map g |
| 2023-08-30 20:45:33 +0200 | <ncf> | by yoneda f is entirely determined by f id :: [b] -> [b] |
| 2023-08-30 20:45:57 +0200 | <int-e> | take h = p, k = g = id: $map h = f h |
| 2023-08-30 20:46:15 +0200 | <ncf> | (in other words f id :: ℕ -> ℕ) |
| 2023-08-30 20:47:15 +0200 | <ncf> | wait no, forget that |
| 2023-08-30 20:47:26 +0200 | <ncf> | but anyway my first statement still holds |
| 2023-08-30 20:47:56 +0200 | <mauke> | $map h . f id = f h |
| 2023-08-30 20:47:57 +0200 | <mauke> | I see |
| 2023-08-30 20:48:00 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-08-30 20:49:35 +0200 | <EvanR> | are you sure you're not on the something |
| 2023-08-30 20:49:37 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) |
| 2023-08-30 20:49:41 +0200 | barzo | (~hd@31.223.52.142) (Quit: Leaving) |
| 2023-08-30 20:49:58 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-08-30 20:50:00 +0200 | <EvanR> | f id :: N -> N seems to have a lot of freedom but f id :: [b] -> [b] does not? |
| 2023-08-30 20:50:41 +0200 | <EvanR> | on to* |
| 2023-08-30 20:51:13 +0200 | <ncf> | [b] -> [b] can permute elements |
| 2023-08-30 20:51:14 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) |
| 2023-08-30 20:51:29 +0200 | <EvanR> | or change the length of the list |
| 2023-08-30 20:51:41 +0200 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 260 seconds) |
| 2023-08-30 20:52:26 +0200 | <EvanR> | use the length of bound on length as a numeric value |
| 2023-08-30 20:52:33 +0200 | <EvanR> | length or bound |
| 2023-08-30 20:52:43 +0200 | <ncf> | there's exactly one function ℕ -> ℕ that always returns 1, but there are many functions [b] -> [b] that always return singletons |
| 2023-08-30 20:53:14 +0200 | <monochrom> | Thanks ncf, that's nice. |
| 2023-08-30 20:53:24 +0200 | <int-e> | ncf: except for the empty list |
| 2023-08-30 20:53:38 +0200 | <EvanR> | i see |
| 2023-08-30 20:53:42 +0200 | <mauke> | was about to say, not if they're polymorphic like that |
| 2023-08-30 20:53:49 +0200 | <ncf> | what about the empty list? |
| 2023-08-30 20:53:53 +0200 | <dolio> | Yeah, it's like (n : ℕ) -> [Fin n] or something. |
| 2023-08-30 20:53:54 +0200 | <int-e> | > last [] |
| 2023-08-30 20:53:55 +0200 | <lambdabot> | *Exception: Prelude.last: empty list |
| 2023-08-30 20:53:59 +0200 | <mauke> | because I can set b = Void |
| 2023-08-30 20:54:05 +0200 | <dolio> | Except the Haskell lists can be infinite. |
| 2023-08-30 20:54:25 +0200 | <ncf> | oh yeah |
| 2023-08-30 20:54:48 +0200 | <dolio> | Also you can stick bottoms in wherever you want, etc. |
| 2023-08-30 20:54:58 +0200 | <monochrom> | I think "can permute" best illustrates your point that [b]->[b] is richer than N->N. |
| 2023-08-30 20:57:10 +0200 | nek0 | (~nek0@2a01:4f8:222:2b41::12) (Quit: The Lounge - https://thelounge.chat) |
| 2023-08-30 21:02:59 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) (Quit: Leaving) |
| 2023-08-30 21:04:37 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
| 2023-08-30 21:06:11 +0200 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 245 seconds) |
| 2023-08-30 21:14:09 +0200 | Lycurgus | (~juan@user/Lycurgus) |
| 2023-08-30 21:16:29 +0200 | caryhartline | (~caryhartl@168.182.58.169) |
| 2023-08-30 21:18:49 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2023-08-30 21:20:43 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) |
| 2023-08-30 21:23:44 +0200 | arthurvl | earthy |
| 2023-08-30 21:25:31 +0200 | ft | (~ft@p508db658.dip0.t-ipconnect.de) |
| 2023-08-30 21:27:43 +0200 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) |
| 2023-08-30 21:29:57 +0200 | vglfr | (~vglfr@188.239.201.89) (Ping timeout: 244 seconds) |
| 2023-08-30 21:31:09 +0200 | vglfr | (~vglfr@cli-188-239-201-89.bbn.slav.dn.ua) |
| 2023-08-30 21:36:58 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) |
| 2023-08-30 21:37:46 +0200 | mima | (~mmh@net-93-67-213-89.cust.vodafonedsl.it) |
| 2023-08-30 21:38:05 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2023-08-30 21:38:32 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2023-08-30 21:40:59 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2023-08-30 21:41:34 +0200 | Lycurgus | (~juan@user/Lycurgus) (Quit: Tschüss) |
| 2023-08-30 21:45:02 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::ccb7) (Remote host closed the connection) |
| 2023-08-30 21:45:19 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::bd68) |
| 2023-08-30 21:45:29 +0200 | fendor | (~fendor@2a02:8388:1640:be00:29b8:807b:7fa6:1bcf) (Remote host closed the connection) |
| 2023-08-30 21:46:06 +0200 | briandaed | (~briandaed@185.234.210.211.r.toneticgroup.pl) (Remote host closed the connection) |
| 2023-08-30 21:47:44 +0200 | <Inst> | curious, is async magic? |
| 2023-08-30 21:48:08 +0200 | <Inst> | it feels like compiler magic |
| 2023-08-30 21:48:28 +0200 | <geekosaur> | forkIO involves some compiler magic but async itself is not |
| 2023-08-30 21:48:31 +0200 | <mauke> | normal library built on top of threads, as far as I know |
| 2023-08-30 21:48:49 +0200 | <geekosaur> | mostly it deals with a lot of tedious stuff you need to do for reliability |
| 2023-08-30 21:49:02 +0200 | <geekosaur> | I think the parconc book covers what's under the covers? |
| 2023-08-30 21:49:06 +0200 | <geekosaur> | @where parconc |
| 2023-08-30 21:49:06 +0200 | <lambdabot> | https://www.safaribooksonline.com/library/view/parallel-and-concurrent/9781449335939/ |
| 2023-08-30 21:49:15 +0200 | <dminuoso> | Much of the magic behind async that makes is work nicely is in fact built-in RTS behavior: |
| 2023-08-30 21:49:32 +0200 | <dminuoso> | Green threads, and lots of blocking IO that under the hood uses asynchronous APIs. |
| 2023-08-30 21:49:50 +0200 | <Inst> | i'm reading the source code |
| 2023-08-30 21:49:55 +0200 | <Inst> | https://hackage.haskell.org/package/async-2.2.4/docs/src/Control.Concurrent.Async.html#forConcurre… |
| 2023-08-30 21:50:05 +0200 | <Inst> | the stuff with runConcurrently and Concurrently, I don't see the ForkIO |
| 2023-08-30 21:50:13 +0200 | <dminuoso> | Its mostly not that apparent without the `async` library, because you generally dont write as much asynchronous code without that library. |
| 2023-08-30 21:50:14 +0200 | <Inst> | it has no traversable instance, but it has an applicative instance |
| 2023-08-30 21:50:39 +0200 | <Inst> | ahhh, the payload is in the applicative instance |
| 2023-08-30 21:50:50 +0200 | <tomsmeding> | vim |
| 2023-08-30 21:50:52 +0200 | <tomsmeding> | oops |
| 2023-08-30 21:52:22 +0200 | idgaen | (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.0.2) |
| 2023-08-30 21:52:51 +0200 | <Inst> | trying to figure out why i can't get mapConcurrent to work in such a way that the values are computed, and I get an await, before I I traverse print over it |
| 2023-08-30 21:53:16 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
| 2023-08-30 21:53:18 +0200 | <Inst> | it feels like if I throw Deepseq.force on it, the concurrency just goes away |
| 2023-08-30 21:56:00 +0200 | lortabac | (~lortabac@88.125.6.227) |
| 2023-08-30 21:56:12 +0200 | <EvanR> | mapConcurrently? |
| 2023-08-30 21:56:20 +0200 | masterbuilder | (~masterbui@user/masterbuilder) (Remote host closed the connection) |
| 2023-08-30 21:56:43 +0200 | <EvanR> | that's an IO thing not sure what deepseq has to do with it |
| 2023-08-30 21:56:59 +0200 | <Inst> | the thing is, concurrency is non-deterministic |
| 2023-08-30 21:57:18 +0200 | <Inst> | i'm trying to force the system to wait for all results to complete before allowing an attempt to print the results, because you know what the alternative is |
| 2023-08-30 21:57:20 +0200 | <EvanR> | what does deepseq have to do with that either |
| 2023-08-30 21:57:44 +0200 | <Inst> | i mean there's no unsafeInterleaveIO, right? |
| 2023-08-30 21:57:55 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2023-08-30 21:57:55 +0200 | <EvanR> | I was going to ask if you're doing that |
| 2023-08-30 21:58:44 +0200 | <EvanR> | if you try to print the results of mapConcurrently, it automatically waits |
| 2023-08-30 21:58:51 +0200 | <EvanR> | if necessary |
| 2023-08-30 21:59:05 +0200 | <EvanR> | and the results are always in order |
| 2023-08-30 22:01:36 +0200 | <EvanR> | and you can't await it because it's not of Async type |
| 2023-08-30 22:02:27 +0200 | <Inst> | bleh, i can't go debug this :( |
| 2023-08-30 22:02:31 +0200 | <Inst> | out of time anyways |
| 2023-08-30 22:04:28 +0200 | <Inst> | the real problem is, i benchmark at 160 ms with out of order concurrency, but if I try to stabilize it |
| 2023-08-30 22:04:34 +0200 | <Inst> | 460 ms |
| 2023-08-30 22:05:54 +0200 | <tomsmeding> | Inst: DeepSeq.force inside the concurrent thread? |
| 2023-08-30 22:06:03 +0200 | <tomsmeding> | presumably mapConcurrently WHNF's the list elements, otherwise it's not much use |
| 2023-08-30 22:06:12 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht) |
| 2023-08-30 22:06:28 +0200 | <c_wraith> | mapConcurrently runs *IO* for each element. |
| 2023-08-30 22:06:31 +0200 | <int-e> | we haven't seen the actual code, have we? |
| 2023-08-30 22:06:33 +0200 | <c_wraith> | It only forces if the IO does |
| 2023-08-30 22:07:34 +0200 | Sciencentistguy0 | (~sciencent@hacksoc/ordinary-member) |
| 2023-08-30 22:08:58 +0200 | <Inst> | it's the same code as the one you put in, except I slapped in mapConcurrently |
| 2023-08-30 22:09:05 +0200 | <Inst> | I think the problem is probably to do with printf |
| 2023-08-30 22:09:13 +0200 | <c_wraith> | since mapConcurrently blocks until all IO is done, it looks like the problem is that IO isn't forcing values |
| 2023-08-30 22:09:37 +0200 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 255 seconds) |
| 2023-08-30 22:09:44 +0200 | <c_wraith> | Unless you're not using mapConcurrently from async, I guess. There could be other things with that name. |
| 2023-08-30 22:10:20 +0200 | Sciencentistguy | (~sciencent@hacksoc/ordinary-member) (Ping timeout: 248 seconds) |
| 2023-08-30 22:10:21 +0200 | Sciencentistguy0 | Sciencentistguy |
| 2023-08-30 22:10:21 +0200 | <int-e> | Inst: even with that description there's probably a dozen ways to match that |
| 2023-08-30 22:11:10 +0200 | <Inst> | https://paste.tomsmeding.com/JMK122AL |
| 2023-08-30 22:11:33 +0200 | <int-e> | and details matter because a lot of this is about forcing evaluation of the right things at the right point |
| 2023-08-30 22:11:47 +0200 | <Inst> | iirc IO isn't lazy unless you unsafeInterleaveIO |
| 2023-08-30 22:12:08 +0200 | <Inst> | or use a function that has it baked in somewhere |
| 2023-08-30 22:12:32 +0200 | <c_wraith> | Inst: congratulations, you're forcing IO values. that's pretty useless |
| 2023-08-30 22:12:36 +0200 | <tomsmeding> | (which uses unsafeInterleaveIO internally) |
| 2023-08-30 22:12:45 +0200 | <EvanR> | mapConcurrently spawns a thread for each element then awaits them all, then returns the resulting structure |
| 2023-08-30 22:12:49 +0200 | <int-e> | lol, force <$> |
| 2023-08-30 22:12:53 +0200 | <int-e> | doesn't force anything |
| 2023-08-30 22:13:04 +0200 | <c_wraith> | Inst: use evaluate |
| 2023-08-30 22:13:06 +0200 | <EvanR> | ok yeah deepseq doesn't do anything |
| 2023-08-30 22:13:37 +0200 | <int-e> | evaluate (force (b, result b)) I guess |
| 2023-08-30 22:13:46 +0200 | <c_wraith> | int-e: yes, that. |
| 2023-08-30 22:13:57 +0200 | <tomsmeding> | % (return undefined >>= \_ -> return 42) :: IO Int |
| 2023-08-30 22:13:57 +0200 | <yahb2> | 42 |
| 2023-08-30 22:14:02 +0200 | <tomsmeding> | Inst: IO is not strict |
| 2023-08-30 22:14:33 +0200 | <tomsmeding> | % (return undefined >>= \x -> Control.Exception.evaluate x >> return 42) :: IO Int |
| 2023-08-30 22:14:34 +0200 | <yahb2> | *** Exception: Prelude.undefined ; CallStack (from HasCallStack): ; error, called at libraries/base/GHC/Err.hs:74:14 in base:GHC.Err ; undefined, called at <interactive>:17:9 in interactive:Ghci4 |
| 2023-08-30 22:15:05 +0200 | <int-e> | f <$> pure x is 100% equivalent to pure (f x) |
| 2023-08-30 22:15:25 +0200 | <tomsmeding> | it would have worked if IO.>>= was strict in the value |
| 2023-08-30 22:15:36 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-08-30 22:15:52 +0200 | <c_wraith> | Ok, I was wrong when I said you were forcing the IO value. You were just doing the equivalent of pure (force x), as int-e says |
| 2023-08-30 22:15:53 +0200 | grnman_ | (~michaelsc@c-66-176-3-51.hsd1.fl.comcast.net) (Ping timeout: 246 seconds) |
| 2023-08-30 22:16:06 +0200 | <EvanR> | is the point to compute some stuff in threads, do nothing with it, then quit with no output. Then use evaluate in each action |
| 2023-08-30 22:16:14 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 246 seconds) |
| 2023-08-30 22:16:16 +0200 | <c_wraith> | evaluate is 100$ semantically the correct operation for this use case |
| 2023-08-30 22:16:20 +0200 | <c_wraith> | err. 100% |
| 2023-08-30 22:16:44 +0200 | <EvanR> | @src evaluate |
| 2023-08-30 22:16:44 +0200 | <lambdabot> | Source not found. Your mind just hasn't been the same since the electro-shock, has it? |
| 2023-08-30 22:17:03 +0200 | <c_wraith> | I do think it's a bit weird to have it in Control.Exception. I see why it's there, but.. it's more broadly useful than that |
| 2023-08-30 22:17:28 +0200 | <Inst> | okay, but still, the problem is that i don't get a concurrency speedup under most circumstances |
| 2023-08-30 22:17:38 +0200 | <Inst> | unless i leave the code free-running |
| 2023-08-30 22:17:49 +0200 | <Inst> | erm, unless it let the order be non-deterministic |
| 2023-08-30 22:17:50 +0200 | <int-e> | Hah, `evaluate $ force x` is literally an example in the documentation of `evaluate` |
| 2023-08-30 22:18:06 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2023-08-30 22:18:28 +0200 | <EvanR> | Inst, async is more for doing stuff concurrently. If you wanted speedups you want parallel haskell. Parallel combinators |
| 2023-08-30 22:18:41 +0200 | <EvanR> | Control.Parallel |
| 2023-08-30 22:18:48 +0200 | <int-e> | EvanR: since I'm looking at this anyway: evaluate a = IO $ \s -> seq# a s |
| 2023-08-30 22:18:57 +0200 | <mauke> | https://hackage.haskell.org/package/deepseq-1.5.0.0/docs/Control-DeepSeq.html#v:force |
| 2023-08-30 22:19:00 +0200 | <mauke> | also here |
| 2023-08-30 22:19:09 +0200 | <c_wraith> | Inst: what order? mapConcurrently returns the list of results in the same order as the list of inputs. |
| 2023-08-30 22:19:11 +0200 | <EvanR> | deepseq was just the wrong thing |
| 2023-08-30 22:19:11 +0200 | <mauke> | I like the view pattern example |
| 2023-08-30 22:19:31 +0200 | <int-e> | :t GHC.Exts.seq# |
| 2023-08-30 22:19:32 +0200 | <lambdabot> | a -> GHC.Prim.State# d -> (# GHC.Prim.State# d, a #) |
| 2023-08-30 22:19:42 +0200 | <int-e> | magic! |
| 2023-08-30 22:19:56 +0200 | <EvanR> | magic hash |
| 2023-08-30 22:20:09 +0200 | <EvanR> | RealWorld is deeply magical |
| 2023-08-30 22:20:16 +0200 | <Inst> | this seems like the use of excessive force |
| 2023-08-30 22:20:17 +0200 | <Inst> | main = do |
| 2023-08-30 22:20:17 +0200 | <Inst> | traverse_ ((uncurry (printf "Factorions for base %2d: %s\n"))) =<< forConcurrently [9..12] (\b -> evaluate $ force (b, result b)) |
| 2023-08-30 22:20:38 +0200 | <c_wraith> | well now you've moved printing inside the concurrently |
| 2023-08-30 22:20:44 +0200 | bratwurst | (~blaadsfa@2604:3d09:207f:f650:216:3eff:fe5a:a1f8) (Ping timeout: 246 seconds) |
| 2023-08-30 22:20:46 +0200 | <c_wraith> | of course that's going to be non-deterministic. |
| 2023-08-30 22:20:51 +0200 | <Inst> | this is deterministic |
| 2023-08-30 22:20:54 +0200 | <Inst> | and concurrent |
| 2023-08-30 22:21:00 +0200 | <int-e> | c_wraith: no? |
| 2023-08-30 22:21:02 +0200 | <c_wraith> | oh, gah. I did misread the args. |
| 2023-08-30 22:21:20 +0200 | <int-e> | this looks like it should work |
| 2023-08-30 22:21:23 +0200 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) |
| 2023-08-30 22:21:26 +0200 | <Inst> | but why? |
| 2023-08-30 22:21:34 +0200 | <int-e> | why what? |
| 2023-08-30 22:21:44 +0200 | <Inst> | why is it working whereas, say, removing evaluate and force doesn't? |
| 2023-08-30 22:21:55 +0200 | <c_wraith> | because of laziness? |
| 2023-08-30 22:22:20 +0200 | <tomsmeding> | Inst: see my yahb example above |
| 2023-08-30 22:22:30 +0200 | <tomsmeding> | % (return undefined >>= \_ -> return 42) :: IO Int -- Inst, this one |
| 2023-08-30 22:22:30 +0200 | <yahb2> | 42 |
| 2023-08-30 22:22:41 +0200 | <tomsmeding> | IO's >>= does not evaluate the value to WHNF is not strict |
| 2023-08-30 22:22:46 +0200 | <c_wraith> | like, when you create a thread and tell it to just return an expression that has no reason to be evaluated... it does exactly what you said. No more. |
| 2023-08-30 22:22:47 +0200 | <tomsmeding> | hence the 'evaluate' is necessary |
| 2023-08-30 22:22:48 +0200 | <int-e> | without the evaluate and force it'll happily put unevaluated thunks in parallel, collect them into a list, and then printing will trigger the real evaluation |
| 2023-08-30 22:22:51 +0200 | <Inst> | so, let me think of this another way, without the evaluate / force |
| 2023-08-30 22:22:55 +0200 | <tomsmeding> | and the 'force' is necessary because the 'evaluate' forces just the (,) |
| 2023-08-30 22:22:57 +0200 | <Inst> | the forConcurrently does nothing |
| 2023-08-30 22:23:07 +0200 | <int-e> | s/put/construct |
| 2023-08-30 22:23:11 +0200 | <mauke> | "I wish to perform my effects concurrently. Also I have no effects. Why isn't it doing anything?" |
| 2023-08-30 22:23:25 +0200 | <EvanR> | nothing in haskell is evaluated unless required by something. Not to be confused with how IO is executed, which happens sequentially in order. And they're separate concepts |
| 2023-08-30 22:23:36 +0200 | <int-e> | Inst: it does something, just less than you wanted |
| 2023-08-30 22:23:52 +0200 | <c_wraith> | Inst: forConcurrently is doing something, it's just useless without the something being a sufficiently large chunk of work. |
| 2023-08-30 22:24:18 +0200 | <int-e> | it's like cooking coffee in parallel with 4 people taking orders but only one coffee machine |
| 2023-08-30 22:24:27 +0200 | lzszt | (~lzszt@2001:9e8:2dea:5800:d0b7:7b8a:c9f4:ac3c) (Quit: Client closed) |
| 2023-08-30 22:24:45 +0200 | <int-e> | (assuming people were able to order coffee quickly... it's a bad analogy) |
| 2023-08-30 22:24:53 +0200 | <c_wraith> | ultimately, this is because async is about concurrency, not parallelism |
| 2023-08-30 22:24:56 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2023-08-30 22:25:01 +0200 | <Inst> | so the for_ is actually causing the effects and causing evaluation otherwise |
| 2023-08-30 22:25:02 +0200 | <Inst> | and when it's causing the effects, it's evaluating the underlying values |
| 2023-08-30 22:25:02 +0200 | <Inst> | so then in which case, no speed-up, pair evaluate force, speedup |
| 2023-08-30 22:25:02 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::bd68) (Remote host closed the connection) |
| 2023-08-30 22:25:10 +0200 | <c_wraith> | it's intended for allowing *effects* to interleave between multiple actions |
| 2023-08-30 22:25:15 +0200 | <EvanR> | i greatly appreciate when the owner comes out and yells over the line "who here just wants basic cup of coffee" |
| 2023-08-30 22:25:20 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::4f8) |
| 2023-08-30 22:25:44 +0200 | <EvanR> | fast path |
| 2023-08-30 22:26:00 +0200 | <c_wraith> | If you specifically want a speedup from using more than one thread of execution in a single calculation, you are asking for parallelism |
| 2023-08-30 22:26:21 +0200 | int-e | would like to point out how much easier this became once we had the actual code. |
| 2023-08-30 22:27:11 +0200 | <mauke> | oh, it's the legwork all over again |
| 2023-08-30 22:27:29 +0200 | <Inst> | tbh this seems awfully footgunny |
| 2023-08-30 22:27:38 +0200 | <Inst> | the reason i didn't want to resort to par monad / rpar etc |
| 2023-08-30 22:27:40 +0200 | <c_wraith> | Inst: that's because you're using the wrong tool for the job |
| 2023-08-30 22:27:56 +0200 | <EvanR> | par isn't a monad |
| 2023-08-30 22:27:58 +0200 | <EvanR> | :t par |
| 2023-08-30 22:27:59 +0200 | <lambdabot> | error: |
| 2023-08-30 22:27:59 +0200 | <lambdabot> | • Variable not in scope: par |
| 2023-08-30 22:27:59 +0200 | <lambdabot> | • Perhaps you meant one of these: |
| 2023-08-30 22:28:02 +0200 | <Inst> | did not want to play with spark herding |
| 2023-08-30 22:28:05 +0200 | <c_wraith> | there is a Par monad. |
| 2023-08-30 22:28:11 +0200 | <EvanR> | par :: a -> b -> b |
| 2023-08-30 22:28:16 +0200 | lortabac | (~lortabac@88.125.6.227) (Quit: WeeChat 2.8) |
| 2023-08-30 22:28:21 +0200 | <Inst> | https://hackage.haskell.org/package/monad-par |
| 2023-08-30 22:28:21 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) (Quit: Leaving) |
| 2023-08-30 22:29:00 +0200 | <EvanR> | parMap :: Strategy b -> (a -> b) -> [a] -> [b] |
| 2023-08-30 22:29:07 +0200 | <Inst> | i browsed parallel and concurrent computing in haskell in the last year or so |
| 2023-08-30 22:29:09 +0200 | <EvanR> | seems pretty straightforward |
| 2023-08-30 22:29:20 +0200 | <Inst> | so i still remember par monad, you're suggesting people don't use it |
| 2023-08-30 22:29:30 +0200 | <Inst> | i get anxiety when sparks fizzle :( |
| 2023-08-30 22:29:32 +0200 | <Inst> | it's sort of a pain |
| 2023-08-30 22:29:39 +0200 | <c_wraith> | sparks are supposed to fizzle. |
| 2023-08-30 22:29:50 +0200 | <Inst> | either, one, no sparks fizzle but you get no speedup, or two, sparks fizzle and you're at the optimum point |
| 2023-08-30 22:30:07 +0200 | <c_wraith> | ... admittedly, you should try to keep the number of sparks fizzling below the number that are converted... |
| 2023-08-30 22:30:12 +0200 | <Inst> | i actually go nuts and pair BOTH |
| 2023-08-30 22:30:21 +0200 | <Inst> | par monad, other concurrency tricks |
| 2023-08-30 22:30:29 +0200 | <Inst> | erm, other parallelism handlers, with concurrency |
| 2023-08-30 22:30:33 +0200 | <EvanR> | it just sounded like you were ignoring the parallel package and going to some monad |
| 2023-08-30 22:30:54 +0200 | <EvanR> | but it sounded like you just wanted to run a list of computations in parallel |
| 2023-08-30 22:31:10 +0200 | <int-e> | It's funny how messing with the evaluation order seems to require an understanding of the evaluation order (laziness and strictness)... |
| 2023-08-30 22:31:19 +0200 | <Inst> | i'm wondering, in other people's parallelism models, do they waste work this way? |
| 2023-08-30 22:34:02 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-08-30 22:34:39 +0200 | <c_wraith> | I don't think I've seen optimistic parallelism anywhere else. |
| 2023-08-30 22:34:58 +0200 | <c_wraith> | But I've only seen real parallelism in other places in data-parallel libraries. |
| 2023-08-30 22:35:01 +0200 | <c_wraith> | (or languages) |
| 2023-08-30 22:35:31 +0200 | <c_wraith> | everything else is concurrency that requires you to manually convert it into parallelism |
| 2023-08-30 22:37:03 +0200 | <Inst> | so wait, unsafeInterleaveIO only makes the effects lazy, because the values are lazy by default, no? |
| 2023-08-30 22:37:20 +0200 | <c_wraith> | yes |
| 2023-08-30 22:37:39 +0200 | <c_wraith> | unsafeInterleaveIO is a weird form of concurrency that causes effects to be demand-driven. |
| 2023-08-30 22:38:21 +0200 | <EvanR> | which is what we would be dealing with if haskell didn't decide on purity |
| 2023-08-30 22:38:27 +0200 | <EvanR> | dealing with everywhere |
| 2023-08-30 22:38:34 +0200 | <Inst> | w/e, I need to stop procrastinating, my intended mode of procrastination was learning lenses so I could do a three-line solution to Jose Valim's problem |
| 2023-08-30 22:39:24 +0200 | <Inst> | here's a better question, people gave me like 23928 docs on laziness in theory, but what's the best way to gain an intuition and reflex for laziness? |
| 2023-08-30 22:39:44 +0200 | <EvanR> | evaluate some example expressions using various strategies |
| 2023-08-30 22:39:58 +0200 | <c_wraith> | https://apfelmus.nfshost.com/blog/2013/08/21-space-invariants.html this is the only *really good* explanation I've ever seen. |
| 2023-08-30 22:41:02 +0200 | <c_wraith> | It's all about understanding that evaluation is demand-driven, and what tools you have to link particular demands to particular evaluations. |
| 2023-08-30 22:41:06 +0200 | <int-e> | stick Debug.Trace.trace calls everywhere in your code and try to predict the order in which they're printed |
| 2023-08-30 22:41:23 +0200 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 246 seconds) |
| 2023-08-30 22:41:25 +0200 | <dolio> | Nah, that's not necessarily a good idea. |
| 2023-08-30 22:41:38 +0200 | <dolio> | Because GHC will just reorder them sometimes. |
| 2023-08-30 22:41:46 +0200 | <Inst> | oh, btw |
| 2023-08-30 22:41:49 +0200 | <Inst> | did you guys see this yet? |
| 2023-08-30 22:42:03 +0200 | <Inst> | https://hackage.haskell.org/package/debug-trace-file |
| 2023-08-30 22:42:05 +0200 | <int-e> | dolio: And then you've learned something too :-P (I'm somewhat serious, somewhat joking...) |
| 2023-08-30 22:42:25 +0200 | <Inst> | tbh, to an extent, that sounds like an interesting art project |
| 2023-08-30 22:42:48 +0200 | <Inst> | use the debug-trace runs as seeds to generative art |
| 2023-08-30 22:43:14 +0200 | <int-e> | sounds like another distraction from whatever you said you needed to do |
| 2023-08-30 22:43:19 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-08-30 22:45:15 +0200 | michalz | (~michalz@185.246.207.203) (Remote host closed the connection) |
| 2023-08-30 22:47:48 +0200 | acidjnk | (~acidjnk@p200300d6e7072f02ccbbb6636abe1529.dip0.t-ipconnect.de) (Ping timeout: 258 seconds) |
| 2023-08-30 22:48:05 +0200 | bratwurst | (~blaadsfa@2604:3d09:207f:f650:216:3eff:fe5a:a1f8) |
| 2023-08-30 22:52:01 +0200 | sm | (~sm@plaintextaccounting/sm) (Quit: sm) |
| 2023-08-30 22:58:25 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
| 2023-08-30 23:00:16 +0200 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) |
| 2023-08-30 23:02:04 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::4f8) (Ping timeout: 248 seconds) |
| 2023-08-30 23:06:20 +0200 | vglfr | (~vglfr@cli-188-239-201-89.bbn.slav.dn.ua) (Ping timeout: 248 seconds) |
| 2023-08-30 23:14:02 +0200 | vglfr | (~vglfr@2a0d:3344:148d:7a00:fdd5:1482:7428:6489) |
| 2023-08-30 23:18:05 +0200 | <monochrom> | I don't think GHC is all that random. |
| 2023-08-30 23:18:32 +0200 | <monochrom> | It reorders code for optimization not for randomization. |
| 2023-08-30 23:19:14 +0200 | <monochrom> | But ghci also has a debugger that exposes unoptimized evaluation order. |
| 2023-08-30 23:20:43 +0200 | falafel | (~falafel@216.68.6.51.dyn.plus.net) (Ping timeout: 255 seconds) |
| 2023-08-30 23:21:45 +0200 | <dolio> | It's not random, but anticipating the exact order it will put trace statements in while optimizing can be difficult. |
| 2023-08-30 23:22:09 +0200 | <monochrom> | I just mean it falls shorts of generating art. |
| 2023-08-30 23:22:10 +0200 | <dolio> | And probably isn't a very useful skill. |
| 2023-08-30 23:22:20 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-08-30 23:22:55 +0200 | Guest|91 | (~Guest|91@023-084-120-023.res.spectrum.com) |
| 2023-08-30 23:24:23 +0200 | abrantesasf | (~abrantesa@179.217.48.72) (Remote host closed the connection) |
| 2023-08-30 23:25:46 +0200 | caryhartline | (~caryhartl@168.182.58.169) (Quit: caryhartline) |
| 2023-08-30 23:27:01 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 255 seconds) |
| 2023-08-30 23:31:41 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2023-08-30 23:33:23 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2023-08-30 23:34:40 +0200 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 255 seconds) |
| 2023-08-30 23:35:48 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot) |
| 2023-08-30 23:39:18 +0200 | grnman_ | (~michaelsc@c-66-176-3-51.hsd1.fl.comcast.net) |
| 2023-08-30 23:39:49 +0200 | Guest|91 | (~Guest|91@023-084-120-023.res.spectrum.com) (Quit: Connection closed) |
| 2023-08-30 23:39:53 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-08-30 23:44:22 +0200 | gatekempt | (~gatekempt@user/gatekempt) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2023-08-30 23:47:24 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 248 seconds) |
| 2023-08-30 23:54:33 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2023-08-30 23:56:36 +0200 | aaronv | (~aaronv@user/aaronv) (Remote host closed the connection) |
| 2023-08-30 23:57:15 +0200 | texasmynsted | (~username@99.96.221.112) (Quit: WeeChat 3.0) |
| 2023-08-30 23:57:35 +0200 | texasmynsted | (~username@99.96.221.112) |