Logs: liberachat/#haskell
| 2021-06-23 16:49:36 | <monochrom> | I just gave out an assignment to students yesterday, it's coding up iterative deepening in Haskell, taking advantage of lazy lists and lazy evaluation. I began with "this assignment deepens (pun intended, just you wait) your experience with lazy evaluation" |
| 2021-06-23 16:49:52 | × | warnz quits (~warnz@2600:1700:77c0:5610:799f:ce24:eb20:cceb) (Remote host closed the connection) |
| 2021-06-23 16:51:21 | <c_wraith> | Laziness and iterative deepening seem like a weird mix. the big benefit to iterative deepening it (usually) uses way less memory than a breadth-first search. |
| 2021-06-23 16:51:35 | <c_wraith> | +is |
| 2021-06-23 16:53:28 | <monochrom> | Breadth-first search still takes up much memory under lazy evaluation. |
| 2021-06-23 16:54:52 | <c_wraith> | I suppose you could apply laziness to things like generating a list of all paths examined by iterative deepening without blowing up its memory use |
| 2021-06-23 16:55:05 | × | dhil quits (~dhil@80.208.56.181) (Ping timeout: 265 seconds) |
| 2021-06-23 16:56:16 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-06-23 16:57:32 | × | fef quits (~thedawn@user/thedawn) (Remote host closed the connection) |
| 2021-06-23 16:58:21 | → | fef joins (~thedawn@user/thedawn) |
| 2021-06-23 16:58:23 | × | peterhil_ quits (~peterhil@dsl-hkibng32-54f849-252.dhcp.inet.fi) (Quit: Must not waste too much time here...) |
| 2021-06-23 16:58:34 | → | peterhil joins (~peterhil@dsl-hkibng32-54f849-252.dhcp.inet.fi) |
| 2021-06-23 17:03:03 | × | Guest3175 quits (~Guest31@176.41.31.219) (Quit: Client closed) |
| 2021-06-23 17:03:04 | → | ystael joins (~ystael@user/ystael) |
| 2021-06-23 17:03:10 | → | mc47 joins (~mc47@xmonad/TheMC47) |
| 2021-06-23 17:03:38 | × | kuribas quits (~user@ptr-25vy0ia3kl0vdl4qmg0.18120a2.ip6.access.telenet.be) (Quit: ERC (IRC client for Emacs 26.3)) |
| 2021-06-23 17:04:25 | → | eggplantade joins (~Eggplanta@2600:1700:bef1:5e10:e846:fcb5:a54b:afb8) |
| 2021-06-23 17:04:35 | <norias> | yeah, to be honest, coming from imperative programming |
| 2021-06-23 17:04:41 | <norias> | i'm 1 day in to haskell |
| 2021-06-23 17:04:56 | <norias> | and i can't imagine how programs that do things happen in functional programming |
| 2021-06-23 17:05:07 | <norias> | not saying it can't / doesn't happen |
| 2021-06-23 17:05:20 | <norias> | just my brain hasn't reached comprehension, yet |
| 2021-06-23 17:05:29 | <norias> | but it looks cool as hell |
| 2021-06-23 17:07:44 | <ski> | you compute a series of intput/output interactions with the external world (everything outside of the process running the Haskell program) |
| 2021-06-23 17:08:14 | × | tromp quits (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2021-06-23 17:08:38 | <ski> | the simplest possible model of this is to view a program as a function that, given input text (standard input), computes output text (standard output) |
| 2021-06-23 17:08:45 | → | dhil joins (~dhil@195.213.192.47) |
| 2021-06-23 17:08:53 | <ski> | @type interact |
| 2021-06-23 17:08:54 | <lambdabot> | (String -> String) -> IO () |
| 2021-06-23 17:09:18 | × | eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:e846:fcb5:a54b:afb8) (Ping timeout: 264 seconds) |
| 2021-06-23 17:09:40 | → | ec joins (~ec@gateway/tor-sasl/ec) |
| 2021-06-23 17:09:50 | <ski> | can be used, to play with this idea. e.g. passing a function that divides up the input `String' into lives, reversing each line, then concatenating them together into a `String' again |
| 2021-06-23 17:10:24 | <ski> | @type interact (unlines . map reverse . lines) |
| 2021-06-23 17:10:25 | <lambdabot> | IO () |
| 2021-06-23 17:10:57 | <ski> | > (unlines . map reverse . lines) "foo\nbar\nbaz\n" |
| 2021-06-23 17:10:58 | <lambdabot> | "oof\nrab\nzab\n" |
| 2021-06-23 17:11:55 | <ski> | however, when you want to do more sophisticated (text-based) interactions, or when you start to want to do other things (open files, network connections, spawn other processes, &c.), this simplistic model shows its limitations |
| 2021-06-23 17:13:17 | <ski> | and so we have a richer ((embedded) domain-specific) language for specifying exactly what I/O interactions to do, in which order. which is the `IO' (abstract data) type |
| 2021-06-23 17:13:22 | <ski> | @type getLine |
| 2021-06-23 17:13:23 | <lambdabot> | IO String |
| 2021-06-23 17:15:41 | × | aman quits (~aman@user/aman) (Ping timeout: 268 seconds) |
| 2021-06-23 17:16:41 | <ski> | a value of type `IO String' describes interactions to perform, so as to (hopefully) compute a `String' in the end, as result |
| 2021-06-23 17:18:08 | → | eggplantade joins (~Eggplanta@2600:1700:bef1:5e10:e846:fcb5:a54b:afb8) |
| 2021-06-23 17:18:37 | <ski> | (in any case, the `IO String' does not (in general) "contain" any `String'. the `String' will be computed, as a result of actually performing the series of instructions specified by the value of type `IO String' (the "action"). performing/running it again, will quite possibly result in a different `String' being produced. but it's still the same action, the same value of type `IO String', that's being run) |
| 2021-06-23 17:20:42 | → | wallymathieu joins (~wallymath@81-234-151-21-no94.tbcn.telia.com) |
| 2021-06-23 17:20:45 | <ski> | norias : so, by using basic "action" building blocks, like `getLine', one can combine them into larger, more complicated actions, using `(>>)' or `(>>=)', which constructs an action from two smaller ones, that, when later executed, will first execute the first "su-action", then the second one |
| 2021-06-23 17:20:56 | <ski> | (>>) :: IO a -> IO b -> IO b |
| 2021-06-23 17:21:09 | <ski> | (>>=) :: IO a -> (a -> IO b) -> IO b |
| 2021-06-23 17:21:26 | × | ozzymcduff quits (~mathieu@81-234-151-21-no94.tbcn.telia.com) (Remote host closed the connection) |
| 2021-06-23 17:22:02 | → | MorrowM joins (~MorrowM_@bzq-110-168-31-106.red.bezeqint.net) |
| 2021-06-23 17:22:11 | <ski> | `actA >> actB' will, when executed, first execute `actA' (throwing away its result value), then execute `actB' (whose result value will be the result value of the execution of the whole `actA >> actB') |
| 2021-06-23 17:22:43 | → | ixlun joins (~ixlun@2001:470:69fc:105::41b3) |
| 2021-06-23 17:23:43 | → | ozzymcduff joins (~mathieu@81-234-151-21-no94.tbcn.telia.com) |
| 2021-06-23 17:23:52 | <ski> | the second combinator is to not throw away the intermediate result, but rather allow the second action to depend on which value resulted from executing the first action. so the second one is actually a function that is fed the intermediate result, and (possibly) uses that to construct the second action to perform |
| 2021-06-23 17:24:02 | × | involans quits (~alex@cpc92718-cmbg20-2-0-cust157.5-4.cable.virginm.net) (Ping timeout: 258 seconds) |
| 2021-06-23 17:25:35 | <ski> | so, `act >>= cont' will, when executed, first execute `act', getting its result back (call it `res'); then execute `cont res' (passing the intermediate result to the function ("continuation") that then computes the second action to execute). as before, the result of the second action is the result of the whole |
| 2021-06-23 17:26:19 | <ski> | so, one very simple program now is `getLine >>= putStrLn'. a slightly more complicated one is `getLine >>= (putStrLn . reverse)' |
| 2021-06-23 17:26:23 | → | gehmehgeh joins (~user@user/gehmehgeh) |
| 2021-06-23 17:26:25 | <ski> | @type putStrLn |
| 2021-06-23 17:26:26 | <lambdabot> | String -> IO () |
| 2021-06-23 17:27:01 | → | thyriaen joins (~thyriaen@45.178.75.13) |
| 2021-06-23 17:27:12 | <ski> | `putStrLn str' is action that, when executed, will output `str' (on standard output) (and then give back an uninteresting result (of type `()') from the execution) |
| 2021-06-23 17:28:36 | × | DNH quits (~DNH@2a09:bac0:48::82b:7a06) (Ping timeout: 250 seconds) |
| 2021-06-23 17:28:38 | <ski> | next step up in complexity is to start to put conditionals, or `case' distinctions, into the second action (after `>>='), so that you decide to respond in different ways, depending on the intermediate result from the first action |
| 2021-06-23 17:28:40 | → | safinaskar joins (~safinaska@109-252-90-89.nat.spd-mgts.ru) |
| 2021-06-23 17:29:35 | <ski> | norias : that's a very quick sketch of the very basics of Haskell I/O .. to get a better feel for this, you'd have to play around with it, and try to build larger things |
| 2021-06-23 17:29:37 | <safinaskar> | is it possible to pass runtime values as arguments to types? i asked this question today, and got answer that this is possible to fake somehow. please, give me some examples |
| 2021-06-23 17:30:22 | × | thyriaen quits (~thyriaen@45.178.75.13) (Client Quit) |
| 2021-06-23 17:30:33 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 258 seconds) |
| 2021-06-23 17:30:39 | <carbolymer> | davean: that's fucked up. It's the opposite what's nix promises |
| 2021-06-23 17:31:11 | → | jmcarthur joins (~jmcarthur@c-73-29-224-10.hsd1.nj.comcast.net) |
| 2021-06-23 17:31:15 | <safinaskar> | for example, I want "head" with this prototype: head :: forall a. foreach (x :: [a]). (null x ~ False) -> a |
| 2021-06-23 17:31:17 | <ski> | safinaskar : that's dependent types |
| 2021-06-23 17:31:27 | <safinaskar> | is it possible to fake this "head" using singletons? |
| 2021-06-23 17:31:56 | <ixlun> | Hi all. I've got this code: https://termbin.com/r17ge . I'm reading in a binary file that's approx 700Mb of floats. It takes a long time to run (in the order of minutes). I would have thought with lazy bytestrings this would have been pretty quick. |
| 2021-06-23 17:32:43 | × | fizbin quits (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) (Remote host closed the connection) |
| 2021-06-23 17:34:20 | <monochrom> | "(runGet $ many getFloatle)" kills laziness. |
| 2021-06-23 17:35:00 | <monochrom> | Building a long list also takes up much memory therefore time. |
| 2021-06-23 17:35:37 | <ski> | safinaskar : singletons allow you to associate a value with a corresponding type, "of the same shape". but the value is of a new type, specifically made for this. e.g. `data Nat = Zero | Succ Nat', then `data NatIs :: Nat -> * where IsZero :: NatIs Zero; IsSucc :: NatIs n -> NatIs (Succ n)'. so, given an input of type `NatIs n', you automatically get a corresponding type `n' |
| 2021-06-23 17:36:33 | <ski> | safinaskar : but i'm not aware of a way to do this generically (for your arbitrary element type `a', say) |
| 2021-06-23 17:36:48 | × | jmcarthur quits (~jmcarthur@c-73-29-224-10.hsd1.nj.comcast.net) (Quit: My MacBook Air has gone to sleep. ZZZzzz…) |
| 2021-06-23 17:37:18 | <ixlun> | monochrom: Right, I presume it's the runGet function that's killing laziness? If so, is there a way around it? |
| 2021-06-23 17:37:51 | → | MoC joins (~moc@user/moc) |
| 2021-06-23 17:38:19 | <monochrom> | "many" kills laziness. |
| 2021-06-23 17:38:34 | × | mikail__ quits (~mikail@90.212.77.3) (Ping timeout: 250 seconds) |
| 2021-06-23 17:38:57 | → | Erutuon joins (~Erutuon@user/erutuon) |
| 2021-06-23 17:43:17 | <safinaskar> | ski: it seems i understand. and this means that we can have, say, list of such naturals using existential types, right? i. e. we can define "data Foo = forall (n :: Nat). Foo (NatIs n)", and then we can have "someList :: [Foo]". right? |
| 2021-06-23 17:44:32 | <ixlun> | monochrom: Right. Do you think I need to do some kind of incremental reads? |
| 2021-06-23 17:44:58 | <monochrom> | Use runGetOrFail on one single getFloatle. Or use conduit or pipes. |
| 2021-06-23 17:45:38 | × | MorrowM quits (~MorrowM_@bzq-110-168-31-106.red.bezeqint.net) (Remote host closed the connection) |
| 2021-06-23 17:45:56 | → | MorrowM joins (~MorrowM_@bzq-110-168-31-106.red.bezeqint.net) |
| 2021-06-23 17:45:56 | → | Guest33 joins (~Guest33@104.246.145.85) |
| 2021-06-23 17:46:41 | → | fizbin joins (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) |
| 2021-06-23 17:47:54 | × | kayprish quits (~kayprish@46.240.143.86) (Remote host closed the connection) |
| 2021-06-23 17:48:59 | × | sleblanc quits (~sleblanc@user/sleblanc) (Ping timeout: 268 seconds) |
| 2021-06-23 17:50:36 | <qrpnxz> | is there a way to just import everything in the std lib in one go? |
| 2021-06-23 17:51:50 | <ski> | safinaskar : yes, but that seems fairly useless, since `exists n. NatIs n' would simply be isomorphic to a plain (value-level) `Nat' |
| 2021-06-23 17:52:06 | <ixlun> | monochrom: okay I'll take a look at that. Thanks! |
| 2021-06-23 17:52:19 | <ski> | the sole point of `NatIs n' would be to mention `n' elsewhere |
| 2021-06-23 17:52:55 | × | Guest33 quits (~Guest33@104.246.145.85) (Quit: Client closed) |
All times are in UTC.