Logs: freenode/#haskell
| 2020-11-01 12:41:15 | <__monty__> | That's kinda the certified software poster boy, no? |
| 2020-11-01 12:41:33 | <__monty__> | Yeah, Carmack mostly talks about haskell iirc. |
| 2020-11-01 12:42:42 | <florian_> | monty : I start to do implementation of Boolean, Natural numbers, List, Binary Tree, Tree, Custom types: and i'm like .. "OOoo ! it can be really awesome for my day to day work" |
| 2020-11-01 12:43:28 | × | jespada quits (~jespada@90.254.243.98) (Quit: Sleeping) |
| 2020-11-01 12:44:50 | <merijn> | maerwald, ski: FWIW, Tim Sweeney (of Epic Games) gave a keynote at POPL about his expectations for the "next big language in games" |
| 2020-11-01 12:45:01 | <merijn> | Lemme see if I can find the slides |
| 2020-11-01 12:45:24 | <__monty__> | merijn: Already linked by ski ^ |
| 2020-11-01 12:45:28 | <ski> | merijn : another than the one i linked to, above ? |
| 2020-11-01 12:45:55 | <merijn> | oh, hah, that was just off screen |
| 2020-11-01 12:46:03 | ski | . o O ( <https://en.wikipedia.org/wiki/ATS_(programming_language)> ) |
| 2020-11-01 12:46:50 | → | texasmynsted joins (~texasmyns@212.102.45.115) |
| 2020-11-01 12:47:27 | <florian_> | monty : thanks a lot for the TLA+ reference ! |
| 2020-11-01 12:49:06 | <florian_> | ski : thank for the ATS ref ! you give me so much interesting sources |
| 2020-11-01 12:49:58 | <ski> | (i haven't really looked much at ATS. but it seemed possibly relevant, in the discussion) |
| 2020-11-01 12:51:06 | → | renzhi joins (~renzhi@2607:fa49:655f:e600::28da) |
| 2020-11-01 12:54:27 | → | atraii_ joins (~atraii@c-98-32-64-84.hsd1.ut.comcast.net) |
| 2020-11-01 12:54:47 | × | sam___ quits (~sam@4.196.204.77.rev.sfr.net) (Ping timeout: 260 seconds) |
| 2020-11-01 12:55:16 | × | atraii quits (~atraii@c-98-32-64-84.hsd1.ut.comcast.net) (Ping timeout: 246 seconds) |
| 2020-11-01 12:55:16 | atraii_ | is now known as atraii |
| 2020-11-01 12:55:51 | <maerwald> | merijn: pretty odd that he makes an argument for lazy evaluation while this will be his biggest problem when doing actual gamedev in haskell |
| 2020-11-01 12:56:08 | <merijn> | maerwald: Well, he's not arguing for lazy in the last slides |
| 2020-11-01 12:56:21 | → | sam___ joins (~sam@212.105.23.93.rev.sfr.net) |
| 2020-11-01 12:56:40 | <merijn> | maerwald: His point is that "complicatedly juggling initialisation order of global state is a mess" due to eager evaluation |
| 2020-11-01 12:56:44 | <maerwald> | my suspicion is that he has only looked at the language and the syntax and is trying to borrow nice ideas, rather than having actually used it |
| 2020-11-01 12:56:55 | <maerwald> | (which is good) |
| 2020-11-01 12:57:35 | <merijn> | maerwald: did you read the 2nd to last slide(s) on "Why haskell is not my favourite"? |
| 2020-11-01 12:57:36 | <int-e> | The next Haskell will be strict? :) |
| 2020-11-01 12:57:44 | <merijn> | int-e: I hope not |
| 2020-11-01 12:57:45 | <maerwald> | merijn: I'm half-way through |
| 2020-11-01 12:57:51 | <maerwald> | int-e: I hope so |
| 2020-11-01 12:57:57 | <merijn> | maerwald: Ah, he addresses that literally at the end :) |
| 2020-11-01 12:58:11 | <merijn> | int-e: I would hope "strictness polymorphic" that sounds much more interesting |
| 2020-11-01 12:58:41 | <maerwald> | and linear types and dependent types so only a handful of ppl around the world can code it |
| 2020-11-01 12:58:42 | <int-e> | if it means what I think it means it sounds like a recipe for exponential code explosion |
| 2020-11-01 12:59:30 | <int-e> | And don't get me wrong, I love laziness. But it is rather expensive. |
| 2020-11-01 13:00:15 | <int-e> | And it's not always possible to make up for that with more clever algorithms that would be really awkward to implement without laziness. |
| 2020-11-01 13:00:22 | <maerwald> | my idea of the perfect language is this: let some academics come up with the most fantastic featureful stuff and then let a community of pramatic programmers cut down feature by feature until they're satisfied. No feature is allowed to be added, ever :) |
| 2020-11-01 13:01:14 | <merijn> | maerwald: tbh, I'm not sold on dependent types |
| 2020-11-01 13:01:34 | <int-e> | maerwald: Force the academic to implement FFI. Implement everything you need in C++. ;-) |
| 2020-11-01 13:02:09 | <merijn> | maerwald: But strictness polymorphic would be nice, like, why do we need foldMap and foldMap' instead of a single foldMap that can be instantiated strict or lazy as needed dependent on whether you give it a strict or lazy function |
| 2020-11-01 13:02:28 | <maerwald> | merijn: I'd much rather have a Lazy type |
| 2020-11-01 13:02:57 | <maerwald> | I don't think it'll be easy to reason about programs when they're strictness polymorphic |
| 2020-11-01 13:03:00 | <ski> | like in OCaml,SML,Scheme ? |
| 2020-11-01 13:03:00 | <int-e> | I feel unqualified to muse about dependent type. I struggle to think of a compelling use for them that scales beyond toy examples... I imagine it'll require a *very* moderate use of dependent types, or a genius software engineer who gets them just right for a particular domain. Possibly both. |
| 2020-11-01 13:03:43 | <int-e> | I imagine it's very easy to use dependent type to code yourself into a corner where you're constantly fighting the types you created. |
| 2020-11-01 13:04:12 | <int-e> | But... yeah sadly that's all speculation. |
| 2020-11-01 13:04:29 | <maerwald> | int-e: that's fine... I don't care how other ppl shoot themselves in the foot. The problem is when I have to use libraries that do that weird stuff. And that will inevitably happe |
| 2020-11-01 13:04:37 | <int-e> | I'd really love to see some experience reports. |
| 2020-11-01 13:04:53 | ski | . o O ( "Ornamental Algebras, Algebraic Ornaments" by Conor McBride in 2010-08-09 at <http://personal.cis.strath.ac.uk/~conor/pub/OAAO/Ornament.pdf> ) |
| 2020-11-01 13:04:56 | <int-e> | Maybe it works well for specific domains like compilers at least? That's quite conceivable. |
| 2020-11-01 13:05:04 | → | knupfer1 joins (~Thunderbi@200116b82ca86a0099682528f6996d5a.dip.versatel-1u1.de) |
| 2020-11-01 13:05:21 | → | domj joins (~domj@77.139.218.14) |
| 2020-11-01 13:05:49 | → | nschoe joins (~quassel@2a01:e0a:3c4:c7b0:c059:9ac8:a690:3133) |
| 2020-11-01 13:06:05 | <int-e> | maerwald: Oh yes, the ecosystem will become far more fragmented than it already is. |
| 2020-11-01 13:06:10 | × | texasmynsted quits (~texasmyns@212.102.45.115) (Remote host closed the connection) |
| 2020-11-01 13:06:29 | → | texasmynsted joins (~texasmyns@212.102.45.115) |
| 2020-11-01 13:07:10 | × | knupfer quits (~Thunderbi@200116b82ca86a000577b9dd59dd39a4.dip.versatel-1u1.de) (Ping timeout: 268 seconds) |
| 2020-11-01 13:07:10 | knupfer1 | is now known as knupfer |
| 2020-11-01 13:07:46 | <int-e> | The beauty of the ML type system is that if you can capture a property in those types, it's almost always worth it (though you can go overboard with newtypes, I think). It doesn't require much discipline to benefit from. |
| 2020-11-01 13:08:19 | × | ahmr88 quits (~ahmr88@cpc85006-haye22-2-0-cust131.17-4.cable.virginm.net) (Remote host closed the connection) |
| 2020-11-01 13:08:33 | <maerwald> | To me, types aren't worth to encode logic into. I only want to encode my data in it. |
| 2020-11-01 13:08:49 | <int-e> | Hmm. I should say HM (Hindley-Milner). And a couple of Haskell's extensions have that property as well, notably GADTs. |
| 2020-11-01 13:09:11 | → | urodna joins (~urodna@unaffiliated/urodna) |
| 2020-11-01 13:09:32 | <__monty__> | int-e: Or, Damas-Hindley-Milner : ) |
| 2020-11-01 13:10:59 | Lord_of_Life_ | is now known as Lord_of_Life |
| 2020-11-01 13:11:34 | → | akad_ joins (~akad@109107030050.radomsko.vectranet.pl) |
| 2020-11-01 13:11:42 | × | sam___ quits (~sam@212.105.23.93.rev.sfr.net) (Read error: No route to host) |
| 2020-11-01 13:12:06 | int-e | goes look at ski's link |
| 2020-11-01 13:13:04 | → | nbloomf joins (~nbloomf@2600:1700:ad14:3020:c427:c5ca:d62:565b) |
| 2020-11-01 13:14:29 | <juri_> | ski: o/ |
| 2020-11-01 13:15:48 | × | alp quits (~alp@2a01:e0a:58b:4920:89f1:ba96:ddf:92c2) (Ping timeout: 268 seconds) |
| 2020-11-01 13:17:15 | → | sam___ joins (~sam@212.105.23.93.rev.sfr.net) |
| 2020-11-01 13:17:23 | → | notnatebtw joins (~nate@125.161.131.30) |
| 2020-11-01 13:17:38 | → | livvy joins (~livvy@gateway/tor-sasl/livvy) |
| 2020-11-01 13:20:05 | <maerwald> | I don't really understand when he talks about parallelism, effects free and Monads |
| 2020-11-01 13:20:06 | <ski> | hello juri_ |
| 2020-11-01 13:20:08 | <maerwald> | merijn: ^ |
| 2020-11-01 13:20:39 | <merijn> | maerwald: Ah, you'd like a position paper I wrote a few years ago :) |
| 2020-11-01 13:21:14 | <merijn> | maerwald: Where I argue a bunch of these Haskell effects libraries are doing it wrong by stuffing everything in the "functional" (in the sense of functional vs non-functional requirements) type |
| 2020-11-01 13:21:18 | <maerwald> | seems like a misunderstanding about what purity is, looking at the slide |
| 2020-11-01 13:21:38 | <merijn> | maerwald: What I want is multiple orthogonal/independent type systems |
| 2020-11-01 13:21:41 | <int-e> | ski: Hmm, weird. |
| 2020-11-01 13:21:51 | <ski> | which ? |
| 2020-11-01 13:21:53 | <maerwald> | merijn: like Java exceptions |
| 2020-11-01 13:21:57 | <int-e> | ski: the ornaments |
| 2020-11-01 13:22:02 | <merijn> | maerwald: So the fact that the result of "div" throws and the fact that "div" returns "Int" are separate |
| 2020-11-01 13:22:24 | <maerwald> | I agree |
| 2020-11-01 13:22:27 | → | pfurla joins (~pfurla@ool-182ed2e2.dyn.optonline.net) |
| 2020-11-01 13:22:29 | <merijn> | maerwald: Similarly, I don't want the strictness polymorphism in my "foldMap :: Monoid m => (a -> m) -> [a] -> m" type |
| 2020-11-01 13:22:45 | <merijn> | I want a *completely separate* type that indicates the strictness of arguments |
| 2020-11-01 13:23:12 | <ski> | int-e : the explicit representation thing he does is fiddly/awkward. but having a way to express such relationships, and possibly derive ornamented types in such a way, seems like it could be useful |
| 2020-11-01 13:23:25 | <merijn> | maerwald: And then for things like "strictness polymorphism" or "throwing exceptions" you can leave the inferred default 95% of the time. But explicitly write a "this doesn't throw signature" when needed and get a type error if it doesn't match |
| 2020-11-01 13:23:33 | <int-e> | ski: yeah but the whole paper is on a level I fail to care about |
| 2020-11-01 13:24:08 | <maerwald> | merijn: I think that's basically how the borrow checker in rust works. It "communicates" with the type system, but it's not completely wired in, afaik |
| 2020-11-01 13:24:09 | <merijn> | maerwald: So you can annotate when you explicitly need something strict/lazy or well "exception polymorphic" (I suppose), but still have the power of annotating your meaning when desirable |
| 2020-11-01 13:24:57 | → | ahmr88 joins (~ahmr88@cpc85006-haye22-2-0-cust131.17-4.cable.virginm.net) |
| 2020-11-01 13:25:06 | × | ahmr88 quits (~ahmr88@cpc85006-haye22-2-0-cust131.17-4.cable.virginm.net) (Remote host closed the connection) |
| 2020-11-01 13:25:11 | <int-e> | ski: well, that's unfair. the abstract and introduction are okay. :P |
| 2020-11-01 13:25:15 | <ski> | int-e : yea. it would be nice with a more practical take on it |
| 2020-11-01 13:25:31 | hackage | ormolu 0.1.3.1 - A formatter for Haskell source code https://hackage.haskell.org/package/ormolu-0.1.3.1 (mrkkrp) |
All times are in UTC.