Newest at the top
| 2024-11-19 18:38:18 +0100 | <guy> | ghcup still going strong |
| 2024-11-19 18:38:08 +0100 | <guy> | cabal ftw |
| 2024-11-19 18:37:54 +0100 | <bwe> | btw. does anyone has hlint working within helix editor with or without using hls? |
| 2024-11-19 18:37:27 +0100 | <geekosaur> | also these days stack hooks into ghcup, which generally works better than stack's own ghc management |
| 2024-11-19 18:37:24 +0100 | <bwe> | guy & Leary: I've put together some minimum example: https://paste.tomsmeding.com/MrYnuSCc |
| 2024-11-19 18:34:25 +0100 | f-a | (ff2a@joined.irc.for-some.fun) () |
| 2024-11-19 18:34:14 +0100 | <haskellbridge> | <maerwald> hls works better with cabal |
| 2024-11-19 18:33:21 +0100 | <ardell> | If I may throw in an unrelated question: I'd like to write something small in Haskell. What's the current recommendation for initial setup? ghcup and cabal? Or is stack still recommended? |
| 2024-11-19 18:33:12 +0100 | <guy> | did anyone have any thoughts on a stateful language? |
| 2024-11-19 18:33:02 +0100 | <guy> | .... |
| 2024-11-19 18:31:50 +0100 | <guy> | but normally you write the forall so the ambiguous types come first |
| 2024-11-19 18:31:36 +0100 | <guy> | there is a wildcard @_ to avoid having to supply preceeding types |
| 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 |