| 2025-05-08 00:00:02 +0200 | <hellwolf> | 05-08 00:59 <tomsmeding> your users whose program now takes ages, will care |
| 2025-05-08 00:00:02 +0200 | <hellwolf> | heh, yea, my domain happens to have small programs; safety is more important there, which I am trying to sell |
| 2025-05-08 00:00:13 +0200 | <tomsmeding> | I'd rather say that every constructor in your GADT gets an additional field: the label |
| 2025-05-08 00:00:27 +0200 | <hellwolf> | that's an interesting idea |
| 2025-05-08 00:00:38 +0200 | <hellwolf> | could be a next step in next version. |
| 2025-05-08 00:01:07 +0200 | <hellwolf> | so, I try to use linear-types only for effectful stuff |
| 2025-05-08 00:01:10 +0200 | <hellwolf> | there you can't duplicate |
| 2025-05-08 00:01:18 +0200 | <hellwolf> | otherwise storage or external messages sent twice |
| 2025-05-08 00:01:20 +0200 | <hellwolf> | that's incorrect |
| 2025-05-08 00:01:23 +0200 | <hellwolf> | semantics |
| 2025-05-08 00:01:25 +0200 | <tomsmeding> | or alternatively, and more neatly, you write your AST as a base functor, and have two "fixpoint combinators" on top of that: the usual one (newtype Fix f = In (f (Fix f))) _after_ sharing recovery, and a labeled one (data Labeled f = Lab Int (f (Labeled f))) before sharing recovery |
| 2025-05-08 00:01:37 +0200 | <tomsmeding> | right |
| 2025-05-08 00:01:40 +0200 | <hellwolf> | and linear types solvs the sharing completely |
| 2025-05-08 00:01:51 +0200 | <hellwolf> | and I developed a technical of using linear types very ergonomically |
| 2025-05-08 00:01:53 +0200 | <hellwolf> | I can talk another time |
| 2025-05-08 00:02:00 +0200 | <hellwolf> | it's too exciting for me, I need to sleep to :D |
| 2025-05-08 00:02:09 +0200 | <tomsmeding> | :p |
| 2025-05-08 00:02:20 +0200 | <tomsmeding> | sleep well |
| 2025-05-08 00:02:34 +0200 | <hellwolf> | | let z = a + b * c in dup'l z & uncurry (*) |
| 2025-05-08 00:02:40 +0200 | <hellwolf> | this is linear-type version of working with pure diagrams |
| 2025-05-08 00:02:46 +0200 | <hellwolf> | | let z = a + b * c in z * z |
| 2025-05-08 00:02:55 +0200 | <hellwolf> | this is the non-linear-type version with diagram duplication |
| 2025-05-08 00:03:19 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 00:03:27 +0200 | <hellwolf> | I can repl codegen and live demo :) |
| 2025-05-08 00:03:36 +0200 | <hellwolf> | that's what I will be working on until the conferenc.e |
| 2025-05-08 00:04:42 +0200 | <hellwolf> | I have Category/Monoidal/Cartesian/Cartesian Closed standard categorical "verbs" |
| 2025-05-08 00:05:39 +0200 | <hellwolf> | special constructors/"verbs" are: MapHask, Switch, Jmp (jump to named function or built-in), Call (external messages), SGet/SPut (storage) |
| 2025-05-08 00:06:12 +0200 | <hellwolf> | I am very judicious of adding special verb, unless I can't find a categorical verb. |
| 2025-05-08 00:06:41 +0200 | <hellwolf> | usually it's particular to the domain, or a special control structure |
| 2025-05-08 00:07:22 +0200 | <hellwolf> | I can't do infinite recursion stuff in this domain, I don't even have heap (I can emulate, but I dont' want to go there), so I need a special verb for tight-loop |
| 2025-05-08 00:07:26 +0200 | <hellwolf> | to implement Foldable. |
| 2025-05-08 00:07:47 +0200 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 252 seconds) |
| 2025-05-08 00:07:54 +0200 | <hellwolf> | so, the tight-loop is the special control flow |
| 2025-05-08 00:08:03 +0200 | <hellwolf> | another one is Switch control flow |
| 2025-05-08 00:08:34 +0200 | <hellwolf> | which I solved the sharing problem there, by having special functions that build the diagram "delicately" |
| 2025-05-08 00:08:44 +0200 | <hellwolf> | with the help of the special verb. |
| 2025-05-08 00:08:52 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-05-08 00:08:54 +0200 | <hellwolf> | but that's the entire language |
| 2025-05-08 00:09:08 +0200 | <hellwolf> | it's not a lambda based language. I still lambda from Haskell. |
| 2025-05-08 00:09:10 +0200 | <hellwolf> | *steal |
| 2025-05-08 00:09:32 +0200 | <hellwolf> | alright, that's all for today :) |
| 2025-05-08 00:10:33 +0200 | <hellwolf> | maybe the final one is the end-to-end example: https://github.com/yolc-dev/yul-dsl-monorepo/blob/master/examples/demo/src/ERC20.hs This is in linear-types, in fact, my special linear-versioned-monad, which is definitely something I haven't seen prior art with my limited search |
| 2025-05-08 00:12:36 +0200 | <hellwolf> | I know it's gonna be exciting for me to keep talking and not shut up. One last thing for labeling: |
| 2025-05-08 00:13:16 +0200 | <hellwolf> | to solves the ergonomics of not having to manually label |
| 2025-05-08 00:13:29 +0200 | <hellwolf> | I have used template haskell to generate unique id |
| 2025-05-08 00:13:39 +0200 | <hellwolf> | based on module name and src loc |
| 2025-05-08 00:13:44 +0200 | <hellwolf> | here: https://github.com/yolc-dev/yul-dsl-monorepo/blob/2b39ca47cb55324cab4eda36c0546ea1fb3d7aca/hs-pkgs… |
| 2025-05-08 00:14:25 +0200 | <hellwolf> | I don't use that for all diagrams, but your suggestion of making labeling part of the GADT type is a good one, I think I will use that eventually. |
| 2025-05-08 00:14:41 +0200 | <hellwolf> | but that might involve too much template haskell dotted everywhere |
| 2025-05-08 00:14:52 +0200 | <hellwolf> | I still care about ergonomics, so I will be still judicious about it. |
| 2025-05-08 00:19:08 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 00:20:13 +0200 | hellwolf | duck. good night. |
| 2025-05-08 00:22:27 +0200 | xff0x | (~xff0x@2405:6580:b080:900:c380:f27a:d8a3:29c7) (Ping timeout: 252 seconds) |
| 2025-05-08 00:23:55 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-05-08 00:24:02 +0200 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-05-08 00:30:24 +0200 | tromp | (~textual@2001:1c00:3487:1b00:d43:3b62:1503:cb84) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-05-08 00:34:56 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 00:38:14 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Read error: Connection reset by peer) |
| 2025-05-08 00:38:45 +0200 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2025-05-08 00:40:00 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2025-05-08 00:41:59 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2025-05-08 00:49:20 +0200 | Frostillicus_1 | (~Frostilli@pool-71-174-119-56.bstnma.fios.verizon.net) |
| 2025-05-08 00:50:42 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 00:53:09 +0200 | acidjnk | (~acidjnk@p200300d6e71c4f51b11b7fbde7c758e1.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2025-05-08 00:55:27 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-05-08 00:56:32 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |
| 2025-05-08 01:04:19 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 01:08:36 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 264 seconds) |
| 2025-05-08 01:08:45 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) chexum |
| 2025-05-08 01:11:16 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-05-08 01:11:16 +0200 | j1n37- | (~j1n37@user/j1n37) (Ping timeout: 276 seconds) |
| 2025-05-08 01:12:32 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-05-08 01:13:01 +0200 | sprotte24 | (~sprotte24@p200300d16f3ca800283c8f0415b7b94b.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2025-05-08 01:13:52 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-05-08 01:14:25 +0200 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-05-08 01:21:43 +0200 | Kaladin | (~Kaladin@157-131-203-96.fiber.dynamic.sonic.net) (Quit: Leaving) |
| 2025-05-08 01:22:20 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 01:26:45 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-05-08 01:28:19 +0200 | shapr | (~user@2600:4040:5c49:5600:cacf:8e54:c9ac:25) (Remote host closed the connection) |
| 2025-05-08 01:30:40 +0200 | Kaladin | (~Kaladin@157-131-203-96.fiber.dynamic.sonic.net) Kaladin |
| 2025-05-08 01:33:49 +0200 | Guest84 | (~Guest84@host-95-237-69-25.retail.telecomitalia.it) |
| 2025-05-08 01:37:42 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 01:42:46 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-05-08 01:45:20 +0200 | Frostillicus_1 | (~Frostilli@pool-71-174-119-56.bstnma.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2025-05-08 01:56:01 +0200 | ystael | (~ystael@user/ystael) (Ping timeout: 248 seconds) |
| 2025-05-08 02:00:57 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2025-05-08 02:04:31 +0200 | jespada | (~jespada@179.26.249.126) (Ping timeout: 244 seconds) |
| 2025-05-08 02:04:33 +0200 | hiredman | (~hiredman@frontier1.downey.family) (Ping timeout: 248 seconds) |
| 2025-05-08 02:07:18 +0200 | hiredman | (~hiredman@frontier1.downey.family) hiredman |
| 2025-05-08 02:09:17 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 02:12:05 +0200 | Guest84 | (~Guest84@host-95-237-69-25.retail.telecomitalia.it) (Quit: Client closed) |
| 2025-05-08 02:12:07 +0200 | Kaladin | (~Kaladin@157-131-203-96.fiber.dynamic.sonic.net) (Quit: Leaving) |
| 2025-05-08 02:14:13 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-05-08 02:20:51 +0200 | Frostillicus_1 | (~Frostilli@pool-71-174-119-56.bstnma.fios.verizon.net) |
| 2025-05-08 02:25:04 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 02:26:25 +0200 | ttybitnik | (~ttybitnik@user/wolper) (Remote host closed the connection) |
| 2025-05-08 02:27:14 +0200 | Axma13761 | (~Axman6@user/axman6) Axman6 |
| 2025-05-08 02:28:47 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org)) |
| 2025-05-08 02:29:33 +0200 | Axman6 | (~Axman6@user/axman6) (Ping timeout: 250 seconds) |
| 2025-05-08 02:30:03 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-05-08 02:30:28 +0200 | tolgo | (~Thunderbi@199.115.144.130) |
| 2025-05-08 02:30:31 +0200 | tolgo | (~Thunderbi@199.115.144.130) (Client Quit) |
| 2025-05-08 02:32:39 +0200 | Natch | (~natch@c-92-34-7-158.bbcust.telenor.se) (Ping timeout: 260 seconds) |
| 2025-05-08 02:35:59 +0200 | Natch | (~natch@c-92-34-7-158.bbcust.telenor.se) Natch |
| 2025-05-08 02:40:53 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 02:46:02 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2025-05-08 02:56:39 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 02:58:19 +0200 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 260 seconds) |
| 2025-05-08 02:58:25 +0200 | Frostillicus_1 | (~Frostilli@pool-71-174-119-56.bstnma.fios.verizon.net) (Ping timeout: 248 seconds) |
| 2025-05-08 03:01:39 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-05-08 03:02:39 +0200 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-05-08 03:09:04 +0200 | haritz | (~hrtz@2a01:4b00:bc2e:7000::2) |
| 2025-05-08 03:10:29 +0200 | sajenim | (~sajenim@user/sajenim) sajenim |
| 2025-05-08 03:10:49 +0200 | haritz | (~hrtz@2a01:4b00:bc2e:7000::2) (Changing host) |
| 2025-05-08 03:10:49 +0200 | haritz | (~hrtz@user/haritz) haritz |
| 2025-05-08 03:12:27 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 03:17:04 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-05-08 03:28:14 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 03:33:07 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-05-08 03:38:15 +0200 | pointlessslippe1 | (~pointless@62.106.85.17) (Read error: Connection reset by peer) |
| 2025-05-08 03:41:41 +0200 | pointlessslippe1 | (~pointless@62.106.85.17) pointlessslippe1 |
| 2025-05-08 03:44:02 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 03:46:01 +0200 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-05-08 03:48:55 +0200 | img | (~img@user/img) img |
| 2025-05-08 03:51:16 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-05-08 04:02:04 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 04:04:37 +0200 | joeyadams | (~textual@syn-162-154-010-038.res.spectrum.com) |
| 2025-05-08 04:06:45 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-05-08 04:15:41 +0200 | tavare | (~tavare@user/tavare) tavare |
| 2025-05-08 04:17:51 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 04:19:57 +0200 | chewybread | (~chewybrea@2601:984:201:3890:b96e:b2c9:c50:1e70) |
| 2025-05-08 04:19:57 +0200 | chewybread | (~chewybrea@2601:984:201:3890:b96e:b2c9:c50:1e70) (Changing host) |
| 2025-05-08 04:19:57 +0200 | chewybread | (~chewybrea@user/chewybread) chewybread |
| 2025-05-08 04:22:01 +0200 | td_ | (~td@i5387091E.versanet.de) (Ping timeout: 252 seconds) |
| 2025-05-08 04:22:38 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-05-08 04:22:48 +0200 | Square | (~Square@user/square) Square |
| 2025-05-08 04:23:00 +0200 | tabaqui | (~tabaqui@167.71.80.236) (Ping timeout: 252 seconds) |
| 2025-05-08 04:23:48 +0200 | td_ | (~td@i53870937.versanet.de) |
| 2025-05-08 04:29:22 +0200 | tavare | (~tavare@user/tavare) (Remote host closed the connection) |
| 2025-05-08 04:33:38 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 04:39:21 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-05-08 04:45:36 +0200 | chewybread | (~chewybrea@user/chewybread) (Remote host closed the connection) |
| 2025-05-08 04:49:26 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 04:54:52 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-05-08 04:58:10 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 05:03:19 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-05-08 05:10:29 +0200 | tabaqui | (~tabaqui@167.71.80.236) tabaqui |
| 2025-05-08 05:12:00 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-05-08 05:13:58 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 05:16:24 +0200 | <monochrom> | No one can steal lambda from Haskell without also stealing purity, laziness, preferring currying, ... |
| 2025-05-08 05:19:19 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2025-05-08 05:21:40 +0200 | tabaqui | (~tabaqui@167.71.80.236) (Ping timeout: 252 seconds) |
| 2025-05-08 05:23:46 +0200 | Frostillicus_1 | (~Frostilli@pool-71-174-119-56.bstnma.fios.verizon.net) |
| 2025-05-08 05:29:45 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 05:34:48 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-05-08 05:44:02 +0200 | aforemny_ | (~aforemny@i59F4C598.versanet.de) aforemny |
| 2025-05-08 05:45:19 +0200 | aforemny | (~aforemny@2001:9e8:6ce9:2000:c495:2bb2:ad61:d989) (Ping timeout: 265 seconds) |
| 2025-05-08 05:45:33 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 05:50:13 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-05-08 06:01:21 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 06:06:20 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-05-08 06:10:25 +0200 | Square | (~Square@user/square) (Ping timeout: 248 seconds) |
| 2025-05-08 06:17:09 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 06:21:49 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-05-08 06:35:19 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 06:37:14 +0200 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-05-08 06:38:28 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 272 seconds) |
| 2025-05-08 06:41:57 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-05-08 06:49:27 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Read error: Connection reset by peer) |
| 2025-05-08 06:52:48 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-08 06:53:19 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 06:54:09 +0200 | Frostillicus_1 | (~Frostilli@pool-71-174-119-56.bstnma.fios.verizon.net) (Ping timeout: 245 seconds) |
| 2025-05-08 07:04:13 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-05-08 07:06:45 +0200 | takuan | (~takuan@d8D86B601.access.telenet.be) |
| 2025-05-08 07:09:39 +0200 | takuan | (~takuan@d8D86B601.access.telenet.be) (Read error: Connection reset by peer) |
| 2025-05-08 07:10:08 +0200 | takuan | (~takuan@d8D86B601.access.telenet.be) |
| 2025-05-08 07:14:42 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 07:19:54 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-05-08 07:27:13 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-05-08 07:27:32 +0200 | califax | (~califax@user/califx) califx |
| 2025-05-08 07:28:13 +0200 | Frostillicus_1 | (~Frostilli@pool-71-174-119-56.bstnma.fios.verizon.net) |
| 2025-05-08 07:30:28 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 07:32:41 +0200 | haritz | (~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2025-05-08 07:35:45 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-05-08 07:46:15 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 07:51:13 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-05-08 07:51:33 +0200 | Frostillicus_1 | (~Frostilli@pool-71-174-119-56.bstnma.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2025-05-08 08:00:10 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 08:05:11 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-05-08 08:08:48 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-05-08 08:10:19 +0200 | j1n37- | (~j1n37@user/j1n37) (Ping timeout: 265 seconds) |
| 2025-05-08 08:15:49 +0200 | internatetional | (~nate@2001:448a:20a3:c2e5:f5f8:a31:7307:70a6) internatetional |
| 2025-05-08 08:15:57 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 08:20:55 +0200 | internatetional | (~nate@2001:448a:20a3:c2e5:f5f8:a31:7307:70a6) (Ping timeout: 276 seconds) |
| 2025-05-08 08:21:34 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-05-08 08:31:20 +0200 | <haskellbridge> | <hellwolf> morning thought to continue... |
| 2025-05-08 08:31:20 +0200 | <haskellbridge> | Using exponential objects (aka. a -> b or b^a) to express the desire explicitly that "a" as an output of an unknown diagram may be used by the exponential object any number of times is the alternative to regular "let" for an embedding language. |
| 2025-05-08 08:31:46 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 08:32:25 +0200 | <haskellbridge> | <hellwolf> It intends to solve the "exponentially growing diagrams" issue, similar to what let var sharing solves. |
| 2025-05-08 08:32:42 +0200 | <haskellbridge> | <hellwolf> The word "exponential" appears twice seems an interesting coincidence. |
| 2025-05-08 08:33:37 +0200 | Frostillicus_1 | (~Frostilli@pool-71-174-119-56.bstnma.fios.verizon.net) |
| 2025-05-08 08:34:17 +0200 | <haskellbridge> | <hellwolf> Furthermore, LinearTypes offers another alternative: force you to express sharing using combinators such as "dup" |
| 2025-05-08 08:34:47 +0200 | joeyadams | (~textual@syn-162-154-010-038.res.spectrum.com) (Quit: Textual IRC Client: www.textualapp.com) |
| 2025-05-08 08:36:12 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-05-08 08:37:07 +0200 | <haskellbridge> | <hellwolf> Furthermore furthermore, I have developed a special "lmonad" for LinearTypes which makes that chore of duplication invisible. In brief, m VarRef, and each time you use the var you get a duplication. |
| 2025-05-08 08:37:15 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-05-08 08:37:31 +0200 | <haskellbridge> | <hellwolf> It's a trade-off again: now, you need to program in a monad |
| 2025-05-08 08:41:20 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Quit: peterbecich) |
| 2025-05-08 08:41:53 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-05-08 08:42:31 +0200 | <haskellbridge> | <hellwolf> further further furthermore, while using monad and LinrarTypes seems to defeat the benefits of using LinrarTypes to express "parallelizable branches", |
| 2025-05-08 08:44:02 +0200 | <haskellbridge> | <hellwolf> by that I mean, thanks to LinearTypes, it's very clear that branches of linear paths can be evaluated in parallel with side effects, since any sharing is explicit with "dup". |
| 2025-05-08 08:45:31 +0200 | acidjnk | (~acidjnk@p200300d6e71c4f49a8c9e3402b4ffa7d.dip0.t-ipconnect.de) acidjnk |
| 2025-05-08 08:46:55 +0200 | <haskellbridge> | <hellwolf> but that benefit can be recouped by versioning the global state, where versioned monad within the same "version" can be evaluated in parallel, but the monad of the next version must wait all those to finish first. |
| 2025-05-08 08:47:33 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-08 08:48:28 +0200 | <haskellbridge> | <hellwolf> this construction may seems ad-hoc, but I think if i try to generalize further, maybe a 2026 endeavour of me..., this is essentially building up to a monadic way of encoding linear-time temporal logic in Haskell. |
| 2025-05-08 08:49:20 +0200 | <haskellbridge> | <hellwolf> linear-versioned monad that I build for yolc is a rather special case of LTL |
| 2025-05-08 08:49:53 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2025-05-08 08:50:58 +0200 | <haskellbridge> | <hellwolf> there is domain-specific benefit to linearly versioning data, namely to financial application security through this programming language safety, but I will skip here. |
| 2025-05-08 08:51:05 +0200 | <haskellbridge> | <hellwolf> alright. fin. |
| 2025-05-08 08:51:28 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 272 seconds) |
| 2025-05-08 08:52:30 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-05-08 08:53:24 +0200 | ft | (~ft@p4fc2a6e6.dip0.t-ipconnect.de) (Quit: leaving) |
| 2025-05-08 08:54:45 +0200 | jmcantrell | (~weechat@user/jmcantrell) (Ping timeout: 248 seconds) |
| 2025-05-08 08:56:57 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-05-08 09:00:03 +0200 | caconym7 | (~caconym@user/caconym) (Quit: bye) |
| 2025-05-08 09:00:45 +0200 | caconym7 | (~caconym@user/caconym) caconym |
| 2025-05-08 09:06:41 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-05-08 09:14:41 +0200 | tromp | (~textual@2001:1c00:3487:1b00:f14f:b20f:416b:87c6) |
| 2025-05-08 09:19:10 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2025-05-08 09:20:36 +0200 | Guest44 | (~Guest44@91-154-214-151.elisa-laajakaista.fi) |
| 2025-05-08 09:29:25 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 248 seconds) |
| 2025-05-08 09:29:28 +0200 | YoungFrog | (~youngfrog@2a02:a03f:c9db:fc00:93c8:3aef:156:8fed) (Ping timeout: 272 seconds) |
| 2025-05-08 09:33:14 +0200 | YoungFrog | (~youngfrog@39.129-180-91.adsl-dyn.isp.belgacom.be) youngfrog |
| 2025-05-08 09:34:42 +0200 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-05-08 09:36:00 +0200 | Frostillicus_1 | (~Frostilli@pool-71-174-119-56.bstnma.fios.verizon.net) (Remote host closed the connection) |
| 2025-05-08 09:43:45 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-05-08 09:44:43 +0200 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-05-08 09:56:37 +0200 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-05-08 09:56:43 +0200 | fp | (~Thunderbi@2001:708:20:1406::10c5) fp |
| 2025-05-08 10:07:33 +0200 | <tomsmeding> | hellwolf: haven't read further in your monologue here, but generating IDs for sharing recovery using template haskell is unsound |
| 2025-05-08 10:07:51 +0200 | <tomsmeding> | the same haskell term at the very same place in the diagram might produce distinct, non-unifiable nodes in the diagram |
| 2025-05-08 10:08:35 +0200 | <tomsmeding> | `let f = \x -> x + x in f a + f b` in haskell |
| 2025-05-08 10:09:05 +0200 | <tomsmeding> | a user can write that, and the resulting yolc diagram, lacking lambda, must have 3 separate (+) nodes, two of which are generated by the exact same (+) operation in the source file |
| 2025-05-08 10:09:49 +0200 | <tomsmeding> | the sharing that you can recover is not _lexical_ identity of the variables in question, but _runtime_ heap pointer identity |
| 2025-05-08 10:09:54 +0200 | <tomsmeding> | or something that approximates the latter |
| 2025-05-08 10:11:18 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2025-05-08 10:12:12 +0200 | <tomsmeding> | hellwolf: "m VarRef and every time you use it you get a duplication" sounds good, but how do you ensure the variable is dropped (as in `consume`) exactly once? Or is the linearity really _only_ for duplication detection and is it fine to duplicate too many times and drop some of the leftovers? |
| 2025-05-08 10:14:15 +0200 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-05-08 10:14:17 +0200 | Guest44 | (~Guest44@91-154-214-151.elisa-laajakaista.fi) (Quit: Client closed) |
| 2025-05-08 10:14:56 +0200 | <hellwolf> | yea, template haskell is unsound. I should read into your approach |
| 2025-05-08 10:15:27 +0200 | <hellwolf> | > but how do you ensure the variable is dropped |
| 2025-05-08 10:15:27 +0200 | <hellwolf> | the monad runner as a "cleanup block" that cleanup the variable references in the end. |
| 2025-05-08 10:15:29 +0200 | <lambdabot> | error: |
| 2025-05-08 10:15:29 +0200 | <lambdabot> | Unexpected do block in function application: |
| 2025-05-08 10:15:29 +0200 | <lambdabot> | do you ensure the variable is dropped |
| 2025-05-08 10:16:09 +0200 | <tomsmeding> | right, so apparently it doesn't matter in your application domain that variables are duplicated more often than strictly necessary? |
| 2025-05-08 10:16:16 +0200 | <tomsmeding> | there's no performance cost associated with duplication? |
| 2025-05-08 10:16:38 +0200 | <hellwolf> | https://github.com/yolc-dev/yul-dsl-monorepo/blob/2b39ca47cb55324cab4eda36c0546ea1fb3d7aca/hs-pkgs… see runYLVM |
| 2025-05-08 10:16:56 +0200 | <hellwolf> | tomsmeding: yep, variable duplication is not a runtime thing! |
| 2025-05-08 10:17:04 +0200 | <tomsmeding> | then this works |
| 2025-05-08 10:17:13 +0200 | <hellwolf> | it's jsut for evaluator (the codegen most importantlh) |
| 2025-05-08 10:17:29 +0200 | <tomsmeding> | then I actually question whether you _need_ linear types for this |
| 2025-05-08 10:17:40 +0200 | <tomsmeding> | it's a technique to make the sharing explicit _in an embedding in haskell_ |
| 2025-05-08 10:18:15 +0200 | <tomsmeding> | but if you'd be writing your own language, with a separate parser and typechecker, then you have an AST of the user-written program immediately, and you can see all sharing because you're the only one who might break it |
| 2025-05-08 10:18:24 +0200 | <tomsmeding> | no need for linear types to make sharing visible |
| 2025-05-08 10:18:41 +0200 | <hellwolf> | yea, linear-type is for "data freshness" |
| 2025-05-08 10:18:50 +0200 | tomsmeding | has no clue what that means |
| 2025-05-08 10:19:05 +0200 | <hellwolf> | yea, it's domain specific. let me see if I can explain |
| 2025-05-08 10:19:21 +0200 | <hellwolf> | so, say, you write such a program: |
| 2025-05-08 10:19:58 +0200 | <hellwolf> | you read the balance of account A -> beforeBalanceA; you invoke some side effects |
| 2025-05-08 10:20:17 +0200 | <hellwolf> | you then do something again, with the assumption that the balance of beforeBalanceA is still valid |
| 2025-05-08 10:20:26 +0200 | <tomsmeding> | that sounds like the versioning, not the linear types |
| 2025-05-08 10:20:29 +0200 | <hellwolf> | in a open financial API system, that creates a vulnerability |
| 2025-05-08 10:20:45 +0200 | <hellwolf> | yea, I use linear types ot create a type safe way to encode that |
| 2025-05-08 10:20:53 +0200 | <hellwolf> | it's a type error if you use dated data |
| 2025-05-08 10:21:12 +0200 | <hellwolf> | there were millions lost due to this kind of bugs. |
| 2025-05-08 10:21:42 +0200 | <hellwolf> | can you enforce it in type safety in other means? |
| 2025-05-08 10:21:54 +0200 | <tomsmeding> | you don't need to shout large numbers to convince me that it's interesting to care about software correctness ;) |
| 2025-05-08 10:21:59 +0200 | <hellwolf> | I am all ears. I am an engineer, so I am here just to assemble solutions. |
| 2025-05-08 10:22:16 +0200 | <hellwolf> | tomsmeding: haha, sorry, it's just sometimes I need to say things to peopel giving money |
| 2025-05-08 10:22:19 +0200 | <hellwolf> | bad habit. |
| 2025-05-08 10:22:22 +0200 | <tomsmeding> | :D |
| 2025-05-08 10:22:40 +0200 | Boarders_____ | (sid425905@id-425905.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-05-08 10:23:39 +0200 | <hellwolf> | but does that program example make sense? |
| 2025-05-08 10:23:50 +0200 | <tomsmeding> | yes it does |
| 2025-05-08 10:23:58 +0200 | tomsmeding | is looking at the LVM definition |
| 2025-05-08 10:24:14 +0200 | <hellwolf> | excuse moi, that's my own sh*t |
| 2025-05-08 10:24:19 +0200 | <hellwolf> | https://github.com/yolc-dev/yul-dsl-monorepo/blob/master/hs-pkgs/yul-dsl-linear-smc/internal/lvm/C… |
| 2025-05-08 10:24:19 +0200 | <hellwolf> | here |
| 2025-05-08 10:24:24 +0200 | <tomsmeding> | yes I found it :) |
| 2025-05-08 10:26:49 +0200 | <tomsmeding> | is it the idea that ctx is at version va, and that a is at version vb? |
| 2025-05-08 10:27:01 +0200 | <tomsmeding> | the input ctx, that is |
| 2025-05-08 10:27:30 +0200 | <hellwolf> | hmm in a way, I guess. a is the output type at version @vb@. |
| 2025-05-08 10:27:49 +0200 | <hellwolf> | not sure I would say ctx having a version, per se. |
| 2025-05-08 10:27:56 +0200 | <tomsmeding> | is there anything at version 'va'? |
| 2025-05-08 10:28:00 +0200 | <hellwolf> | it's more about what you can be bound with |
| 2025-05-08 10:28:41 +0200 | <tomsmeding> | presumably the idea is that pure primitive LVM operations have va=vb, and side-effectful primitive LVM operations have va < vb? |
| 2025-05-08 10:28:46 +0200 | <hellwolf> | (_ :: m ctx va vb a) >>= (_ :: a -> m ctx vb vc b) ? |
| 2025-05-08 10:29:07 +0200 | <hellwolf> | I would not see version independently, it's all about the >>= |