Newest at the top
| 2025-04-01 16:10:28 +0200 | <tomsmeding> | that's what I meant with "implicitly the constructor ..." |
| 2025-04-01 16:10:17 +0200 | <tomsmeding> | yes |
| 2025-04-01 16:10:04 +0200 | <hellwolf> | if (!x1, !x2), should it not imply that the constructor has been also strictly evaluated? |
| 2025-04-01 16:10:00 +0200 | Googulator18 | (~Googulato@2a01-036d-0106-211a-ac5d-24c1-ad5e-7f2b.pool6.digikabel.hu) |
| 2025-04-01 16:09:43 +0200 | Googulator18 | (~Googulato@2a01-036d-0106-211a-ac5d-24c1-ad5e-7f2b.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-04-01 16:09:00 +0200 | <tomsmeding> | `(!x1, !x2)` evaluates the two fields explicitly, and thus also implicitly the constructor from which the two fields are projected |
| 2025-04-01 16:08:36 +0200 | <tomsmeding> | the 2 fields of (,) are lazy, so evaluating a value of type (Int, Int) to WHNF just evaluates the outer (,) constructor, not the contained Ints |
| 2025-04-01 16:08:16 +0200 | <tomsmeding> | the WHNF of a type is _just_ the outermost constructor, plus any strict fields of that constructor |
| 2025-04-01 16:08:13 +0200 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-04-01 16:07:51 +0200 | <tomsmeding> | it does; ! evaluates to WHNF |
| 2025-04-01 16:06:18 +0200 | <hellwolf> | `let !(x1, x2) in _` is different than `let (!x1, !x2) in _`; it doesn't make intuitive sense, or does it to you? |
| 2025-04-01 16:05:56 +0200 | ash3en | (~Thunderbi@149.222.150.125) (Ping timeout: 252 seconds) |
| 2025-04-01 16:05:49 +0200 | <tomsmeding> | the bang-on-constructor-that-has-no-effect is in a pattern match |
| 2025-04-01 16:05:39 +0200 | <tomsmeding> | yes it would, a let is lazy |
| 2025-04-01 16:04:23 +0200 | <EvanR> | so if x is a constructor pattern, the seq wouldn't have any effect |
| 2025-04-01 16:03:40 +0200 | <EvanR> | a special case I found is let !x = e in body ==> let x = e in x `seq` body |
| 2025-04-01 16:02:57 +0200 | comerijn | (~merijn@77.242.116.146) (Ping timeout: 248 seconds) |
| 2025-04-01 16:01:24 +0200 | Leary | (~Leary@user/Leary/x-0910699) (Ping timeout: 268 seconds) |
| 2025-04-01 15:58:33 +0200 | <EvanR> | semantically at least |
| 2025-04-01 15:55:44 +0200 | <EvanR> | hellwolf, bang patterns are syntax sugar for seq |
| 2025-04-01 15:54:16 +0200 | fantom | (~fantom@2.219.56.221) |
| 2025-04-01 15:49:11 +0200 | Digitteknohippie | Digit |
| 2025-04-01 15:48:32 +0200 | rit | (~rit@2409:40e0:101e:42e7:101c:ea47:4905:baf6) |
| 2025-04-01 15:48:24 +0200 | rit | (~rit@2409:40e0:101e:42e7:101c:ea47:4905:baf6) (Remote host closed the connection) |
| 2025-04-01 15:48:24 +0200 | rit | (~rit@2409:40e0:101e:42e7:101c:ea47:4905:baf6) |
| 2025-04-01 15:47:52 +0200 | fantom | (~fantom@2.219.56.221) (Ping timeout: 244 seconds) |
| 2025-04-01 15:43:17 +0200 | acidjnk_new | (~acidjnk@p200300d6e71c4f8289e7d3d4c6144767.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2025-04-01 15:38:28 +0200 | Otong | (~Otong@user/Otong) (Remote host closed the connection) |
| 2025-04-01 15:38:19 +0200 | Otong | (~Otong@user/Otong) Otong |
| 2025-04-01 15:37:40 +0200 | Otong | (~Otong@user/Otong) (Remote host closed the connection) |
| 2025-04-01 15:37:11 +0200 | Otong | (~Otong@user/Otong) Otong |
| 2025-04-01 15:33:01 +0200 | notdabs | (~Owner@2600:1700:69cf:9000:553a:e935:8c4f:3651) |
| 2025-04-01 15:23:43 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 245 seconds) |
| 2025-04-01 15:23:04 +0200 | Digit | (~user@user/digit) (Ping timeout: 272 seconds) |
| 2025-04-01 15:22:22 +0200 | Digitteknohippie | (~user@user/digit) Digit |
| 2025-04-01 15:14:59 +0200 | tromp | (~textual@2001:1c00:3487:1b00:29bc:7fae:9d9f:d545) |
| 2025-04-01 15:13:38 +0200 | fp | (~Thunderbi@2001:708:150:10::1d80) fp |
| 2025-04-01 15:10:05 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 265 seconds) |
| 2025-04-01 15:06:51 +0200 | comerijn | (~merijn@77.242.116.146) merijn |
| 2025-04-01 15:05:28 +0200 | Googulator18 | (~Googulato@2a01-036d-0106-211a-ac5d-24c1-ad5e-7f2b.pool6.digikabel.hu) |
| 2025-04-01 15:05:11 +0200 | Googulator18 | (~Googulato@2a01-036d-0106-211a-ac5d-24c1-ad5e-7f2b.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-04-01 14:59:21 +0200 | <hellwolf> | is there optimization regarding single-constructor data type? |
| 2025-04-01 14:51:27 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2025-04-01 14:50:55 +0200 | zungi | (~tory@user/andrewchawk) andrewchawk |
| 2025-04-01 14:46:24 +0200 | zungi | (~tory@user/andrewchawk) (Ping timeout: 264 seconds) |
| 2025-04-01 14:41:43 +0200 | jespada | (~jespada@2800:a4:2256:6500:9933:8787:b375:7c3e) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2025-04-01 14:36:52 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org)) |
| 2025-04-01 14:34:44 +0200 | <tomsmeding> | (This reasoning doesn't quite hold up for single-constructor data types, but for uniformity and "principle of least surprise" it makes much more sense to extend this principle to single-constructor data types too.) |
| 2025-04-01 14:34:15 +0200 | <tomsmeding> | (in order to know that it is indeed that constructor, the runtime will have to evaluate it down to a constructor anyway. That's why it's strict.) |
| 2025-04-01 14:33:31 +0200 | srk | (~sorki@user/srk) srk |