Logs: freenode/#haskell
| 2020-10-06 12:17:23 | <ski> | quazimod1 : iirc that ^ has an example of the modularity (with separating generating a search-tree for games, from traversing (and pruning) it) |
| 2020-10-06 12:19:11 | <ski> | quazimod1 : "it being a drop in option that 'just works'" -- i don't think that's the case. i think that for many modules/libraries, turning on `Strict' (or even just `StrictData', depending), will make them not work |
| 2020-10-06 12:19:31 | <quazimod1> | yeah that makes more sense |
| 2020-10-06 12:19:32 | → | __skn joins (~sunil@sec.nimmagadda.net) |
| 2020-10-06 12:20:10 | <dminuoso> | quazimod1: Note that there's limits to lazyness being useful though. Just being able to use lazyness doesn't make all occurences of it useful. |
| 2020-10-06 12:20:12 | <ski> | (if you turn it on, when you're compiling them, that is) |
| 2020-10-06 12:20:20 | <maerwald> | ski: I enabled Strict and StrictData for large projects and nothing happened :) |
| 2020-10-06 12:20:20 | <dminuoso> | For instance, lazy bytestrings are very debatable. They are very non-composable. |
| 2020-10-06 12:20:44 | <maerwald> | Strict is only problematic when you write monadic combinators |
| 2020-10-06 12:20:58 | → | st8less joins (~st8less@2603:a060:11fd:0:101c:4882:6a23:1c57) |
| 2020-10-06 12:21:28 | <quazimod1> | yeah i'm too dumb to understand |
| 2020-10-06 12:21:29 | <ski> | i think `Strict' (and `StrictData') are more useful for when you know you'll be working "in a strict way", where you won't really be helped much by non-strictness anyway. and possibly also for converting some preexisting code/library that mostly satisfy those constraints |
| 2020-10-06 12:21:55 | × | st8less quits (~st8less@2603:a060:11fd:0:101c:4882:6a23:1c57) (Client Quit) |
| 2020-10-06 12:21:58 | <dminuoso> | If I look back, ever since I started writing Haskell, I haven't been bitten by a space leak yet, but have had numerous occasions where lazyness let me write code far more modular, and more expressive. |
| 2020-10-06 12:22:06 | <dminuoso> | It's even small things like being able to write `zip [1..]` |
| 2020-10-06 12:22:08 | → | heatsink joins (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) |
| 2020-10-06 12:22:16 | <ski> | maerwald : yea, i'm not saying you'll get bottom directly :) but some things may be way less efficient than one's expecting. it obviously depends on the style of the code, what kind of things it's doing |
| 2020-10-06 12:22:28 | <maerwald> | ski: kazu yamamoto seems to disagree with you https://github.com/yesodweb/wai/pull/752#issuecomment-501531386 |
| 2020-10-06 12:23:52 | <quazimod1> | even though i'm dumb it feells to me like selective laziness is better than always lazy |
| 2020-10-06 12:24:00 | <maerwald> | I agree |
| 2020-10-06 12:25:25 | <ski> | maerwald : interesting :) perhaps the kind of things they's doing (or the way they tend to do them) more easily lends itself to strict semantics then. and perhaps that being the case is a bit more common than one'd thing |
| 2020-10-06 12:26:32 | × | jespada quits (~jespada@90.254.246.48) (Ping timeout: 260 seconds) |
| 2020-10-06 12:26:43 | <ski> | yea, i think having a reasonable way to get both worlds, would be good. but it's hard to know how to mix them, being able to succinctly and clearly choose which you want, when, not clear how to design such a language |
| 2020-10-06 12:26:52 | × | heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 256 seconds) |
| 2020-10-06 12:27:02 | <quazimod1> | doesn't the strict mode do that |
| 2020-10-06 12:27:09 | <dminuoso> | quazimod1: It's debatable at the end. The thing with lazyness, is that its value doesn't kick in until you actually have lazyness by default. |
| 2020-10-06 12:27:10 | <quazimod1> | give you the ability to whitelist lazy |
| 2020-10-06 12:28:02 | → | jespada joins (~jespada@90.254.246.48) |
| 2020-10-06 12:28:50 | <quazimod1> | this may again be more dumb thinking but i get the strong impression that commercial decision makers will avoid laziness |
| 2020-10-06 12:29:27 | <dminuoso> | quazimod1: The best summary is that adding a selective strictness annotation always works, but selective lazyness annotations dont. |
| 2020-10-06 12:29:40 | <ski> | quazimod1 : "doesn't the strict mode do that" -- no, because it turns it on for the whole module |
| 2020-10-06 12:29:42 | <dminuoso> | Lazyness needs to be pervasive to work |
| 2020-10-06 12:29:50 | <ski> | yea, that too |
| 2020-10-06 12:30:10 | <maerwald> | There are some arguments pro composition and compiler optimisations due to non-strict semantics, but in the end: lazyness is a poor streaming method, which is why we go away from lazy bytestring and lazy IO and towards actual streaming libraries, that guarantee proper streaming. Otherwise there's too much cleverness in your code you don't understand yourself |
| 2020-10-06 12:30:28 | <dminuoso> | Lazyness is not just for streaming. |
| 2020-10-06 12:30:34 | <Habib> | can someone help me out w/ understanding prettyprinter? |
| 2020-10-06 12:30:34 | <maerwald> | I didn't say that |
| 2020-10-06 12:30:46 | <dminuoso> | Habib: Just ask! |
| 2020-10-06 12:30:52 | <ski> | what i had in mind was to have a fine-grained selection of strictness and non-strictness. possibly, in some way, reflected in the types (but how to do that, in a not too obtrusive and code-duplicating way, isn't clear) |
| 2020-10-06 12:31:01 | × | cosimone quits (~cosimone@2001:b07:ae5:db26:b248:7aff:feea:34b6) (Read error: Connection reset by peer) |
| 2020-10-06 12:31:21 | <ski> | i'd like to experiment with a language with call-by-coneed :) |
| 2020-10-06 12:31:34 | → | cosimone joins (~cosimone@2001:b07:ae5:db26:b248:7aff:feea:34b6) |
| 2020-10-06 12:31:35 | <maerwald> | ski: http://docs.idris-lang.org/en/latest/tutorial/typesfuns.html#laziness |
| 2020-10-06 12:32:23 | → | Habib_ joins (~Habib@185.134.23.120) |
| 2020-10-06 12:32:25 | <quazimod1> | I've done a lot of stream programming in javascript |
| 2020-10-06 12:32:35 | <Habib_> | is prettyprinter really a prettyprinter, or is it just a prettyprinting engine? |
| 2020-10-06 12:32:44 | <dminuoso> | quazimod1: So the realization that selective/surgical annotations only work with strictness annotations makes it obvious, that StrictData needs *far* more work if you want to use lazyness at all, as opposed to default with some strictness. |
| 2020-10-06 12:32:46 | <quazimod1> | i dont know how comfy i'd be with implicit streaming vs actual streaming constructs |
| 2020-10-06 12:32:50 | <dminuoso> | Habib_: Yes. |
| 2020-10-06 12:32:56 | <dminuoso> | Habib_: What's the difference? |
| 2020-10-06 12:33:28 | <maerwald> | dminuoso: there aren't many instances where you don't want StrictData |
| 2020-10-06 12:33:37 | <quazimod1> | dminuoso: so the Strict and StrictData options appear to allow optional laziness using ~, so you'd have 'lazy modules' littered with ~ in a strict by default apporach, is what you're saying? |
| 2020-10-06 12:33:43 | <dminuoso> | maerwald: I dont think that's true. I've had very few places where I needed a bang. |
| 2020-10-06 12:33:51 | <dminuoso> | *far* less instances where I *wanted* lazyness |
| 2020-10-06 12:34:06 | <Habib_> | pretty-simple just prints data types in a nicely formatted way so i can see largely nested values, but prettyprinter seems to be more of a bunch of primitives to let me control everything in a very precise way, but no way to just… print something. |
| 2020-10-06 12:34:07 | <quazimod1> | to be fair i think the vast majority of the time you don't really care which way |
| 2020-10-06 12:34:11 | <maerwald> | You need it very quickly if you store a lot of data in memory |
| 2020-10-06 12:34:28 | <quazimod1> | still, it appears to me that having optional & deliberate laziness makes more sense |
| 2020-10-06 12:34:35 | × | akegalj quits (~akegalj@93-138-123-17.adsl.net.t-com.hr) (Ping timeout: 240 seconds) |
| 2020-10-06 12:34:36 | <quazimod1> | dumb dumb opinions |
| 2020-10-06 12:34:44 | <ski> | maerwald : yea, having explicit suspensions (that `Lazy'), is good to have in a strict language, but are a bit awkward to use (also really needs to be combined with something like <https://srfi.schemers.org/srfi-45/srfi-45.html>. also see <http://homepages.inf.ed.ac.uk/wadler/topics/language-design.html#lazyinstrict>). there's the pervasiveness argument that dminuoso mentioned |
| 2020-10-06 12:35:00 | <Habib_> | dminuoso: i don't get how anyone is supposed to be able to use prettyprinter in the console for just looking at values without getting lost |
| 2020-10-06 12:35:05 | × | Habib quits (~Habib@194.35.233.138) (Ping timeout: 240 seconds) |
| 2020-10-06 12:35:05 | Habib_ | is now known as Habib |
| 2020-10-06 12:35:15 | <maerwald> | quazimod1: also: laziness is harder to reason about. And ppl get it wrong all the time. It's just less intuitive and some of the rules aren't that obvious |
| 2020-10-06 12:35:17 | → | shatriff joins (~vitaliish@217.27.153.240) |
| 2020-10-06 12:35:23 | <dminuoso> | Habib: prettyprinter is not for "just looking at values" |
| 2020-10-06 12:35:27 | <dminuoso> | It's for generating pretty output. |
| 2020-10-06 12:35:33 | <quazimod1> | i guess the other question that I have is, what happens when you have zero laziness... don't you just solve the same problems slightly differently |
| 2020-10-06 12:35:37 | <Habib> | yeah, this is what i mean by pretty printer vs. pretty printing engine |
| 2020-10-06 12:35:39 | <dminuoso> | Think of generating error/warning messages for your prorgram. |
| 2020-10-06 12:35:43 | <ski> | maerwald : "Otherwise there's too much cleverness in your code you don't understand yourself" -- i agree that this is not that good, yea. (but it's not just streams) |
| 2020-10-06 12:35:48 | <Habib> | a pretty printer prints… prettily |
| 2020-10-06 12:36:00 | <quazimod1> | ocaml, despite it's hateful tooling, seems to be a reasonable FP without laziness |
| 2020-10-06 12:36:11 | <maerwald> | but it isn't pure either |
| 2020-10-06 12:36:19 | <dminuoso> | Habib: I see. prettyprinter is a pretty printing engine. |
| 2020-10-06 12:36:21 | <Habib> | dminuoso: error/warning messages, go on… |
| 2020-10-06 12:36:28 | <quazimod1> | that's true, do you need laziness to have purity? |
| 2020-10-06 12:36:38 | <dminuoso> | Habib: https://github.com/quchen/prettyprinter read the README down below :) |
| 2020-10-06 12:36:48 | <dminuoso> | It covers the motivation and uses for this library |
| 2020-10-06 12:37:06 | <maerwald> | quazimod1: you need to be able to make your language non-strict without it overthrowing the entire semantics (modulo bottom) |
| 2020-10-06 12:37:13 | <dminuoso> | (One important aspect is that prettyprinter makes a strict separation between the document that you prettyprint and the layouting |
| 2020-10-06 12:37:13 | <maerwald> | otherwise it's not pure |
| 2020-10-06 12:37:18 | <Habib> | i don't understand why it's recommended in the aelve guide alongside options like pretty-simple and then made out to be the best option (subjectively); they do completely different things |
| 2020-10-06 12:37:28 | <maerwald> | whether the language is actually strict or not doesn't matter for it to be pure |
| 2020-10-06 12:37:54 | → | jassy joins (~jassy@60-242-83-81.tpgi.com.au) |
| 2020-10-06 12:38:12 | <Habib> | dminuoso: can you say more about the separation between the document and the layouting? it seems all its primitives are about layouting. |
| 2020-10-06 12:38:16 | <quazimod1> | maerwald: is there an example that could illustrate that concept? |
| 2020-10-06 12:38:25 | <dminuoso> | Habib: Well, think of pretty-simple as giving an adhoc "prettificiation". Sort of a generic. |
| 2020-10-06 12:38:28 | <quazimod1> | i cant wrap my head around it |
| 2020-10-06 12:38:35 | <dminuoso> | Habib: No they are not! That's the beauty :) |
| 2020-10-06 12:38:49 | <maerwald> | quazimod1: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.27.7800&rep=rep1&type=pdf |
| 2020-10-06 12:38:59 | <dminuoso> | Habib: https://hackage.haskell.org/package/prettyprinter-1.7.0/docs/Prettyprinter.html |
| 2020-10-06 12:39:04 | <dminuoso> | Scroll down to "General workflow" |
| 2020-10-06 12:39:10 | <ski> | quazimod1 : "what happens when you have zero laziness... don't you just solve the same problems slightly differently" -- yes. or you don't solve them at all (give up, or work around them, in a more clumsy, less modular/composable way) (or you simulate laziness, with suspensions like the one maerwald linked to) |
| 2020-10-06 12:39:22 | <dminuoso> | So you write up a document, you layout it, and then you render it |
| 2020-10-06 12:39:30 | → | motherfs1 joins (~motherfsc@unaffiliated/motherfsck) |
| 2020-10-06 12:39:33 | <dminuoso> | And there's different layout algorithms (you can also write your own) |
| 2020-10-06 12:39:53 | <Habib> | so i could write a layout algorithm that lays out the document in the same way that pretty-simple does? |
| 2020-10-06 12:40:03 | <ski> | quazimod1 : OCaml is quite nice. and SML too. F# is not bad, either, although it lacks the good module system, alas |
All times are in UTC.