Newest at the top
| 2024-11-19 18:46:03 +0100 | <guy> | might help with these matching issues |
| 2024-11-19 18:45:57 +0100 | <guy> | writing; data DBEntry where DBEntry :: SiteVariant -> BS.ByteString -> DBEntry |
| 2024-11-19 18:45:38 +0100 | <geekosaur> | ardell: tbh stack is still easier to start with, but as your extra-deps start to grow cabal will become easier to work with. if you can stick to the snapshot then stack will be easier |
| 2024-11-19 18:44:26 +0100 | <guy> | (DBEntry siteVariant html) |
| 2024-11-19 18:43:57 +0100 | <guy> | DBEntry {..} = case siteVariant |
| 2024-11-19 18:43:56 +0100 | <guy> | its all valid in terms of proxies. but you have an error matching here; |
| 2024-11-19 18:43:22 +0100 | <guy> | then the B case should work, if you also supply an instance for that class |
| 2024-11-19 18:42:27 +0100 | <guy> | also your instance should not replace the type with a new type, that should be a comment, and it should not be incorrect accotrding to the class |
| 2024-11-19 18:40:56 +0100 | <guy> | A -> fromHTML (Proxy @SiteA) html |
| 2024-11-19 18:39:14 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection) |
| 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 |