Newest at the top
| 2024-10-07 22:23:48 +0200 | <EvanR> | like a damn math book, they define stuff seemingly out of blue before getting to the point |
| 2024-10-07 22:23:28 +0200 | <EvanR> | where the definitions are in order |
| 2024-10-07 22:23:08 +0200 | <EvanR> | I'm finding where clause to be awkward sometimes. Unless it's a wild mess of definitions that must be necessarily out of order, or there's no logical order of presentation, I've been liking block of let bindings ending with an in |
| 2024-10-07 22:21:32 +0200 | euleritian | (~euleritia@dynamic-176-006-132-124.176.6.pool.telefonica.de) |
| 2024-10-07 22:21:08 +0200 | euleritian | (~euleritia@dynamic-176-006-132-124.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-10-07 22:21:04 +0200 | euleritian | (~euleritia@dynamic-176-006-132-124.176.6.pool.telefonica.de) |
| 2024-10-07 22:20:49 +0200 | euleritian | (~euleritia@dynamic-176-006-132-124.176.6.pool.telefonica.de) (Remote host closed the connection) |
| 2024-10-07 22:18:18 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) athan |
| 2024-10-07 22:17:56 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2024-10-07 22:12:51 +0200 | <yin> | c_wraith: just syntactical convenience |
| 2024-10-07 22:11:22 +0200 | <yin> | ty |
| 2024-10-07 22:10:28 +0200 | euleritian | (~euleritia@dynamic-176-006-132-124.176.6.pool.telefonica.de) |
| 2024-10-07 22:09:56 +0200 | euleritian | (~euleritia@ip5f5ad3f6.dynamic.kabel-deutschland.de) (Ping timeout: 272 seconds) |
| 2024-10-07 22:09:34 +0200 | <monochrom> | Look for the paper "the next 700 languages" |
| 2024-10-07 22:09:21 +0200 | <yin> | i don't know who Landin is |
| 2024-10-07 22:08:52 +0200 | <monochrom> | err, I don't even think you can't! |
| 2024-10-07 22:08:39 +0200 | <monochrom> | I don't even think you can design your language to accept "let x = 0:y in x where y = 1:x" haha |
| 2024-10-07 22:07:48 +0200 | <monochrom> | Haskell's "let x=e in b" certainly becomes Landin's "b where x=e". |
| 2024-10-07 22:07:43 +0200 | <c_wraith> | if you're going to just specify the behavior as "perform all these bindings, make these names in scope", how is it any different from just putting them in the do block? |
| 2024-10-07 22:07:19 +0200 | <monochrom> | I think you could do it in your language. |
| 2024-10-07 22:07:04 +0200 | <EvanR> | it attaches to definitions and case alternatives |
| 2024-10-07 22:06:50 +0200 | <EvanR> | thing |
| 2024-10-07 22:06:45 +0200 | <EvanR> | where clause isn't an expression by itself, is another |
| 2024-10-07 22:06:30 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-10-07 22:06:18 +0200 | ljdarj1 | ljdarj |
| 2024-10-07 22:05:58 +0200 | <yin> | i understand the current constraints. i guess what i'm asking is if there would be something stopping us from doing it if we wanted to? c_wraith asks a good question, but i think we could get around that if we just considered sugar for implicitly passing the bound variable as an argument |
| 2024-10-07 22:05:41 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 255 seconds) |
| 2024-10-07 22:04:56 +0200 | <monochrom> | haha |
| 2024-10-07 22:04:51 +0200 | <EvanR> | </clippy> |
| 2024-10-07 22:04:40 +0200 | <EvanR> | maybe you want to use a recursive do |
| 2024-10-07 22:04:39 +0200 | <monochrom> | To be sure, Landin would have (actually did) "where" belonging to an expression, so meh, it's a personal taste, you can design a language to look whatever you like. |
| 2024-10-07 22:04:01 +0200 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-10-07 22:02:25 +0200 | <monochrom> | "f x = y+1 where y = x" the "where" belongs to "f x =", not to "y+1". "case xs of x:xt -> y+1 where y = x" the "where" belongs to "x:xt ->", not to "y+1". |
| 2024-10-07 22:02:16 +0200 | <int-e> | (after desugaring, the x is not in scope outside of that lambda) |
| 2024-10-07 22:01:15 +0200 | <lambdabot> | a >>= \ x -> b |
| 2024-10-07 22:01:15 +0200 | <int-e> | @undo do x <- a; b |
| 2024-10-07 22:01:14 +0200 | <c_wraith> | well, it introduces the obvious question of *when* they would be bound. Usually names defined in a where block are evaluated on demand. That would be ugly for <- bindings |
| 2024-10-07 22:00:49 +0200 | <monochrom> | It is because do-block is an expression but "where" is for definitions and pattern matching, so do-block is neither. |
| 2024-10-07 22:00:48 +0200 | <int-e> | yin: yes, they're not in scope outside of the do block (they're only in scope for any subsequent statements inside the do block) |
| 2024-10-07 21:59:29 +0200 | <ncf> | huh? |
| 2024-10-07 21:59:26 +0200 | <yin> | s/can't/wouldn't be able to |
| 2024-10-07 21:58:58 +0200 | <yin> | is there any logical reason why we can't use bound variables (with `<-` in do blocks) inside where clauses? |
| 2024-10-07 21:58:39 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 252 seconds) |
| 2024-10-07 21:56:53 +0200 | floyza | (~gavin@h69-11-148-150.kndrid.broadband.dynamic.tds.net) gdown |
| 2024-10-07 21:53:18 +0200 | weary-traveler | (~user@user/user363627) user363627 |
| 2024-10-07 21:48:23 +0200 | EvanR | (~EvanR@user/evanr) EvanR |
| 2024-10-07 21:48:02 +0200 | mari-estel | (~mari-este@185.238.219.66) (Ping timeout: 252 seconds) |
| 2024-10-07 21:42:43 +0200 | mantraofpie | (~mantraofp@user/mantraofpie) mantraofpie |
| 2024-10-07 21:42:20 +0200 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-10-07 21:42:01 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Remote host closed the connection) |