Newest at the top
2025-05-08 10:36:29 +0200 | <hellwolf> | newtype P'x (eff :: PortEffect) r a = MkP'x (P (YulCat LinearEffectX) r a) |
2025-05-08 10:36:29 +0200 | <hellwolf> | -- | Yul port with the port effect kind, aka. yul ports. |
2025-05-08 10:36:25 +0200 | <hellwolf> | type P'V v = P'x (VersionedPort v) |
2025-05-08 10:36:24 +0200 | <hellwolf> | -- | Yul port with linearly versioned data, aka. versioned yul ports. |
2025-05-08 10:36:03 +0200 | <hellwolf> | "P k r a" was the original API |
2025-05-08 10:35:41 +0200 | <hellwolf> | haha, well how else, you do it. P is not my api, P'v is a newtype wrapper where I shove the version into |
2025-05-08 10:35:22 +0200 | <tomsmeding> | "P'v v r a" |
2025-05-08 10:35:16 +0200 | <hellwolf> | :) what I just said, or the code related to P? |
2025-05-08 10:34:37 +0200 | <tomsmeding> | reads like klingon |
2025-05-08 10:34:24 +0200 | <tomsmeding> | sure |
2025-05-08 10:34:14 +0200 | <hellwolf> | e.g. Ur or (), or this type of thing doesn't carry such a version information |
2025-05-08 10:34:04 +0200 | <hellwolf> | not all @a@ has to be |
2025-05-08 10:34:01 +0200 | <hellwolf> | right, to be precise, @a@ has a chance to be versioned at @va@ |
2025-05-08 10:33:39 +0200 | <tomsmeding> | hence me not yet understanding what va is used for |
2025-05-08 10:33:20 +0200 | <tomsmeding> | what I'm naively expecting is that a variable reference has a specific version, and you can only _refer_ to such a variable if its version is equal to the current vb |
2025-05-08 10:33:13 +0200 | <hellwolf> | so all data are versioned |
2025-05-08 10:33:10 +0200 | <hellwolf> | data uses the "port api" from linear-smc library |
2025-05-08 10:32:59 +0200 | <hellwolf> | sput'l :: forall. VersionThread r ⊸ P'V v r a ⊸ P'V v r b ⊸ (VersionThread r, P'V (v + 1) r ()) |
2025-05-08 10:32:53 +0200 | <hellwolf> | https://github.com/yolc-dev/yul-dsl-monorepo/blob/master/hs-pkgs/yul-dsl-linear-smc/src/YulDSL/Has… |
2025-05-08 10:32:44 +0200 | <tomsmeding> | sure |
2025-05-08 10:32:38 +0200 | <hellwolf> | since @a@ has no injectivty to @va@ |
2025-05-08 10:32:30 +0200 | <hellwolf> | let me show you, it's not obvious, if you only look at LVM definitinop |
2025-05-08 10:32:05 +0200 | <tomsmeding> | so I thought I'd look at variables, but I haven't found what I'm looking for yet |
2025-05-08 10:31:52 +0200 | <tomsmeding> | I'm looking for something that shows me how using a non-fresh reference will result in a type error |
2025-05-08 10:31:24 +0200 | <hellwolf> | okay, thanks, I will fix |
2025-05-08 10:31:10 +0200 | <tomsmeding> | LVMVar.hs |
2025-05-08 10:31:05 +0200 | <hellwolf> | where did you see that? |
2025-05-08 10:30:39 +0200 | <tomsmeding> | or perhaps "referrable" |
2025-05-08 10:30:27 +0200 | <tomsmeding> | (it's spelled "referentiable", not "referenciable") |
2025-05-08 10:29:29 +0200 | <hellwolf> | corect |
2025-05-08 10:29:29 +0200 | <hellwolf> | 05-08 11:28 <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:29:07 +0200 | <hellwolf> | I would not see version independently, it's all about the >>= |
2025-05-08 10:28:46 +0200 | <hellwolf> | (_ :: m ctx va vb a) >>= (_ :: a -> m ctx vb vc b) ? |
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:00 +0200 | <hellwolf> | it's more about what you can be bound with |
2025-05-08 10:27:56 +0200 | <tomsmeding> | is there anything at version 'va'? |
2025-05-08 10:27:49 +0200 | <hellwolf> | not sure I would say ctx having a version, per se. |
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:01 +0200 | <tomsmeding> | the input ctx, that is |
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:24:24 +0200 | <tomsmeding> | yes I found it :) |
2025-05-08 10:24:19 +0200 | <hellwolf> | here |
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:14 +0200 | <hellwolf> | excuse moi, that's my own sh*t |
2025-05-08 10:23:58 +0200 | tomsmeding | is looking at the LVM definition |
2025-05-08 10:23:50 +0200 | <tomsmeding> | yes it does |
2025-05-08 10:23:39 +0200 | <hellwolf> | but does that program example make sense? |
2025-05-08 10:22:40 +0200 | Boarders_____ | (sid425905@id-425905.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
2025-05-08 10:22:22 +0200 | <tomsmeding> | :D |
2025-05-08 10:22:19 +0200 | <hellwolf> | bad habit. |