Logs: liberachat/#haskell
| 2021-06-28 08:41:44 | <tomsmeding> | Arahael: if the type 'a' didn't occur in the type signature of the function, then it wouldn't be callable |
| 2021-06-28 08:41:48 | <Profpatsch> | Can we please have Applicative constructor syntax |
| 2021-06-28 08:42:12 | <Arahael> | tomsmeding: Aha, so they really wanted some sort of proxy. |
| 2021-06-28 08:42:14 | <Profpatsch> | Foo { field1 <- fieldA, field2 <- fieldB } |
| 2021-06-28 08:42:24 | <tomsmeding> | Arahael: that's what it also sounds like to me |
| 2021-06-28 08:42:37 | × | Feuermagier_ quits (~Feuermagi@213.178.26.41) (Read error: Connection reset by peer) |
| 2021-06-28 08:42:37 | <tomsmeding> | Profpatsch: Foo <$> fieldA <*> fieldB ? |
| 2021-06-28 08:42:43 | <Arahael> | tomsmeding: Maybe they just happened to be using it in a monad context and thought "Hey, a Monad m will do!" |
| 2021-06-28 08:42:47 | → | Feuermagier joins (~Feuermagi@user/feuermagier) |
| 2021-06-28 08:43:05 | <tomsmeding> | probably, hence int-e's interpretation as a historic accident :) |
| 2021-06-28 08:43:11 | <Arahael> | Makes sense. :) |
| 2021-06-28 08:43:42 | <Profpatsch> | tomsmeding: that’s a non-feature, because position dependence |
| 2021-06-28 08:43:54 | → | samhh joins (~samhh@90.252.127.54) |
| 2021-06-28 08:44:12 | <tomsmeding> | non-feature is too strong a word (it's very very useful in a lot of places), but indeed that doesn't cover position-independent construciton |
| 2021-06-28 08:44:23 | × | boxscape_ quits (~boxscape_@p4ff0b158.dip0.t-ipconnect.de) (Quit: Connection closed) |
| 2021-06-28 08:44:26 | <merijn> | Profpatsch: Eh, ApplicativeDo exists? :p |
| 2021-06-28 08:44:27 | <tomsmeding> | Profpatsch: you might check out the ApplicativeDo extension |
| 2021-06-28 08:44:27 | <Profpatsch> | I’m using applicativeDo combined with NamedFieldPuns, but A) it’s verbose and B) it’s too easy to accidentally get monadic |
| 2021-06-28 08:44:35 | tomsmeding | high-5's merijn |
| 2021-06-28 08:44:50 | <merijn> | Profpatsch: Yeah, I don't really like ApplicativeDo for that reason |
| 2021-06-28 08:45:00 | <merijn> | SHE, maybe? |
| 2021-06-28 08:45:06 | <merijn> | That has proper idiom brackets, no? |
| 2021-06-28 08:45:21 | <Profpatsch> | In that case, it will give a nice error message cause I’m using Validation from validation-selective and Kowainik has a Monad instance with a nice “Validation doesn’t support Monads” error |
| 2021-06-28 08:46:57 | → | Lycurgus joins (~juan@cpe-45-46-140-49.buffalo.res.rr.com) |
| 2021-06-28 08:47:23 | <Profpatsch> | I mean I’m probably missing some GHC parser cons here, but { field <- fieldA } looks like the obvious syntax to me that should just work |
| 2021-06-28 08:47:53 | → | chomwitt joins (~Pitsikoko@athedsl-16082.home.otenet.gr) |
| 2021-06-28 08:47:54 | × | fef quits (~thedawn@user/thedawn) (Ping timeout: 244 seconds) |
| 2021-06-28 08:48:46 | × | chris_ quits (~chris@81.96.113.213) (Remote host closed the connection) |
| 2021-06-28 08:48:47 | <merijn> | I don't agree, tbh |
| 2021-06-28 08:49:08 | <merijn> | That only looks obvious if you handwave all the very crucial details of "wtf is that even supposed to mean?" |
| 2021-06-28 08:49:21 | <Profpatsch> | syntactic sugar for |
| 2021-06-28 08:49:37 | <Profpatsch> | field <- fieldA >>= \field -> Foo { field } |
| 2021-06-28 08:49:47 | <merijn> | Right, but then it's monadic |
| 2021-06-28 08:49:54 | <merijn> | And you wanted Applicative |
| 2021-06-28 08:49:56 | <Profpatsch> | ah blab |
| 2021-06-28 08:49:59 | <Profpatsch> | yes |
| 2021-06-28 08:50:12 | <Profpatsch> | however applicativeDo generates it |
| 2021-06-28 08:50:23 | → | delYsid joins (~user@user/delYsid) |
| 2021-06-28 08:50:27 | <merijn> | "dark heuristic voodoo" |
| 2021-06-28 08:50:32 | <merijn> | Which is bad |
| 2021-06-28 08:50:36 | <Profpatsch> | With the Monad part disabled |
| 2021-06-28 08:50:41 | <Profpatsch> | Just the applicative part |
| 2021-06-28 08:50:43 | <merijn> | And really has no place in a proper compiler, imo |
| 2021-06-28 08:50:52 | <Profpatsch> | I tend to agree |
| 2021-06-28 08:51:18 | <Profpatsch> | heuristics like that in a compiler are kind of horrifying when it might degrade from parallel to linear without notice |
| 2021-06-28 08:51:19 | × | eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:7930:a54c:f178:5c1a) (Remote host closed the connection) |
| 2021-06-28 08:51:36 | <Profpatsch> | I mean you can do it |
| 2021-06-28 08:51:49 | <Profpatsch> | deriving newtype (Applicative) -- no Monad |
| 2021-06-28 08:51:50 | → | eggplantade joins (~Eggplanta@2600:1700:bef1:5e10:48c3:15b7:84fd:d26e) |
| 2021-06-28 08:52:09 | <Profpatsch> | And then use your wrapped type instead |
| 2021-06-28 08:52:26 | <Profpatsch> | But applicative do should at least have introduced ado or something |
| 2021-06-28 08:52:57 | <Profpatsch> | Purescript did it right |
| 2021-06-28 08:53:14 | → | dhil joins (~dhil@195.213.192.47) |
| 2021-06-28 08:53:25 | × | alex3 quits (~alex3@BSN-77-82-41.static.siol.net) (Ping timeout: 244 seconds) |
| 2021-06-28 08:54:17 | × | chomwitt quits (~Pitsikoko@athedsl-16082.home.otenet.gr) (Ping timeout: 268 seconds) |
| 2021-06-28 08:54:23 | nshepperd | . o O (ado x <- foo; y <- bar in f x y) |
| 2021-06-28 08:54:47 | <Hecate> | ado . ken |
| 2021-06-28 08:55:07 | → | boxscape_ joins (~boxscape_@p4ff0b158.dip0.t-ipconnect.de) |
| 2021-06-28 08:55:15 | × | boxscape_ quits (~boxscape_@p4ff0b158.dip0.t-ipconnect.de) (Client Quit) |
| 2021-06-28 08:56:15 | × | eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:48c3:15b7:84fd:d26e) (Ping timeout: 250 seconds) |
| 2021-06-28 09:00:07 | <tomsmeding> | Profpatsch: (\a b c d e f -> Foo e a f b d c) <$> fieldE <*> fieldA <*> fieldF <*> fieldB <*> fieldD <*> fieldC |
| 2021-06-28 09:00:43 | <tomsmeding> | merijn: if the syntax would support exactly only <- arrows, then this would be a perfectly unambiguous desugaring |
| 2021-06-28 09:01:18 | <tomsmeding> | but at that point it's literally syntactic sugar, which I guess could still be nice |
| 2021-06-28 09:01:39 | × | hnOsmium0001 quits (uid453710@id-453710.stonehaven.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-06-28 09:01:44 | → | alex3 joins (~alex3@BSN-77-82-41.static.siol.net) |
| 2021-06-28 09:01:45 | → | boxscape_ joins (~boxscape_@p4ff0b158.dip0.t-ipconnect.de) |
| 2021-06-28 09:02:03 | <merijn> | tbh, I'm not a big fan of cramming new stuff into Haskell's existing syntax. I'd rather see a number of bigger syntax changes turned into a coherent new grammar and see someone implement a new GHC front-end for this new "non-Haskell" language |
| 2021-06-28 09:02:10 | → | lavaman joins (~lavaman@98.38.249.169) |
| 2021-06-28 09:02:24 | <Profpatsch> | ptyhon3 but even worse |
| 2021-06-28 09:02:27 | <merijn> | This insistence of programmers to keep adding new syntax to languages that weren't designed with it in mind is toxic |
| 2021-06-28 09:02:43 | <merijn> | Profpatsch: Repeatedly adding stuff into new languages just converges to the clusterfuck that is C++ |
| 2021-06-28 09:02:50 | <merijn> | And Haskell is already headed there |
| 2021-06-28 09:03:05 | <tomsmeding> | in some senses it's already surpassed c++ :p |
| 2021-06-28 09:03:20 | <merijn> | tomsmeding: I disagree, C++ is *really* bad |
| 2021-06-28 09:03:23 | × | tzh quits (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz) |
| 2021-06-28 09:03:27 | <merijn> | Much, much worse than most people think |
| 2021-06-28 09:04:07 | <Profpatsch> | merijn: well, most syntax additions are sugar and can be trivially transformed back |
| 2021-06-28 09:04:09 | <tomsmeding> | -XTransformListComp |
| 2021-06-28 09:05:01 | <merijn> | tomsmeding: See, that one doesn't even really count, because the language was designed with monadic comprehensions and only *later* did they restrict them to lists |
| 2021-06-28 09:05:01 | <Profpatsch> | The surface language should be easy for the human to write |
| 2021-06-28 09:05:16 | <merijn> | Profpatsch: The surface language should be easy for the human to *read* |
| 2021-06-28 09:05:19 | <delYsid> | Profpatsch: Java, then? :-) |
| 2021-06-28 09:05:22 | <tomsmeding> | merijn: not talking about -XMonadComprehensions :p |
| 2021-06-28 09:05:24 | <merijn> | Which means it should be relatively consistent |
| 2021-06-28 09:05:25 | <Profpatsch> | (In favor of removing list comprehensions) |
| 2021-06-28 09:05:29 | × | boxscape_ quits (~boxscape_@p4ff0b158.dip0.t-ipconnect.de) (Changing host) |
| 2021-06-28 09:05:29 | → | boxscape_ joins (~boxscape_@user/boxscape) |
| 2021-06-28 09:05:31 | <merijn> | tomsmeding: Yeah, but that's just a generalisation |
| 2021-06-28 09:05:31 | <tomsmeding> | this is the sql-like oddness |
| 2021-06-28 09:06:29 | <merijn> | 50 different special case syntaxes for specific cases doesn't make it easier to write stuff |
| 2021-06-28 09:06:32 | <merijn> | Just look a YAML |
| 2021-06-28 09:06:45 | <merijn> | It has a billion special cases to "be easy for the human to write" |
| 2021-06-28 09:06:56 | <merijn> | With the end result that no sane person even understands what anything means |
| 2021-06-28 09:07:00 | × | lavaman quits (~lavaman@98.38.249.169) (Ping timeout: 272 seconds) |
| 2021-06-28 09:07:05 | <Profpatsch> | <*> and <$> are not syntactic but still an antipattern |
| 2021-06-28 09:07:17 | <tomsmeding> | it's hard, though; if you keep adding special cases to an existing language you end up with c++; if you split languages you get python3; if you do nothing you get... what, exactly? |
| 2021-06-28 09:07:25 | <merijn> | Profpatsch: Disagree, those are just functions |
| 2021-06-28 09:07:26 | <Profpatsch> | Takes hours to learn how they stick together, errors suck, and they aren’t even position-independent |
| 2021-06-28 09:07:47 | <Profpatsch> | merijn: yes, but constructor ordering is plain wrong |
| 2021-06-28 09:07:51 | <Profpatsch> | relying on it |
All times are in UTC.