Newest at the top
| 2025-05-08 00:02:20 +0200 | <tomsmeding> | sleep well |
| 2025-05-08 00:02:09 +0200 | <tomsmeding> | :p |
| 2025-05-08 00:02:00 +0200 | <hellwolf> | it's too exciting for me, I need to sleep to :D |
| 2025-05-08 00:01:53 +0200 | <hellwolf> | I can talk another time |
| 2025-05-08 00:01:51 +0200 | <hellwolf> | and I developed a technical of using linear types very ergonomically |
| 2025-05-08 00:01:40 +0200 | <hellwolf> | and linear types solvs the sharing completely |
| 2025-05-08 00:01:37 +0200 | <tomsmeding> | right |
| 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:23 +0200 | <hellwolf> | semantics |
| 2025-05-08 00:01:20 +0200 | <hellwolf> | that's incorrect |
| 2025-05-08 00:01:18 +0200 | <hellwolf> | otherwise storage or external messages sent twice |
| 2025-05-08 00:01:10 +0200 | <hellwolf> | there you can't duplicate |
| 2025-05-08 00:01:07 +0200 | <hellwolf> | so, I try to use linear-types only for effectful stuff |
| 2025-05-08 00:00:38 +0200 | <hellwolf> | could be a next step in next version. |
| 2025-05-08 00:00:27 +0200 | <hellwolf> | that's an interesting idea |
| 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: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:02 +0200 | <hellwolf> | 05-08 00:59 <tomsmeding> your users whose program now takes ages, will care |
| 2025-05-07 23:59:30 +0200 | <hellwolf> | so anything that doesn't belong to a category, I call it "special constructor" in my GADT |
| 2025-05-07 23:59:30 +0200 | <hellwolf> | 05-08 00:59 <tomsmeding> special constructor? |
| 2025-05-07 23:59:22 +0200 | <tomsmeding> | your users whose program now takes ages, will care |
| 2025-05-07 23:59:09 +0200 | <hellwolf> | who cares |
| 2025-05-07 23:59:07 +0200 | <hellwolf> | I am a recovering conalist, so sometimes I still say, it's denotationally the same |
| 2025-05-07 23:59:03 +0200 | <tomsmeding> | special constructor? |
| 2025-05-07 23:58:49 +0200 | <hellwolf> | but that's introducing special constructor |
| 2025-05-07 23:58:39 +0200 | <tomsmeding> | accelerate uses stablenames |
| 2025-05-07 23:58:29 +0200 | <hellwolf> | labeling, I thought of it |
| 2025-05-07 23:58:26 +0200 | <hellwolf> | yep |
| 2025-05-07 23:58:21 +0200 | <tomsmeding> | either using `StableName`s, or by generating unique IDs for every created AST node using unsafePerformIO |
| 2025-05-07 23:58:05 +0200 | <hellwolf> | without sharing, either you do a non-linear-type dup (\(x1, x2) -> _ produce a single diagram) |
| 2025-05-07 23:57:58 +0200 | <tomsmeding> | there's another option you haven't mentioned yet: make the implicit haskell-heap-sharing of expressions visible |
| 2025-05-07 23:56:58 +0200 | <tomsmeding> | your expression will be exponentially large |
| 2025-05-07 23:56:53 +0200 | <tomsmeding> | fixing _complete_ lack of sharing using an optimiser is hopeless |
| 2025-05-07 23:56:49 +0200 | <hellwolf> | the fact that I separate purity gives me choice |
| 2025-05-07 23:56:36 +0200 | <hellwolf> | I try to avoid it |
| 2025-05-07 23:56:34 +0200 | <hellwolf> | yes, |
| 2025-05-07 23:56:31 +0200 | <tomsmeding> | but at a big ergonomics cost |
| 2025-05-07 23:56:27 +0200 | <hellwolf> | 2. having explicit diagrams duplication in a helper function, similar to linear type versioned dup'l function, but not using linear types |
| 2025-05-07 23:56:26 +0200 | <tomsmeding> | oh I see, linear types let you avoid the sharing issue indeed |
| 2025-05-07 23:55:58 +0200 | <hellwolf> | it has two solutions: 1. don't care, denotational/conalism, give me an optimizer |
| 2025-05-07 23:55:39 +0200 | <hellwolf> | of diagrams |
| 2025-05-07 23:55:34 +0200 | <hellwolf> | that has duplication |
| 2025-05-07 23:55:24 +0200 | <hellwolf> | varSharing is the version without lineartypes |
| 2025-05-07 23:55:17 +0200 | <hellwolf> | right? |
| 2025-05-07 23:55:15 +0200 | <hellwolf> | because of linear types, you don't share, you explicitly dup |
| 2025-05-07 23:55:01 +0200 | <hellwolf> | varSharingL has a linear-type helped version: it avoids duplication, but sacrifice ergonomics |
| 2025-05-07 23:54:36 +0200 | <hellwolf> | https://github.com/yolc-dev/yul-dsl-monorepo/blob/2b39ca47cb55324cab4eda36c0546ea1fb3d7aca/hs-pkgs… this has "lets" |
| 2025-05-07 23:54:19 +0200 | <hellwolf> | https://github.com/yolc-dev/yul-dsl-monorepo/blob/2b39ca47cb55324cab4eda36c0546ea1fb3d7aca/hs-pkgs… this is an example of native-haskell pattern matching. there is a sharing problem, but I resolved it with exponential object. Not sure I can explain that today. |
| 2025-05-07 23:54:15 +0200 | <EvanR> | let's let the let example loose |
| 2025-05-07 23:53:10 +0200 | <tomsmeding> | sure |