Newest at the top
| 2024-11-19 18:31:11 +0100 | <guy> | and you dont need to supply all or any usually, but can if there is ambiguity |
| 2024-11-19 18:30:52 +0100 | <guy> | the forall is kind of like the list of function arguments, except requiring @ arguments that are types |
| 2024-11-19 18:30:43 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2024-11-19 18:29:58 +0100 | <guy> | let xs = blankVec @Double |
| 2024-11-19 18:29:32 +0100 | <guy> | much worse |
| 2024-11-19 18:29:24 +0100 | <guy> | let xs = blankVec (Proxy :: Proxy Double) |
| 2024-11-19 18:29:02 +0100 | <guy> | blankVec :: Proxy a -> Vec a |
| 2024-11-19 18:29:02 +0100 | <guy> | rather than eg |
| 2024-11-19 18:28:17 +0100 | <guy> | which is anyway implicit |
| 2024-11-19 18:28:04 +0100 | <guy> | blankVec :: forall a. Vec a |
| 2024-11-19 18:27:53 +0100 | son0p | (~ff@2800:e6:4001:6cc3:2748:5c2a:65d9:57ac) (Ping timeout: 245 seconds) |
| 2024-11-19 18:27:35 +0100 | <guy> | blankVec @Double :: Vec Double |
| 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) |