Newest at the top
| 2026-01-25 23:44:26 +0100 | <tomsmeding> | our functions either recurse or traverse |
| 2026-01-25 23:44:23 +0100 | <monochrom> | https://www.slideshare.net/slideshow/fp-patterns-buildstufflt/41936137#13 >:) |
| 2026-01-25 23:43:32 +0100 | <monochrom> | But we are worse than calling everything "recursion" aren't we? We call everything "function". |
| 2026-01-25 23:42:36 +0100 | <monochrom> | Oh yeah all of us should just say "least fixed point" and be done with it! |
| 2026-01-25 23:42:05 +0100 | <monochrom> | (It had to go through a delay. I also had a "part (b)" in which the students had to show what would go wrong in Haskell if there were no delay.) |
| 2026-01-25 23:41:59 +0100 | <tomsmeding> | monochrom: conversely, functional programmers call everything recursion that we have more precise words for :) |
| 2026-01-25 23:41:08 +0100 | <monochrom> | I once posed a homework question that defined infinite streams of Bool to represent timing diagrams of digital circuits, then had students code up a flip flop using a feedback loop. (One more "plain English" word for recursion!) |
| 2026-01-25 23:38:36 +0100 | <monochrom> | People invent all sorts of "plain/simple English" words to avoid saying "recursion". :) |
| 2026-01-25 23:35:27 +0100 | <geekosaur> | plus most other events scheduled other events for later, since it was a population simulator so it was simulating various life events |
| 2026-01-25 23:34:01 +0100 | <EvanR> | in arrow FRP you wouldn't use recursion but ArrowLoop |
| 2026-01-25 23:34:00 +0100 | takuan | (~takuan@d8D86B9E9.access.telenet.be) (Ping timeout: 244 seconds) |
| 2026-01-25 23:33:49 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2026-01-25 23:33:25 +0100 | <EvanR> | e.g. interpreting recursion doesn't necessarily need anything cyclic |
| 2026-01-25 23:33:08 +0100 | <EvanR> | but whether that counts as some sort of cycle, might depend on your concept of the underlying implementation |
| 2026-01-25 23:33:07 +0100 | <geekosaur> | I wasn't using FRP but a PSQ for a simulation, and one of the events was a status report that triggered every so often in simulated time and rescheduled itself for later |
| 2026-01-25 23:32:35 +0100 | <EvanR> | early versions of FRP exploited recursive definitions (why you might be thinking of as cycles?) to implement some sort of state |
| 2026-01-25 23:31:14 +0100 | <tomsmeding> | as I said, I dunno, maybe this is nonsense :) |
| 2026-01-25 23:31:05 +0100 | <tomsmeding> | the update to the time triggers an update to the time again, after a delay? |
| 2026-01-25 23:30:45 +0100 | <mjacob> | tomsmeding: Where is the cycle in this example? |
| 2026-01-25 23:22:50 +0100 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) (Ping timeout: 245 seconds) |
| 2026-01-25 23:21:16 +0100 | oats | (~oats@user/oats) oats |
| 2026-01-25 23:21:01 +0100 | oats | (~oats@user/oats) (Read error: Connection reset by peer) |
| 2026-01-25 23:15:35 +0100 | <tomsmeding> | a clock? (disclaimer: have never used FRP) |
| 2026-01-25 23:14:00 +0100 | <mjacob> | What are possible applications of cycles in functional reactive programming? I know that many frameworks forbid it unless there is a delay in each cycle. But it is hard to me to think of an example where cycles are useful (with or without delay). |
| 2026-01-25 23:11:28 +0100 | mjacob | (~mjacob@adrastea.uberspace.de) mjacob |
| 2026-01-25 23:07:58 +0100 | <monochrom> | But beware that it is only delivered to the main thread. |
| 2026-01-25 23:07:16 +0100 | <monochrom> | :) |
| 2026-01-25 22:58:30 +0100 | <tomsmeding> | ah no I'm stupid, ignore, it's AsyncException in base |
| 2026-01-25 22:57:57 +0100 | <tomsmeding> | do I really have to reach into ghc-internal to get the UserInterrupt exception, for detecting if someone ^C'd me? |
| 2026-01-25 22:55:30 +0100 | DetourNetworkUK | (DetourNetw@user/DetourNetworkUK) (Ping timeout: 252 seconds) |
| 2026-01-25 22:53:08 +0100 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2026-01-25 22:52:45 +0100 | jmcantrell_ | (~weechat@user/jmcantrell) (Ping timeout: 252 seconds) |
| 2026-01-25 22:42:41 +0100 | pavonia | (~user@user/siracusa) siracusa |
| 2026-01-25 22:41:26 +0100 | oskarw | (~user@user/oskarw) (Remote host closed the connection) |
| 2026-01-25 22:40:50 +0100 | <geekosaur> | in Haskell it's a distinct type, not a distinct value inhabiting every type |
| 2026-01-25 22:40:35 +0100 | <geekosaur> | that's what I meant by "in-band" |
| 2026-01-25 22:39:24 +0100 | <monochrom> | Does the empty object {} exist in JSON? I would be OK with that becoming () in Haskell. But then my idea still implies that parse errors still exist, e.g., parsing "5" to () should be an error. |
| 2026-01-25 22:38:58 +0100 | <[exa]> | the philosophical reason is: in js everything can be null |
| 2026-01-25 22:38:30 +0100 | <[exa]> | oh well look at that https://github.com/haskell/aeson/issues/788#issuecomment-939328524 |
| 2026-01-25 22:37:09 +0100 | <geekosaur> | tbh that actually feels a bit wrong to me, since null is in-band in JSON |
| 2026-01-25 22:36:19 +0100 | <[exa]> | I wanted to nicely match if a value is empty, looked pretty much okay that way |
| 2026-01-25 22:36:04 +0100 | geekosaur | wonders if it's to play a bit more nicely in ghci with ExtendedDefaultRules or something like that |
| 2026-01-25 22:35:41 +0100 | <tomsmeding> | [exa]: let me invert the question: why are you parsing a ()? |
| 2026-01-25 22:35:11 +0100 | <[exa]> | but we've got our cozy haskell null!!! |
| 2026-01-25 22:35:02 +0100 | <[exa]> | yeah well you can do `Null <- ...` |
| 2026-01-25 22:34:30 +0100 | <tomsmeding> | I might actually expect () to parse `null`, because there doesn't seem to be another way to specifically parse `null`? (Apart from parsing a `Value` and requiring it to be `Null`) |
| 2026-01-25 22:32:48 +0100 | tomsmeding | isn't sure, but that sounds like a bad reason |
| 2026-01-25 22:32:27 +0100 | <[exa]> | I guess might be the case because of defaulting, if you write a parser and do `_ <- parseJSON`, it would select () by default |
| 2026-01-25 22:32:03 +0100 | <[exa]> | like, it's somewhat surprising |
| 2026-01-25 22:29:21 +0100 | <[exa]> | not really, there's helpers to avoid that |