Newest at the top
| 2025-01-22 12:38:55 +0100 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-01-22 12:35:58 +0100 | benjamin | (~benjamin@2a03:4b80:a720:7ac0:3716:ccab:82b8:4e6a) |
| 2025-01-22 12:33:28 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-01-22 12:32:31 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-01-22 12:31:29 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Client Quit) |
| 2025-01-22 12:30:39 +0100 | euleritian | (~euleritia@dynamic-176-006-138-118.176.6.pool.telefonica.de) |
| 2025-01-22 12:30:29 +0100 | euleritian | (~euleritia@ip2504f9f4.dynamic.kabel-deutschland.de) (Ping timeout: 244 seconds) |
| 2025-01-22 12:30:24 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-01-22 12:28:55 +0100 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 252 seconds) |
| 2025-01-22 12:26:39 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-01-22 12:25:57 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-22 12:24:33 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:8ff4:ecd1:bf2c:3514) ubert |
| 2025-01-22 12:22:06 +0100 | <geekosaur> | strictly speaking there is, but it's because lists are (linked) lists so sequential is pretty much the rule of the day |
| 2025-01-22 12:21:09 +0100 | <hellwolf> | There is nothing "sequential" about the list monad, e.g. |
| 2025-01-22 12:21:09 +0100 | <hellwolf> | yea, that's probably a better phrase of cause and effect. |
| 2025-01-22 12:21:09 +0100 | <hellwolf> | 01-22 13:17 <geekosaur> the specific way IO and ST use it guarantees sequencing, and that is the sole reason that they are monads |
| 2025-01-22 12:20:48 +0100 | alexherbo2 | (~alexherbo@2a02-8440-350e-d10b-25a2-ca7e-51a0-4409.rev.sfr.net) (Remote host closed the connection) |
| 2025-01-22 12:19:40 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-01-22 12:19:12 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-01-22 12:18:57 +0100 | <geekosaur> | whereas, do you know about accursedUnutterablePerformIO? all it does is inline runRW#. and that causes the world to come unraveled |
| 2025-01-22 12:18:07 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-01-22 12:17:57 +0100 | <geekosaur> | the specific way IO and ST use it guarantees sequencing, and that is the sole reason that they are monads |
| 2025-01-22 12:17:23 +0100 | <hellwolf> | re that "sequencing", I recently fixed a bug in a monad that I implemented, where I had a bug related to "sequencing". The short story, it didn't. But it's not monad's fault. That starts to make me to realign my intuition. I can't fully articulate everything rigorously yet, but I definitely would not assume monad means sequences. |
| 2025-01-22 12:13:58 +0100 | <geekosaur> | (they just provide sequencing, the real magic is buried in `runRW#`) |
| 2025-01-22 12:13:31 +0100 | <geekosaur> | (granting that what Clean claims about Haskell is BS because monads have nothing to do with how IO and ST work) |
| 2025-01-22 12:12:53 +0100 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 248 seconds) |
| 2025-01-22 12:11:17 +0100 | <hellwolf> | | However, Clean deals with mutable state and input/output (I/O) through a uniqueness type system, in contrast to Haskell's use of monads. |
| 2025-01-22 12:11:09 +0100 | agent314 | (~quassel@208.131.130.116) (Ping timeout: 260 seconds) |
| 2025-01-22 12:11:01 +0100 | agent314_ | (~quassel@208.131.130.89) agent314 |
| 2025-01-22 12:08:47 +0100 | <geekosaur> | Clean uses uniqueness types instead |
| 2025-01-22 12:08:37 +0100 | <geekosaur> | they said "IO monad" |
| 2025-01-22 12:08:32 +0100 | <homo> | I don't recall clean having IO monad |
| 2025-01-22 12:08:03 +0100 | <merijn> | kuribas: Clean? |
| 2025-01-22 12:07:38 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-01-22 12:07:12 +0100 | j1n37- | (~j1n37@user/j1n37) (Ping timeout: 246 seconds) |
| 2025-01-22 12:05:32 +0100 | <homo> | kuribas try working with communities that use haxe and guile, you'll understand what I mean by pretty syntax |
| 2025-01-22 12:04:19 +0100 | <kuribas> | I wouldn't call haskell "pretty syntax". |
| 2025-01-22 12:03:57 +0100 | <kuribas> | there idris2 with optional lazyness. |
| 2025-01-22 12:03:50 +0100 | agent314 | (~quassel@208.131.130.116) agent314 |
| 2025-01-22 12:03:39 +0100 | agent314 | (~quassel@208.131.130.89) (Ping timeout: 265 seconds) |
| 2025-01-22 12:03:00 +0100 | <homo> | I'll say it more completely: lazy statically-typed with IO monad and pretty syntax, combination of which cannot be found in other languages |
| 2025-01-22 12:02:59 +0100 | <geekosaur> | curry |
| 2025-01-22 12:01:48 +0100 | <kuribas> | homo: "lazy statically-typed", are there other than haskell? |
| 2025-01-22 12:01:23 +0100 | pointlessslippe1 | (~pointless@62.106.85.17) pointlessslippe1 |
| 2025-01-22 11:58:55 +0100 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 264 seconds) |
| 2025-01-22 11:58:29 +0100 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-01-22 11:58:10 +0100 | <homo> | hellwolf I'm focused on something more realistic than bootstrapping ghc and porting ghc to different platform (whether it is processor instuction set or operating system), bootstrapping haskell on different platform doesn't imply bootstrapping ghc, I don't intend to sound like ghc's stakeholder, rather I respect their lack of interest by not working with them |
| 2025-01-22 11:57:44 +0100 | pointlessslippe1 | (~pointless@62.106.85.17) (Read error: Connection reset by peer) |
| 2025-01-22 11:50:46 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-01-22 11:47:53 +0100 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 245 seconds) |