- Haskell-Cafe - Haskell.org

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

Re: Singular Type Constructor
by Ashley Yakeley 13 Aug '01

13 Aug '01

At 2001-08-12 11:26, Levent Erkok wrote: >How about using overlapping instances? Add: > > instance Eq a where > _ == _ = True > >to your program: if there isn't a ``better'' instance, it'll use this one. >Such an instance declaration is inherently dangerous to have around, but >might help your particular situation. How do Hugs and GHC calculate "better" instances in this case? I make a distinction between "appears to overlap" and "actually overlaps": the first is what the compilers detect: I only switch off this checking if I have instances that "appear to" overlap but don't "actually" overlap e.g.: -- instance MyClass Bool instance (Num a) => MyClass a -- ...which don't "actually" overlap provided I don't have "instance Num Bool" anywhere. Patching GHC so that it detects instances that "actually" overlap instead of "appear to" overlap is left as an exercise for the reader... -- Ashley Yakeley, Seattle WA

1 0

Re: Singular Type Constructor
by Ashley Yakeley 13 Aug '01

13 Aug '01

At 2001-08-12 16:55, Hal Daume III wrote: >but supposing you wanted a sort of relaxed equality >wherein, if you chould check for equality on the second element, you >would, otherwise you would just check the first element. i would want >to say something like: > >instance (Eq a, Not (Eq b)) => Eq (MyPair a b) where > (MyPair a _) == (MyPair a' _) = a == a' > >But from what you're telling me there's no way to have both of these >instances, correct? There's no 'Not', so you can't have the second one. If you had a 'Not', it would allow some ugliness: -- data PQ = P | Q equalPQ = (MyPair 'a' P) == (MyPair 'a' Q) -- Note that equalPQ is True. But if someone else introduces an "instance Eq PQ" in another module, equalPQ could become False. I think this sort of thing is supposed to be prohibited: code that is correct cannot change its meaning due to modules it does not depend on. -- Ashley Yakeley, Seattle WA

1 0

Re: Singular Type Constructor
by Ashley Yakeley 12 Aug '01

12 Aug '01

At 2001-08-08 23:00, Hal Daume III wrote: >however, if you try something like: > >instance TypeName a where > typeName T = "??" > >it will complain because there must be one non-type variable in the >instance head. Try using "-fglasgow-exts -fallow-undecidable-instances". >moreover, even if this restriction is removed (anyone know what it's >there for?), there will be the problem of overlapping instances with, >say TypeName Char and TypeName a. Correct. And the instances really would overlap, it wouldn't just be GHC complaining that they _might_ overlap but not being able to figure out that they don't. >so i'm wondering if there is a way to specify something like: > >instance Not (TypeName a) => TypeName a where ... No. >that is, this type variable a matches with all a such that a is not an >instance of TypeName... If there were such a thing, it would be incoherent to say: "if a is not TypeName, then a is TypeName with this typeName". >there are other places where i would find such a thing >useful/interesting beyond this TypeName foo, but this seemed like a >good, simple way to explain it... Can you think of a use for it that isn't semantically incoherent? -- Ashley Yakeley, Seattle WA

3 2

Re: from micro-rant to macro-feature
by Malcolm Wallace 10 Aug '01

10 Aug '01

Gary Memovich writes: > Now if we only expanded the flexibility of 'newtype' declarations so > that we could include a conversion function to the underlying type, > and expand the type checking system to automatically add calls to such > a function when needed, and change the syntax so that the constructor > for 'newtype' wasn't limited to identifiers, and change the syntax > some more so that new 'prefix' declarations were available to adjust > the precedence levels of these new constructors, it would be a piece > of cake :-) As a point of interest, nhc98 extends very slightly the Haskell syntax for declaring infix and precedence to permit user-defined prefix operators. For instance: infixl 7 * infixl 6 + prefix negate 6 - The extended syntax is gendecl -> vars '::' [context '=>'] type | fixity [digit] ops | 'prefix' varid [digit] op | and the obvious semantics is that the unary operator is treated as if it were really the varid. Do feel free to play with it. (Note however that this kind of declaration does not change the pattern-matching language for constants - negative integer patterns are just fiddled by the compiler.) Regards, Malcolm

1 0