Newest at the top
| 2024-10-03 19:27:14 +0200 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2024-10-03 19:25:28 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3105-0250-8807-c34f-69f1-3589.rev.sfr.net) alexherbo2 |
| 2024-10-03 19:25:26 +0200 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 252 seconds) |
| 2024-10-03 19:24:19 +0200 | <c_wraith> | which is why it's hidden away inside Control.Exception - it was originally intended for turning bottoms into exceptions at a predictable point in the IO action |
| 2024-10-03 19:23:45 +0200 | <EvanR> | or would take up gratuitous resources to delay evaluation |
| 2024-10-03 19:23:08 +0200 | <EvanR> | e.g. when the argument is something that might explode when evaluated and you want it to explode now |
| 2024-10-03 19:22:49 +0200 | <EvanR> | very useful |
| 2024-10-03 19:22:39 +0200 | <EvanR> | only works in IO though |
| 2024-10-03 19:22:21 +0200 | <EvanR> | evaluates the argument to WHNF |
| 2024-10-03 19:21:56 +0200 | <yahb2> | evaluate :: a -> IO a |
| 2024-10-03 19:21:56 +0200 | <gentauro> | % :t evaluate |
| 2024-10-03 19:21:53 +0200 | <gentauro> | %:t evaluate |
| 2024-10-03 19:21:30 +0200 | <c_wraith> | that absolutely 100% evaluates the IO action. |
| 2024-10-03 19:21:14 +0200 | <yahb2> | <no output> |
| 2024-10-03 19:21:14 +0200 | <c_wraith> | % evaluate (print 5) |
| 2024-10-03 19:21:12 +0200 | <yahb2> | <no output> |
| 2024-10-03 19:21:12 +0200 | <c_wraith> | % :m + Control.Exception |
| 2024-10-03 19:21:05 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 19:20:54 +0200 | <yahb2> | <interactive>:47:1: error: [GHC-88464] ; Variable not in scope: evaluate :: IO () -> t |
| 2024-10-03 19:20:54 +0200 | <c_wraith> | % evaluate (print 5) |
| 2024-10-03 19:20:42 +0200 | <c_wraith> | ah, here's an even better example of "not laziness" |
| 2024-10-03 19:19:02 +0200 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2024-10-03 19:18:27 +0200 | machinedgod | (~machinedg@d50-99-47-73.abhsia.telus.net) (Ping timeout: 276 seconds) |
| 2024-10-03 19:18:19 +0200 | <c_wraith> | (though you did have to accept that sometimes it inserts implicit uses of print) |
| 2024-10-03 19:17:27 +0200 | <c_wraith> | EvanR: it used to be correct, before people insisted ghci become complicated for no reason |
| 2024-10-03 19:17:06 +0200 | <EvanR> | simulating being inside a do block theory has its wheels fall off sometimes |
| 2024-10-03 19:16:57 +0200 | <gentauro> | geekosaur: yeah, I noticed that |
| 2024-10-03 19:16:50 +0200 | <geekosaur> | okay, so print-bind-result doens't apply to let I guess |
| 2024-10-03 19:16:36 +0200 | <yahb2> | 5 |
| 2024-10-03 19:16:36 +0200 | <geekosaur> | % !e <- print 5 |
| 2024-10-03 19:16:30 +0200 | <EvanR> | if the expression is an IO action it executes, otherwise no |
| 2024-10-03 19:16:27 +0200 | <yahb2> | <no output> |
| 2024-10-03 19:16:27 +0200 | <geekosaur> | % !e = print 5 |
| 2024-10-03 19:16:27 +0200 | <c_wraith> | No relevant laziness |
| 2024-10-03 19:16:22 +0200 | <yahb2> | <no output> |
| 2024-10-03 19:16:22 +0200 | <geekosaur> | % :set -fprint-bind-result |
| 2024-10-03 19:16:14 +0200 | <c_wraith> | that strictly evaluates (print 5) |
| 2024-10-03 19:16:04 +0200 | <c_wraith> | seq (print 5) () |
| 2024-10-03 19:16:00 +0200 | <c_wraith> | I mean, no |
| 2024-10-03 19:15:51 +0200 | <EvanR> | ^ |
| 2024-10-03 19:15:14 +0200 | <gentauro> | but I think that the behavior might have to due solely to `ghci` |
| 2024-10-03 19:15:12 +0200 | <c_wraith> | that made it complicated for no value |
| 2024-10-03 19:15:10 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 19:15:07 +0200 | <c_wraith> | well, it was until people started demanding the ability to add declarations in ghci |
| 2024-10-03 19:14:57 +0200 | <gentauro> | EvanR: Yes and no. My guess for what author is experiencing was the lazy nature of Haskell and hereby `ghci` |
| 2024-10-03 19:14:51 +0200 | <c_wraith> | ghci's behavior is "you are entering lines in a do block that makes up the entry point of the program". Nice and simple. |
| 2024-10-03 19:14:14 +0200 | <EvanR> | which is weird |
| 2024-10-03 19:14:06 +0200 | <EvanR> | gentauro was asking about ghci's behavior I thought |
| 2024-10-03 19:13:47 +0200 | <EvanR> | on top of that |
| 2024-10-03 19:13:32 +0200 | <EvanR> | you actually have to type it in ghci |