2025/05/07

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 +0200merijn(~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 +0200merijn(~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 +0200sord937(~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