August 2001 - Haskell-Cafe

Emacs
by Mark Carroll 17 Aug '01

17 Aug '01

Is it just me, or does haskell-indent-mode sometimes have some surprising ideas about how much to indent? That Haskell modes exist at all is wonderful. (-: -- Mark

1 0

Re: Deep confusion about monads
by Mark Carroll 17 Aug '01

17 Aug '01

Gosh, thank you everybody! Let me try to summarise where I am, given all the help. haskell-cafe is an okay place to ask this stuff. (-: I should also check out the wiki too; it looked a bit scary to use last time I looked, but it seems to have relevant stuff. It's a pity that the mailing list archives aren't more easily searched; maybe applying google to them would work. Part of my confusion was due to a usual problem with teaching. People come in to a lesson with preconceived ideas X, the teacher tells them stuff Y, and instead of coming out of the lesson thinking Y, they come out thinking f(X,Y), because the teacher didn't tell them not-X. It's instructional to ask children where they think trees' mass comes from as they grow, after a lesson on the subject. I originally thought that "IO a" meant "an a whose value may depend on some IO that was done", as if that data were tainted by other data it touched which stemmed from IO actions. Instead, "IO a" it appears to mean "some IO action you can do that will give an a", and you can only do stuff with the "a" within an "IO-aware" context. A Haskell program is an IO action. I got the idea of tainted data from Perl, which is a security aid to help you ensure that any data drawn from outside your program has to be approved by you before your program can use it to affect other things outside your program. Try to keep most code functional, even if this means that your monadic code uses very complex referentially-transparent helper functions. I hadn't bumped into Theo Norvell's monad tutorial yet. I'm guessing that it's the one at http://www.engr.mun.ca/~theo/Misc/haskell_and_monads.htm ? I'll take a look. There is a concept of being in the IO monad. My current concept of "A >>= B" is that it helps let B into the monad that A's in. This is how 'head' is let in by readFile "/etc/hosts" >>= (return . head) I find fmap deeply strange, though, because I don't really understand functors. People pointed me towards fmap, and I figured from IO's instance of Functor that fmap head $ readFile "/etc/hosts" also works, so I plan to learn a little category theory to help find out why this makes sense. (Someone also taught me how to use $. (-:) >>= actually has the type (Monad m) => m a -> (a -> m b) -> m b That makes some sense. I get >> and the syntactic sugar of 'do' looks fairly simple so I'll probably start using that more once I'm happy with the translation between that and >>= All the best, Mark

1 0

RE: Namespace clashes
by brk＠jenkon.com 17 Aug '01

17 Aug '01

> -----Original Message----- > From: Mark Carroll [SMTP:mark@chaos.x-philes.com] > Sent: Wednesday, August 15, 2001 10:11 PM > To: haskell-cafe(a)haskell.org > Subject: Namespace clashes > > When I use Haskell, I'm still tripping over reserved words; lately I tried > to use 'type' as a data field name, for example, and was somewhat > irritated to note that I can't. (Can I?) What gives me the willies is that > [Bryn Keller] Personally, I don't mind this sort of thing and I find the import capabilities in Haskell sufficient for most purposes. However, I'm new enough to Haskell that I sometimes have a hard time figuring out what I've done wrong from the error messages. Here's one such: func x = do data <- readFile x return data Where the problem is that I've mistakenly used the reserved word 'data' for a name binding. Here's the error message I get for that: scratch.hs:3: Empty 'do' construct But I'm learning. :-)

2 1

Deep confusion about monads
by Mark Carroll 16 Aug '01

16 Aug '01

Let me know if I'm bugging you guys too much. It'd be great if I had someone close at hand who knew more about Haskell than I do, but unfortunately I don't. Are there any fora that are especially for people to help novices, or is haskell-cafe the best fit? I decided I ought to learn more about monads, so I've been trying to do simple IO. However, I'm running into really basic problems that I haven't managed to solve with the three monad tutorials I've read so far! First, given an IO String, I don't seem to be able to take the head of it to get an IO Char. I'm guessing that the IO monad is quite unlike the simple 'tainting' I first imagined; I reall do seem to have to treat it as an abstract polymorphic type. Worse, I can't work out how to write a IO String -> IO Char version of head; I can't make my (x:xs) match an IO String! Better would be if I could somehow write an IO String -> IO Char wrapper for head. I'm also confused as to why I can write: readFile "/tmp/foo" >>= putStr to print out the contents of a file but, in ghci, let x = readFile "/tmp/foo" putStr x ...doesn't work. Then again, I'm also confused by the way that Simon Thompson's book says that, (>>=) :: IO a -> (a -> IO a) -> IO a which I think might be a misprint for, (>>=) :: IO a -> (a -> IO b) -> IO b ...? I'm not sure if I've explained enough of my confusion that a succinct, helpful response not mentioned in what I've read so far can be easily given. I guess that my problem is that I had initially imagined that the prefix 'IO' appears as a magical tainting of any data that could depend on the result of some IO action. However, I'm coming to the conclusion that I'm quite wrong in this. I'd like to be able to manipulate IO Strings as if they were just strings that I can't forget came from IO, but I'm guessing now that things aren't that simple - they really are quite different to strings, yet I want to avoid resorting to unsafePerformIO. The really annoying thing is that all the monad examples I've read so far have made perfect sense to me. (-: What I'm really hoping is that a simple answer as to how best to arrange my IO String -> IO Char (or IO [a] -> IO a) version of head will somehow resolve a lot of my confusion. For instance, maybe I have to somehow write an 'action' version of head that I apply with the help of >>= ? -- Mark

4 6

Re: Deep confusion about monads
by Ashley Yakeley 16 Aug '01

16 Aug '01

At 2001-08-16 16:30, I wrote: >>(>>=) :: IO a -> (a -> IO b) -> IO b > >This one is correct. Whoops! No it's not. It should be: (>>=) :: (Monad m) => m a -> (a -> m b) -> m b The other two are however special cases of this type. -- Ashley Yakeley, Seattle WA

1 0

Re: Deep confusion about monads
by Ashley Yakeley 16 Aug '01

16 Aug '01

At 2001-08-16 13:30, Mark Carroll wrote: >in ghci, > >let x = readFile "/tmp/foo" x here has type "IO String" >putStr x putStr wants x to be type "String". You want this: do { x <- readFile "/tmp/foo"; putStr x; } ...which is translated to... readFile "/tmp/foo" >>= (\x -> putStr x) >(>>=) :: IO a -> (a -> IO b) -> IO b This one is correct. -- Ashley Yakeley, Seattle WA

1 0

Qualified imports
by Mark Carroll 16 Aug '01

16 Aug '01

In writing a large program, do people tend to just name all their functions differently, or do they make much use of qualified imports? I'm currently facing this design decision in starting my first significant Haskell project and I'd prefer to do whatever's conventional in the Haskell community. Personally, I'd probably veer towards all the qualified stuff, given that I'm the sort of person who never uses 'import' in Java, but then I have the question of how to name types that would otherwise be of the form Foo.Foo and look silly. (In Modula-3, Foo.T would be the traditional choice.) -- Mark

2 1

Namespace clashes
by Mark Carroll 16 Aug '01

16 Aug '01

When I used to use Modula-3, I never had to worry about mildly-surprising namespace clashes. This was for two reasons: (a) Functions imported from other modules could only be referred to by prefixing their name with their module's name. (b) All system-provided keywords were upper case, and one named variables and functions using mixed case or lower case. When I use Haskell, I'm still tripping over reserved words; lately I tried to use 'type' as a data field name, for example, and was somewhat irritated to note that I can't. (Can I?) What gives me the willies is that a later Haskell might introduce a new keyword or a new Prelude function that clashes with something I define myself (not that it's that unstable, I know). Of course, I haven't tried this, but maybe if I always did an "import qualified Prelude"-type thing, that might mean I was always definitely safe from at least Prelude extensions though not language changes, but maybe at the price of my code looking real nasty! I'm not exactly complaining here; I suppose Lisp had the same problem. I'm just noting the thought. (-: Overall, I'm quite enjoying playing with Haskell. -- Mark

1 0

RE: newbie conceptual question [from haskell list]
by Frank Atanassow 15 Aug '01

15 Aug '01

[redirected from haskell(a)haskell.org to haskell-cafe(a)haskell.org] David Hughes wrote: > > It seems to me that I can still use functional > > programming paradigm with an imperative language. How can I benefit more > > from a functional programming language (i.e.Haskell)? > Point One: functional languages are powerful. [..] > Point Two: functional languages are beautiful. [..] > Point Three: functional languages are robust; [..] These things are nice, but the more I learn about functional languages, the more I feel that they are only icing on the cake. The most important thing about functional languages is that we know _what they are_, and that they can be characterized in a regular fashion which is amenable to analysis; in other words, we know how to reason about them, and what sorts of properties functional programs satisfy. Saying that a language "satisfies nice properties" sounds abstract and useless to some people who just want to get things done, but I really believe that it helps not only researchers who know know how to read and use formal semantics, but also everyday programmers, because they absorb some of these reasoning methods and then start using them intuitively and unconsciously. For example, every Haskell programmer has some grasp of referential transparency, and uses it implicitly every time he thinks about how to structure or rearrange his programs. Of course, this argument holds for any "simple" language, not just functional ones, where by "simple" I mean "easy to reason about". For example, there are concurrent calculi of processes, object calculi and first-order algebraic languages which also share this property, and I prefer any of them to warty conventional languages. (And this is why I also like SML: even though it's not referentially transparent like Haskell, I know what sorts of properties it satisfies.) > Point Four: functional languages are difficult are learn. [..] I would say "there is more in functional languages to learn about than there is in conventional languages". I get the feeling that programmers who come into FP from more conventional languages expect that FP will be just like C, only with a few new features and the syntax mixed up a bit, because if you look at the world of conventional languages---C, C++, Pascal, Java, Python, Perl, Ruby, FORTRAN---it is almost invariably true: there is hardly any difference between these languages, except surface syntax, and the fact that in some of them you have to macro-define what is a built-in in another. So they are all about the same level of difficulty, because they are really no genuinely new concepts, or at least they are not encapsulated in the language. Also, they are mostly implementation-defined: if you roughly know the von Neumann architecture, then you know what to expect. Haskell (and ML) really is different. First, it's not implementation-defined. Second, they satisfy some genuinely new properties. Some of these languages have closures, for example, but they don't obey the same properties as Haskell's higher-order functions because you don't have referential transparency. So you have to start thinking, "OK, is this one of those situations where I _can't_ use this property?", and pretty soon that's all you're thinking about---the exceptions to the rule. (At least, this is what happens to me in, for example, Emacs LISP, where closures can only be passed downwards.) In Haskell, you never have to think about that, because though the context may affect the efficiency of a program, it cannot affect its meaning. > Point Five: there's a dearth of libraries. [..] > Philip Wadler, "What The Hell Are Monads?" The second one is by Noel Winstanley, not Wadler. --- Frank Atanassow, Information & Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508TB Utrecht, The Netherlands Tel +31 (0)30 253-3261 Fax +31 (0)30 251-3791

6 20

Spotting unnecessary parentheses
by Mark Carroll 13 Aug '01

13 Aug '01

While I'm hesitantly trying to write Haskell, I'm over-using brackets so as to eliminate precedence problems from the list of things I did wrong this time. Is there any easy way of finding out which brackets are unnecessary? Nobody's written a redundancy-remover or anything? (-: I was just wondering how to painlessly come by some intuition on this score... -- Mark

1 0