2024/10/03

Newest at the top

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
2024-10-03 19:12:21 +0200 <yahb2> <no output>
2024-10-03 19:12:20 +0200 <gentauro> % e = print 5
2024-10-03 19:12:12 +0200 <gentauro> (0.01 secs, 114,280 bytes)
2024-10-03 19:12:04 +0200 <gentauro> λ> e = print 5
2024-10-03 19:12:01 +0200 <yahb2> 5
2024-10-03 19:12:01 +0200 <EvanR> % print 5
2024-10-03 19:11:53 +0200 <gentauro> λ> :set -fprint-bind-result
2024-10-03 19:11:45 +0200 <geekosaur> otherwise you'd need to evaluate `e` separately
2024-10-03 19:11:13 +0200 <geekosaur> I think with `-fprint-bind-result` you'll see it because ghci detects things that are in `MonadIO` and sequences them for you
2024-10-03 19:10:32 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) merijn
2024-10-03 19:10:20 +0200 <gentauro> thx I mean
2024-10-03 19:10:17 +0200 <gentauro> geekosaur: No probs and tx.