00:00:00 --- log: started haskell/02.03.15 02:12:59 --- join: ChoJin (~ask@cha213245038031.chello.fr) joined #haskell 02:46:57 --- join: shapr (~user@p-c2fbab7e.easy.inet.fi) joined #haskell 02:50:16 --- join: pesco (~pesco@pD9501143.dip.t-dialin.net) joined #haskell 02:51:43 --- quit: shapr ("dammit") 02:52:27 --- quit: pesco ("Client Exiting") 02:54:55 --- join: pesco (~pesco@pD9501143.dip.t-dialin.net) joined #haskell 04:15:10 --- join: shapr (~user@p-c2fbab7e.easy.inet.fi) joined #haskell 04:32:15 --- quit: Jiriki (Read error: 104 (Connection reset by peer)) 04:34:25 --- join: Jiriki (sjh@207.164.213.150) joined #haskell 05:18:23 --- quit: ChoJin ("bye !!!") 05:21:54 Here's a new question concerning the use of the ST monad: 05:22:18 Again, I'm implementing RC4. 05:22:56 Thus I have a stream of text bytes bs which I'll XOR with a stream of key bytes ks. 05:24:00 right 05:24:01 The stream of key bytes is (theoretically) an infinite sequence of numbers calculated by repeated execution of a certain algorithm within a state. 05:25:01 Is there a way to lazily define this infinite key stream by means of a state transformer program? 05:25:16 I think you'll need to use a lazy state monad 05:25:24 I *think* the GHC one defaults to being strict 05:25:29 I see. 05:25:50 I'm not too firm on the terminology strict<->lazy 05:26:29 I didn't quite know what they meant by a _monad_ being strict/lazy. 05:26:31 in this case, I think what it means is that if you do a state computation, a strict state monad will immediately evaluate it enough to work out it's effect on the state 05:26:38 s/it's/its/ 05:27:05 Yes. And a lazy one will wait until the new state is actuelly needed. 05:27:27 yeah 05:27:34 (I *think*, I'm not 100% certain about this myself) 05:27:55 It sounds reasonable to me. 05:28:05 looks like GHC does have the LazyST monad, anyway 05:29:39 Yeah, and it sounds as it's the one I want. Thanks alot... 05:34:46 just be careful you never require the final state from that key stream.. :-) 05:43:04 what do you mean by final state? 05:43:53 I'm not trying to output it all, if that's what you mean... :) 05:44:41 no, but you said generating each element of the key stream modifies some state, right? 05:44:52 do you need that state for anything ever again after you've finished with that key stream? 05:47:06 no. 05:47:11 that's good :-) 05:47:17 I see. 05:47:26 cos if you did, laziness wouldn't help you 05:47:43 Right. That's what you meant by final state, ok. 05:48:22 It's just a computation that is supposed to be done once for each byte, yielding a key byte in each iteration. 05:49:07 Aw, LazyST doesn't offer modifySTRef. Why not? 05:50:36 no idea. Shouldn't be hard to write, though 05:51:02 modifySTRef v f = do x <- readSTRef v 05:51:08 writeSTRef v (f x) 05:51:23 with the layout correct and arguments put in the appropriate positions if they aren't already there 05:52:33 :) Just did that on the other desktop... 05:55:43 Ahww, it doesn't work. But it leaks space! :) 05:57:12 woohoo! 05:57:15 * pesco bounces 06:02:25 Can modules be reopened, like namespaces in C++, so I can add my modifySTRef inside the LazyST module? 06:03:41 You can write a module LazySTm (module LazyST, modifySTRef) where import LazyST; modifySTRef = ... 06:03:59 Yes, sounds good enough. 06:04:12 Calling the same name might lead to qualification ugliness unless it's a function in a class, though 06:04:36 s/Calling/Calling it/ (refering to modifySTRef) 06:06:44 Hm. 07:22:59 Igloo_: same name as what? 07:23:14 it doesn't matter if it clashes with the one from ST, since he can't possible have both imported unqualified at the same time 07:23:26 since things like readSTRef and writeSTRef etc would clash 07:26:36 Oh, if there are already clashes then ignore that 07:27:03 * Igloo_ wonders why there isn't an ST class in that case 07:47:12 This is great, I'm really beginning to like this language. 07:59:49 --- quit: shapr ("brb") 08:06:36 --- join: shapr (~user@p-c2fbab7e.easy.inet.fi) joined #haskell 08:50:39 whee? 08:51:10 'lo 09:22:58 --- quit: Yurik ("reboot") 10:04:11 --- join: ski (~md9slj@fraggel26.mdstud.chalmers.se) joined #haskell 10:56:28 --- quit: ski ("bye") 11:27:52 --- join: samx (~sam@dyn-A-136.yhteys.mtv3.fi) joined #haskell 11:40:07 * pesco is away: Saufen 11:46:20 --- join: guest007 (~guest007@cm219.omega69.scvmaxonline.com.sg) joined #haskell 11:47:23 --- part: guest007 left #haskell 11:52:33 --- join: YveDeLarc (~gefla@pD9E39C91.dip.t-dialin.net) joined #haskell 11:54:52 hi 12:53:04 hello 12:53:49 you've reached the irc channel for the Haskell Programming Language. No one is awake right, but if you'd like to leave a message, we'll get back to you. 12:53:50 ;) 13:08:03 haskell interpreter is busy interpreting your message. please come back tomorrow for the answer 13:20:08 --- join: ski (~md9slj@fraggel26.mdstud.chalmers.se) joined #haskell 14:02:04 --- quit: ski ("zzz") 15:29:21 * YveDeLarc grins. 15:29:53 greetTheOthers :: IO IrcAction 15:30:43 well. I'll check back again sometime. Have a good time. 15:30:46 --- part: YveDeLarc left #haskell 15:40:07 --- join: gene9 (~andrey@194.158.215.164) joined #haskell 16:47:34 --- quit: gene9 ("Client Exiting") 17:07:19 --- join: gene9 (dna@194.158.217.128) joined #haskell 17:57:58 --- quit: gene9 ("b") 19:27:07 --- quit: samx (Read error: 110 (Connection timed out)) 21:09:40 --- join: jemfinch (~jemfinch@rnie-99-43.resnet.ohio-state.edu) joined #haskell 21:20:04 --- part: jemfinch left #haskell 21:24:41 --- quit: pesco (Remote closed the connection) 22:02:43 --- quit: shapr (carter.openprojects.net irc.openprojects.net) 23:59:59 --- log: ended haskell/02.03.15