Newest at the top
| 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. |
| 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:21:59 +0200 | <hellwolf> | I am all ears. I am an engineer, so I am here just to assemble solutions. |
| 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:42 +0200 | <hellwolf> | can you enforce it in type safety in other means? |
| 2025-05-08 10:21:12 +0200 | <hellwolf> | there were millions lost due to this kind of bugs. |
| 2025-05-08 10:20:53 +0200 | <hellwolf> | it's a type error if you use dated data |
| 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:29 +0200 | <hellwolf> | in a open financial API system, that creates a vulnerability |
| 2025-05-08 10:20:26 +0200 | <tomsmeding> | that sounds like the versioning, not the linear types |
| 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:19:58 +0200 | <hellwolf> | you read the balance of account A -> beforeBalanceA; you invoke some side effects |
| 2025-05-08 10:19:21 +0200 | <hellwolf> | so, say, you write such a program: |
| 2025-05-08 10:19:05 +0200 | <hellwolf> | yea, it's domain specific. let me see if I can explain |
| 2025-05-08 10:18:50 +0200 | tomsmeding | has no clue what that means |
| 2025-05-08 10:18:41 +0200 | <hellwolf> | yea, linear-type is for "data freshness" |
| 2025-05-08 10:18:24 +0200 | <tomsmeding> | no need for linear types to make sharing visible |
| 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:17:40 +0200 | <tomsmeding> | it's a technique to make the sharing explicit _in an embedding in haskell_ |
| 2025-05-08 10:17:29 +0200 | <tomsmeding> | then I actually question whether you _need_ linear types for this |
| 2025-05-08 10:17:13 +0200 | <hellwolf> | it's jsut for evaluator (the codegen most importantlh) |
| 2025-05-08 10:17:04 +0200 | <tomsmeding> | then this works |
| 2025-05-08 10:16:56 +0200 | <hellwolf> | tomsmeding: yep, variable duplication is not a runtime thing! |
| 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:16 +0200 | <tomsmeding> | there's no performance cost associated with duplication? |
| 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:15:29 +0200 | <lambdabot> | do you ensure the variable is dropped |
| 2025-05-08 10:15:29 +0200 | <lambdabot> | Unexpected do block in function application: |
| 2025-05-08 10:15:29 +0200 | <lambdabot> | error: |
| 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:27 +0200 | <hellwolf> | > but how do you ensure the variable is dropped |
| 2025-05-08 10:14:56 +0200 | <hellwolf> | yea, template haskell is unsound. I should read into your approach |
| 2025-05-08 10:14:17 +0200 | Guest44 | (~Guest44@91-154-214-151.elisa-laajakaista.fi) (Quit: Client closed) |
| 2025-05-08 10:14:15 +0200 | __monty__ | (~toonn@user/toonn) toonn |
| 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:11:18 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2025-05-08 10:09:54 +0200 | <tomsmeding> | or something that approximates the latter |
| 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: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:08:35 +0200 | <tomsmeding> | `let f = \x -> x + x in f a + f b` in haskell |
| 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 |