Logs: freenode/#haskell
| 2020-10-30 10:16:37 | <dminuoso> | Is it a sort of modified case-of? |
| 2020-10-30 10:16:42 | <dminuoso> | a kind of `applicative-case-of`? |
| 2020-10-30 10:17:14 | <dminuoso> | (That seems to be the only way that can make sense) |
| 2020-10-30 10:18:02 | × | cabpa quits (~cabpa@110.54.186.150) (Ping timeout: 264 seconds) |
| 2020-10-30 10:20:23 | <dminuoso> | Such that you could do `let s :: Parser (Either L R); s = ...; in caseS s of Left x -> ...; Right x -> ...; |
| 2020-10-30 10:20:40 | <Uniaika> | dminuoso: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-qualified-do.rst |
| 2020-10-30 10:20:46 | <Uniaika> | it's QualifiedDo! |
| 2020-10-30 10:21:06 | <Uniaika> | and here is the MR https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3436 |
| 2020-10-30 10:21:07 | <dminuoso> | Uniaika: I recall that, but Im not sure whether it could help at all |
| 2020-10-30 10:21:19 | <dminuoso> | Selective requires a case-of version, rather than a do version |
| 2020-10-30 10:21:40 | <dminuoso> | But case-of has no RebindableSyntax to speak of |
| 2020-10-30 10:21:58 | <dminuoso> | Or rather a weird cross between `case of` and `(>>=)` |
| 2020-10-30 10:22:09 | <[exa]> | +1 ^ |
| 2020-10-30 10:22:09 | <dminuoso> | Without guards? |
| 2020-10-30 10:23:05 | <[exa]> | they kindof "made sure this works" with having the Either type in the paper (so that a->b branch "must" be executed) but it would clearly help if the whole patternmatching mechanism was supported |
| 2020-10-30 10:23:23 | <dminuoso> | [exa]: Except you can rig the same type signature with just Applicative |
| 2020-10-30 10:23:30 | <dminuoso> | So the type signature alone is not strong enough |
| 2020-10-30 10:23:41 | ← | thblt parts (~thblt@unaffiliated/thblt) ("ERC (IRC client for Emacs 27.1)") |
| 2020-10-30 10:24:19 | <[exa]> | still kindof thinking how's the select useful in the common case when the decision trees don't really terminate |
| 2020-10-30 10:24:46 | ← | cleveraware parts (~kali@45.133.7.43) () |
| 2020-10-30 10:25:41 | <merijn> | [exa]: The Selective Functor paper is pretty goood :) |
| 2020-10-30 10:25:48 | <[exa]> | yeah reading it now |
| 2020-10-30 10:25:57 | <Uniaika> | yes it's a good read |
| 2020-10-30 10:26:30 | <dminuoso> | Im still hoping parsley will become a thing some day |
| 2020-10-30 10:26:31 | <Uniaika> | as a follow-up and concrete implementation, there is also : https://github.com/kowainik/validation-selective |
| 2020-10-30 10:26:45 | <dminuoso> | https://github.com/J-mie6/ParsleyHaskell |
| 2020-10-30 10:26:52 | <dminuoso> | It's still being developed on |
| 2020-10-30 10:26:57 | → | kuribas joins (~user@ptr-25vy0i7skjncktb6m9t.18120a2.ip6.access.telenet.be) |
| 2020-10-30 10:27:22 | <Uniaika> | hi kuribas :) |
| 2020-10-30 10:27:46 | <[exa]> | dminuoso: is there any read on parsley? |
| 2020-10-30 10:28:02 | → | dyamon joins (~dyamon@cpc69058-oxfd26-2-0-cust662.4-3.cable.virginm.net) |
| 2020-10-30 10:28:04 | <dminuoso> | [exa]: There was a presenstation on Haskell eXchange 2018 |
| 2020-10-30 10:28:17 | <dminuoso> | But I think the skillcasts are not publically available unless you bought a ticket |
| 2020-10-30 10:28:31 | <dminuoso> | (Or was it 2019?) |
| 2020-10-30 10:28:46 | <[exa]> | dminuoso: can you sum it up in like 1 sentence? I can read through the code but you know... :D |
| 2020-10-30 10:29:14 | <dminuoso> | [exa]: So selective is a cross between monad and applicative. You get dynamic choise based on previous results, but static analyzability. |
| 2020-10-30 10:29:25 | <dminuoso> | The idea is to build a parser optimizer in template haskell using that knowledge. |
| 2020-10-30 10:29:43 | <kuribas> | Uniaika: hey :) |
| 2020-10-30 10:29:44 | <dminuoso> | Where TH would probe and dissect your parser, and transform it |
| 2020-10-30 10:30:00 | <[exa]> | dminuoso: ooh okay |
| 2020-10-30 10:30:29 | <[exa]> | I don't like the TH part but it makes sense for sure |
| 2020-10-30 10:31:15 | <dminuoso> | Im not sure whether it still uses TH, but I think the demo used it |
| 2020-10-30 10:32:03 | <dminuoso> | TH at least would avoid some external tooling that you need to glue into the build process |
| 2020-10-30 10:32:47 | <dminuoso> | In a perfect world this would probably be a compiler plugin |
| 2020-10-30 10:33:39 | <[exa]> | like the point with TH is that it's getting back to bison-ish parser processors agaon |
| 2020-10-30 10:34:06 | <[exa]> | *again |
| 2020-10-30 10:34:06 | <dminuoso> | except you get to describe your parser with your beloved parser combinators |
| 2020-10-30 10:34:12 | ← | vilpan parts (~0@212.117.1.172) () |
| 2020-10-30 10:34:24 | <dminuoso> | *and* get the benefits of the parser generator generating a better performing parser |
| 2020-10-30 10:34:34 | <dminuoso> | (or perhaps even detect parser bugs) |
| 2020-10-30 10:35:21 | <[exa]> | shift-reduce conflicts yay! |
| 2020-10-30 10:35:25 | <dminuoso> | external tool I think is very unlikely, because of multiple modules, language extensions, etc.. |
| 2020-10-30 10:35:39 | hackage | modern-uri 0.3.3.0 - Modern library for working with URIs https://hackage.haskell.org/package/modern-uri-0.3.3.0 (mrkkrp) |
| 2020-10-30 10:35:42 | <dminuoso> | so I think TH and compiler plugin are your only options |
| 2020-10-30 10:35:52 | <dminuoso> | Unless you offload the parser combinator into a haskell-like DSL |
| 2020-10-30 10:36:10 | <[exa]> | anyway you still cannot use the old-fashioned patternmatch or if in the parser b/c it wouldn't get caught by Selective, right? |
| 2020-10-30 10:36:21 | <dminuoso> | Sure you can |
| 2020-10-30 10:36:42 | <dminuoso> | selective just wouldnt know about it, and assume both effects can happen |
| 2020-10-30 10:37:05 | [exa] | puzzled now |
| 2020-10-30 10:37:06 | <dminuoso> | superficially it'd just see: |
| 2020-10-30 10:37:17 | <dminuoso> | branch :: Selective f => f (Either a b) -> f (a -> c) -> f (b -> c) -> f c |
| 2020-10-30 10:37:25 | <dminuoso> | branch f g h |
| 2020-10-30 10:37:29 | × | petersen quits (~petersen@redhat/juhp) (Ping timeout: 268 seconds) |
| 2020-10-30 10:37:33 | <[exa]> | oh the ifs are rewritten by TH? |
| 2020-10-30 10:37:34 | <dminuoso> | and know that these three effects can all happen |
| 2020-10-30 10:37:43 | <dminuoso> | no, the structure on selective itself |
| 2020-10-30 10:37:45 | <dminuoso> | think |
| 2020-10-30 10:37:58 | <[exa]> | sorry I'm probably missing something important |
| 2020-10-30 10:37:58 | <dminuoso> | imagine this was written in a Free fashion |
| 2020-10-30 10:38:10 | <dminuoso> | with Monad you couldnt realistically go in and manipulate much |
| 2020-10-30 10:38:11 | × | DirefulSalt quits (DirefulSal@gateway/vpn/privateinternetaccess/direfulsalt) (Read error: Connection reset by peer) |
| 2020-10-30 10:38:15 | <dminuoso> | (even if its a free monad) |
| 2020-10-30 10:38:22 | <dminuoso> | thta is, manipulate without changing the meaning |
| 2020-10-30 10:38:42 | <dminuoso> | the core issue is |
| 2020-10-30 10:38:45 | <dminuoso> | % :t (>>=) |
| 2020-10-30 10:38:45 | <yahb> | dminuoso: Monad m => m a -> (a -> m b) -> m b |
| 2020-10-30 10:38:57 | → | DirefulSalt joins (DirefulSal@gateway/vpn/privateinternetaccess/direfulsalt) |
| 2020-10-30 10:38:59 | <[exa]> | yeah, you can get new effects from "environment" |
| 2020-10-30 10:39:06 | <[exa]> | (with monads) |
| 2020-10-30 10:39:18 | <dminuoso> | Is an optimization barrier. To optimize into >>= it would require GHC to analyze the function itself, leading very quickly to halting problems |
| 2020-10-30 10:39:38 | <dminuoso> | or not just optimization, but introspection |
| 2020-10-30 10:39:49 | <dminuoso> | consider optparse-applicative otoh, which can statically give you informatoin about the parser structure |
| 2020-10-30 10:39:53 | <dminuoso> | it can tell you exactly what flags are possible |
| 2020-10-30 10:40:21 | <[exa]> | yeah that's understood, that is impossible with (Appl|Select)ives |
| 2020-10-30 10:40:25 | <dminuoso> | but optparse applicative does not have the power to say "if you first specify -f, then we accept another flag -g, otherwise we accept -h in additoin" |
| 2020-10-30 10:40:57 | <dminuoso> | selective gives you that power, while allowing the tooling to analyze and tell you `-f/-g/-h` are possible |
| 2020-10-30 10:41:20 | <dminuoso> | so some optparse-selective could give you dynamic choices, while maintaining the analyzability to generate help pages from |
| 2020-10-30 10:41:27 | <dminuoso> | the reason is |
| 2020-10-30 10:41:34 | <[exa]> | oh I get it now sorry |
| 2020-10-30 10:41:39 | <dminuoso> | if it sees `branch f g h`, then it knows all `f, g and h` are possible |
| 2020-10-30 10:42:15 | <dminuoso> | equivalent to how `(,,) <$> f <*> g <*> h` lets you know that all `f, g and h` are possible |
| 2020-10-30 10:42:18 | <[exa]> | the confusion was that I somehow expected that you could have 2 branches of code that are switched by a simple 'if' (outside of selective) but that's impossible b/c you don't have >>= to extract the boolean |
| 2020-10-30 10:42:50 | <dminuoso> | Right, the branching in selective functors is constrained to `select/branch` |
| 2020-10-30 10:43:08 | <dminuoso> | Which is why I said that the equivalent to do-notation would be some version of `case-of` |
| 2020-10-30 10:43:15 | <dminuoso> | So instead of saying |
| 2020-10-30 10:43:26 | <dminuoso> | `branch f (branch g h i) j k` |
| 2020-10-30 10:43:29 | <dminuoso> | you might be able to say |
| 2020-10-30 10:43:44 | <typetetris> | Whats a small server side rendering web framework to look at? |
| 2020-10-30 10:43:57 | <dminuoso> | caseS f of G -> ...; H -> ...; I -> ...; J -> ... |
| 2020-10-30 10:44:03 | <typetetris> | Especially for creating easy links between pages. |
All times are in UTC.