- Haskell-Cafe - Haskell.org

RE: "interact" behaves oddly if used interactively
by Simon Marlow 03 Oct '03

03 Oct '03

> > The real problem is that lazy I/O injects side effects into the pure > > world of expressions. Haskell has a perfectly good system for > > encapsulating side effects - the IO monad. So why put > these sneaky side > > effects into pure values? > > I fear one problem is that the word "side effect" is not properly > defined. > > Actually both getContents and interact are in the IO monad. Since the > action "interact" is not terminated until the input stream ends, I do > not see any problem there. Yes, it is probably true that you cannot observe any non-referential-transparency using only interact. The side effects are only visible in the IO monad, and since as you say interact doesn't let you back into the IO monad until it has finished, it is probably safe. The unsafety is only visible using the other lazy I/O operations, principally hGetContents. > Evaluation never leaves the IO monad until > termination. getContents is more strange. However, you can just define > its semantics to yield a random string. When you are not > careful you may certainly get something nearly random ;-) So... you agree that getContents in its current form should really be called unsafeGetContents? Unless perhaps we redefine its semantics to either (a) yield a random string or (b) eagerly slurp the entire stream contents? Cheers, Simon

4 3

RE: "interact" behaves oddly if used interactively
by Simon Marlow 03 Oct '03

03 Oct '03

[ taking this one to haskell-café... ] > I still do not quite agree with Simon that 'interact' exposes anything > but non-strictness. Non-strictness means that > > map toUpper _|_ = _|_ > map toUpper ('a':_|_) = ('A':_|_) > map toUpper ('a':'b':_|_) = ('A':'B':_|_) > > and 'interact (map toUpper)' is a great way to experience > this property. > > However, you can also experience the property without 'interact', > evaluating expressions like > > take 2 (map toUpper ('a':'b':undefined)) Certainly you can observe non-strictness, that's not the point. The point is that you can also observe more than just non-strictness using interact, and I don't think that is desirable. For example: interact (\xs -> let z = length xs in "Hello World\n") Now, Haskell is a pure language, so it shouldn't matter whether the implementation evaluates z or not, as long as it is careful not to violate the non-strict semantics by turning a terminating program into a non-terminating one. A parallel Haskell implementation might happily spawn off another thread to evaluate z for example. An optimistic implementation might evaluate z for a fixed amount of time before continuing with the main thread of evaluation. BUT in the presence of lazy I/O this simply isn't true any more. Why? Because z is not pure; evaluating it has a side-effect. And yet it has type Int. Am I the only one who thinks this is wrong? Cheers, Simon

8 11

Question about Type Checking
by Clement 02 Oct '03

02 Oct '03

Hi i am doing a type checker. and how can i check if the Expn that i have is a Prim Function = ("f",[([Arg "x"],Simple (Int 2))]) type Function = (Name, [Equation]) type Equation = ([Expn], Body) {- (the body of) either a simple equation: f a1 .. an = e or a conditional equation: f a1 .. an | b1 = e1 ... | bm = em data Body = Simple Expn | Conditional [(Expn, Expn)] deriving (Show, Read) data Expn = Int Int | Char Char | Bool Bool | Arg Name | Prim Name | Func Name | Appn Expn Expn | Tuple [Expn] and how can i group the Expn together for Appn? __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

1 0

Pre-Call for Contributions -- HC&A Report (November 2003 edition)
by C.Reinke 02 Oct '03

02 Oct '03

[apologies for multiple copies - experience has shown that not all Haskellers can be reached via the main Haskell list anymore] An entry for your diaries (no other action required right now): ------------------------------Pre-Call-------------------------------- Your contributions to the November 2003 edition of the Haskell Communities & Activities Report will be invited soon. http://www.haskell.org/communities/ Submissions are welcome between 20th and 31st of October ---------------------------------------------------------------------- The real Call for Contributions will follow closer to the submission window, in about two weeks. This is just an early warning. You will need to plan about 15 minutes for composing your contribution, which would be a brief, ASCII-format, description of your Haskell activities (see earlier editions for plenty of examples). Cheers, Claus (current editor of HC&A Reports)

1 0

Re: ANNOUNCE: HaRe, the Haskell Refactorer, version 0.1
by ketil＠ii.uib.no 02 Oct '03

02 Oct '03

(taken to -cafe) "C.Reinke" <C.Reinke(a)kent.ac.uk> writes: > Dear Haskellers, > > as part of our project on Refactoring Functional Programs > > http://www.cs.kent.ac.uk/projects/refactor-fp/ > > we are pleased to announce the availability of HaRe 0.1 (also > known as HaRe 01/10/2003 ;-), a snapshot of our Haskell Refactorer > prototype. First, let me say that I'm intrigued. This looks like really neat functionality to have available. I'm curious whether you are planning (or have developed) tools to *detect* cases for refactoring? Occasionally, I find myself wishing for a tool to help me clean up a finished program, by e.g. - removing unused items from export/import lists - identifying functions which are only used in one place (and thus candidate for inclusion in 'where' clauses) - identifying functions defined in one module, but only (mainly?) used by/depending on functions in another module, and thus candidate for cross-module migration. - perhaps similarly, identify function transformation that reduces the parameter lists (i.e. exposed function interface) and so on. (Does that make sense at all? :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants

2 1

AW: Newbie qustion about monads
by Markus.Schnell＠infineon.com 02 Oct '03

02 Oct '03

> I'm not trying to create useful monads (I'm pretty sure they > aren't :), > but understanding the concepts. So, the question remains: > when the monad > laws say that > > (return x) >>= f == f x The Monad class is just called Monad because it is intended to cover a monad. But it doesn't ensure the laws. That is your sole responsibility. > > what is intended in that "=="? Eq."==" for You can define it to your liking as long as it is commutative. HTH, Markus

3 2

RE: swap leak problem
by Simon Marlow 02 Oct '03

02 Oct '03

> This sounds like a good plan (I do have a ghc build around). > How do I go > about compiling a debugging RTS? Add the following to mk/build.mk: GhcRtsHcOpts = -optc-DDEBUG GhcRtsCcOpts = -g then go into ghc/rts and 'make clean && make'. Now rebuild your program using this GHC (or alternatively add a -L flag pointing to this ghc/rts directory). Then run it with +RTS -DS -Sstderr, observe it going very slowly and see if it throws any assertion failures. Cheers, Simon

2 1

Non-blocking keyboard peek
by Adrian May 02 Oct '03

02 Oct '03

Hi folks, I have simulator which should grind away all night but check the keyboard once per iteration to see if I'm trying to view the results, change parameters or terminate it. Therefore I need a non-blocking keyboard peek function. So far, my searching only lead to some stuff about using threads in GHC but that seems far too complicated and messy. I have no reason to open a new thread and would still have to fight over some resource lock at the very position in the program where I would normally have just peeked at the keyboard and maybe called the menu procedure. I don't think such a peek function would affect referential transparency or be considered gauche for any other reason. Does it really not exist? Can I write it for a reasonable amount of effort? Thanks in advance, AM PS. This is the second of these mails I sent 'cos the first one just didnt show up on the list. ______________________________________________________________________________ Zwei Mal Platz 1 mit dem jeweils besten Testergebnis! WEB.DE FreeMail und WEB.DE Club bei Stiftung Warentest! http://f.web.de/?mc=021183

2 1

RE: Haskell-beginners problem with memory consuption
by Simon Marlow 02 Oct '03

02 Oct '03

> Keep in mind that Strings are lists of characters. I think (somebody > correct me if I'm wrong) GHC will store a character inside a cons > cell, but that still leaves 8 bytes per character. Worst case it will > store the 8-byte cons cell pointing to a 32-bit char value, 12 bytes > per character. (Strings as lists-of-char is very useful, but not > terribly efficient). Worst case: 16 bytes per character, usual case (all characters <= '\xff'): 8 bytes per character, because we have static copies of characters 0-255 in the RTS. Using Data.PackedString or UArray Char: 4 bytes per character. Cheers, Simon

1 0

RE: Lazy IO is useful! [Was: "interact" behaves oddly...]
by Simon Marlow 02 Oct '03

02 Oct '03

> main = > do let mylist = [1..10000] > writeFile "myfile.txt" (unlines (map show mylist)) This part does run in O(1) space and isn't problematic. > -- ... > mylist' <- (map read . lines) `fmap` readFile "myfile.txt" > let result = sum mylist' > print result Indeed, this works by interleaving the I/O and the computation of the result. It is a convenient way to program, because you can use ordinary list operations on the I/O stream. We know it is not "safe": a programmer can observe the fact that implicit I/O is going on. It is also not a good way to program: you have no way to catch errors and take appropriate action if the implicit I/O should fail in some way. Should we really be encouraging the writing of programs that have no error checking? > With lazy IO, this program too should run in constant space, and the > functions that consume the large intermediate structure can remain > unchanged! > > So, I think a lazy programming language should support not only lazy > evaluation, but also lazy IO! When it is appropriate to abstract away > from the details of when IO happens, lazy IO is useful. It can > facilitate separation of concerns and modularity, just like lazy > evaluation. Appropriate lazy IO should not compromise the > purity of the language or be an obstacle to optimistic evaluation. I look forward to seeing a form of lazy I/O that doesn't suffer from these problems! (although I suspect I still won't use it :-p) Cheers, Simon

1 0