Newest at the top
| 2024-11-19 18:26:51 +0100 | <guy> | Leary, seems to be talking about returning Proxies from a "varient", and suggests the Variant datatype contains the disambiguating type annotation, itself as a proxy. dont do this, instead use the TypeApplication as the syntax for the disambiguating argument |
| 2024-11-19 18:24:39 +0100 | <guy> | i dont think its iffy at all. @args are just as valid as regular args and the user can branch on choices easily like this |
| 2024-11-19 18:23:26 +0100 | <guy> | so its a datatype that makes use of the `a' annotation internally |
| 2024-11-19 18:23:15 +0100 | <Leary> | bwe: I don't know about that, but producing proxies from a variant is always going to be iffy in a standalone function. Making the variant the proxy itself is my recommendation. |
| 2024-11-19 18:22:40 +0100 | <bwe> | guy: no, HasFoo is not my proxy |
| 2024-11-19 18:21:37 +0100 | <guy> | but that said, so should your proxy remove the need for the existential quantifier, since it brings it into scope via an input argument |
| 2024-11-19 18:21:04 +0100 | <guy> | that machinery i think makes proxies essentially redundant |
| 2024-11-19 18:20:41 +0100 | <guy> | and it *is* ambiguous, so you just use that extension |
| 2024-11-19 18:20:20 +0100 | <guy> | this is basically why TypeApplications was introduced, it saves having to use the proxy as an input argument, when the polymorphic variable appears in the return type |
| 2024-11-19 18:19:28 +0100 | <guy> | because if thats the case it can be ommited, but then `a' only appears in the rhs, so it requires the forall and AmbiguousTypes |
| 2024-11-19 18:18:44 +0100 | <guy> | is HasFoo your proxy? |
| 2024-11-19 18:18:16 +0100 | <guy> | you need to pass the proxy, or the equivalent typeApplication in that case |
| 2024-11-19 18:18:01 +0100 | mvk | (~mvk@2607:fea8:5c96:5800::2d42) (Client Quit) |
| 2024-11-19 18:17:55 +0100 | <guy> | but only as long as it doesnt just appear in a return type |
| 2024-11-19 18:17:40 +0100 | <guy> | like if it were in a class that had `a' in its header, then you wouldnt need to resolve `a' via a forall |
| 2024-11-19 18:17:06 +0100 | mvk | (~mvk@2607:fea8:5c96:5800::2d42) mvk |
| 2024-11-19 18:16:50 +0100 | <guy> | HasFoo should stop it being ambiguous if its on the lhs of the *> *depending on what that is* |
| 2024-11-19 18:16:11 +0100 | mari-estel | (~mari-este@user/mari-estel) (Remote host closed the connection) |
| 2024-11-19 18:16:07 +0100 | <bwe> | Leary: ok, so there's no way getting around type level data constructor? |
| 2024-11-19 18:16:02 +0100 | <guy> | whats *> btw? |
| 2024-11-19 18:15:16 +0100 | <guy> | idk if you need to put it in a continuations like that |
| 2024-11-19 18:14:57 +0100 | <Leary> | bwe: It's existential regardless, because you don't know statically which type you're producing. You could write `withFoo :: Variant -> (forall a. HasFoo a => a -> r) -> r`. |
| 2024-11-19 18:14:52 +0100 | <guy> | yeah you need a forall a. if your going to use typeApplications it requires RankNTypes |
| 2024-11-19 18:12:55 +0100 | <bwe> | Leary: could I do it without Proxy like `genProxy :: Variant -> HasFoo a *> a` ? Does the Proxy require existential quantifier? |
| 2024-11-19 18:11:48 +0100 | ardell | (~ardell@user/ardell) ardell |
| 2024-11-19 18:08:21 +0100 | <guy> | im hoping it can be a good idea for a project in linear types, since the state data is always replaced |
| 2024-11-19 18:07:43 +0100 | <guy> | again, this is something that can be implemented in haskell, and im wondering what the switch to "stateful by default" at a syntax level, would mean for a language |
| 2024-11-19 18:06:49 +0100 | <guy> | (functions come with actual value associated) |
| 2024-11-19 18:06:36 +0100 | <guy> | such that this `s' data would be handled automatically |
| 2024-11-19 18:06:08 +0100 | <guy> | and all functions therefore needing to be passed as instantiated objects |
| 2024-11-19 18:05:42 +0100 | <guy> | the idea is to make the last argument in a series of partial applications `s' and have the return type as (s,output) |
| 2024-11-19 18:05:02 +0100 | <guy> | i know that basically haskell can handle stateful computations, so i wonder what the difference would be |
| 2024-11-19 18:04:46 +0100 | SlackCoder | (~SlackCode@64-94-63-8.ip.weststar.net.ky) SlackCoder |
| 2024-11-19 18:04:44 +0100 | <guy> | hi! I am wondering what a "stateful functional programing language" would be like as compared to haskell |
| 2024-11-19 18:04:27 +0100 | guy | (~guy@2a01:4b00:d007:ed00:3c30:fab:460b:9474) |
| 2024-11-19 18:01:07 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-19 17:58:24 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) |
| 2024-11-19 17:58:02 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-11-19 17:57:08 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-11-19 17:50:02 +0100 | droshux | (~droshux@147.188.245.217) () |
| 2024-11-19 17:48:10 +0100 | ski | (~ski@remote11.chalmers.se) ski |
| 2024-11-19 17:46:52 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-11-19 17:45:01 +0100 | <droshux> | Hi!Q |
| 2024-11-19 17:44:54 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) |
| 2024-11-19 17:44:51 +0100 | <droshux> | Tbh I haven't really paid attention to it, maybe I should next time. |
| 2024-11-19 17:44:33 +0100 | mari-estel | (~mari-este@user/mari-estel) (Ping timeout: 245 seconds) |
| 2024-11-19 17:44:07 +0100 | <zzz> | i find it amazing that a ls can take as much memory as a web browser |
| 2024-11-19 17:43:32 +0100 | <droshux> | I've not found it too bad but I've not been using a system with super limited memory |
| 2024-11-19 17:43:10 +0100 | <zzz> | hls is such a memory hog... |
| 2024-11-19 17:39:02 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Quit: leaving) |