2024/10/03

Newest at the top

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 +0200merijn(~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 +0200vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2024-10-03 19:18:27 +0200machinedgod(~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 +0200merijn(~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
2024-10-03 19:13:30 +0200 <c_wraith> it's just that ghci binds IO actions that are entered at the top level
2024-10-03 19:13:26 +0200 <EvanR> true, existence is an act of mental construction
2024-10-03 19:13:11 +0200 <c_wraith> seq (print 5) ()
2024-10-03 19:13:03 +0200 <c_wraith> even simply *existing* doesn't cause them to execute in ghci
2024-10-03 19:12:48 +0200 <EvanR> except in ghci
2024-10-03 19:12:38 +0200 <c_wraith> Yeah, seems to me that the best answer is "IO values aren't executed simply for existing"
2024-10-03 19:12:34 +0200 <gentauro> hmmmm
2024-10-03 19:12:28 +0200 <yahb2> <no output>
2024-10-03 19:12:28 +0200 <gentauro> % !e = print 5