Newest at the top
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 |
2025-05-07 23:53:02 +0200 | <hellwolf> | ah, okay, perhaps let's just leave it here and talk about it another day. I will just show you the "let" example |
2025-05-07 23:52:46 +0200 | <tomsmeding> | it's 23:52 over here |
2025-05-07 23:52:40 +0200 | <tomsmeding> | I'm interested, but not now :') |
2025-05-07 23:52:31 +0200 | <hellwolf> | but bear with me... I haven't had write up, so I am now typing from scratch |
2025-05-07 23:52:21 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
2025-05-07 23:52:17 +0200 | <hellwolf> | I will get there, there is technique to avoid that; and the lineartype provided scenario is even more interesting to talk about. |
2025-05-07 23:51:50 +0200 | <tomsmeding> | assuming you care about that :) |
2025-05-07 23:51:41 +0200 | <tomsmeding> | an duplication is usually bad for performance |
2025-05-07 23:51:30 +0200 | <hellwolf> | let me show you an example. |
2025-05-07 23:51:14 +0200 | <tomsmeding> | can't represent that diagram without let-binding |
2025-05-07 23:51:05 +0200 | <hellwolf> | And since they are "pure", if such duplication actually happens, it's fine, it's referential transparent. |
2025-05-07 23:51:04 +0200 | <tomsmeding> | but what if I want `let z = x + y in z + z`? |
2025-05-07 23:50:28 +0200 | <hellwolf> | For pure morphisms, everything is just a "diagram". And since I don't implement lambda, there is no "Let" constructor. if you do x + x, diagrams "x" got duplicated and their outputs are sent to (+) morphism. |
2025-05-07 23:49:11 +0200 | <hellwolf> | First of all, all functions (a morphism in the category) in yolc has a "eff" tag, which classifies into either pure, and non-pure. Just like Haskell's IO or the lack of IO as tag. |
2025-05-07 23:47:39 +0200 | <hellwolf> | yea, that's right. There are two scenarios in my case. |
2025-05-07 23:47:33 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-05-07 23:46:27 +0200 | <tomsmeding> | (IMO sharing is the big design choice when designing an embedded language in haskell) |
2025-05-07 23:46:06 +0200 | <tomsmeding> | i.e. do you have a let-binding construct in your embedded language, and if so, how do you expose that to the user |
2025-05-07 23:45:39 +0200 | <tomsmeding> | how would you have the user represent sharing in their embedded program? |
2025-05-07 23:45:12 +0200 | <tomsmeding> | embedding is much easier :D |
2025-05-07 23:45:03 +0200 | <tomsmeding> | I might be able to finish it if I spend more time on it |
2025-05-07 23:44:56 +0200 | <hellwolf> | I am not versed in to actually building those. Using embedding approach is more because of my limitation. |
2025-05-07 23:44:30 +0200 | <tomsmeding> | at some point I tried to implement a haskell typechecker (well, a very small subset of haskell), without reference to literature because it's more fun that way, and I got stuck at properly handling inference of polymorphic functions |
2025-05-07 23:44:29 +0200 | <hellwolf> | oh, yea, I think I read some of Arnauld's paper. Linear-types rules seems very concise. |
2025-05-07 23:44:20 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
2025-05-07 23:44:06 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
2025-05-07 23:43:36 +0200 | <tomsmeding> | *daunted |