July 2001 - Haskell-Cafe

Singular Type Constructor
by Ashley Yakeley 20 Aug '01

20 Aug '01

Consider: -- data T a = T -- Is there anything in the Prelude or a standard library that looks like this? Should there be? What should it be called? 'Singleton'? 'Reified'? 'T'? I looked but couldn't find anything. Such a simple type constructor is in fact very useful when you need to pass types around to disambiguate class instances. For instance: -- class HasTypeName t where getTypeName :: T t -> String instance HasTypeName Int where getTypeName T = "Int" instance HasTypeName () where getTypeName T = "()" intName = getTypeName (T :: T Int) -- -- Ashley Yakeley, Seattle WA

3 2

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

Re: Novice Haskell query
by Ashley Yakeley 01 Aug '01

01 Aug '01

At 2001-07-31 14:17, Mark Carroll wrote: >Now, "show x" will work, and "show y" won't. How can I write things so >that I can show both x and y? I don't seem to be able to write, say, > > instance Show a => Show (Tree a) where > show (Branch datum left right) = > show left ++ " <- " ++ show datum ++ " -> " ++ show right > > instance Show (Tree a) where > show Leaf = "*" These two instances overlap. You want one instance, with both Branch and Leaf alternatives in the 'show' function. >or, perhaps, > > instance Show (Tree a) where > Show a => show (Branch datum left right) = > show left ++ " <- " ++ show datum ++ " -> " ++ show right > show Leaf = "*" Close, but you're making a promise (that 'Tree a' is Show for _any_ 'a') that you can't fulfill. Attempting to restrict the type of 'a' while defining the function is bogus, the 'a' symbol simply isn't in scope at that point. Clearly the type 'Tree a' is only Show if 'a' is. It's irrelevant that the 'Leaf' part of the definition doesn't need 'a' to be Show: the 'Branch' part does, so the type has to be restricted to 'Show a => Tree a' if it is going to be Show. So you want this: instance Show a => Show (Tree a) where ... -- Ashley Yakeley, Seattle WA

2 1

Novice Haskell query
by Mark Carroll 31 Jul '01

31 Jul '01

Let's say I have: data Tree a = Branch a (Tree a) (Tree a) | Leaf instance Show a => Show (Tree a) where show (Branch datum left right) = show left ++ " <- " ++ show datum ++ " -> " ++ show right show Leaf = "*" y = Leaf x = (Branch 3 Leaf Leaf) Now, "show x" will work, and "show y" won't. How can I write things so that I can show both x and y? I don't seem to be able to write, say, instance Show a => Show (Tree a) where show (Branch datum left right) = show left ++ " <- " ++ show datum ++ " -> " ++ show right instance Show (Tree a) where show Leaf = "*" or, perhaps, instance Show (Tree a) where Show a => show (Branch datum left right) = show left ++ " <- " ++ show datum ++ " -> " ++ show right show Leaf = "*" ...or whatever other things come to mind. -- Mark

2 1

RE: Singular Type Constructor
by Ashley Yakeley 31 Jul '01

31 Jul '01

At 2001-07-31 01:55, Simon Marlow wrote: >The type T is undoubtedly useful, but I think the example you give isn't >a good one. It works perfectly well without the T data type: > > class HasTypeName t where > getTypeName :: t -> String Perhaps. I think your use of 'undefined' is a bit ugly. The type 't -> String' suggests you need a value of type 't' to get a name for 't', which is not what I want to imply. 'undefined :: t' is intended to represent the type 't', which is not something intuitively "undefined". -- Ashley Yakeley, Seattle WA

1 0

RE: Singular Type Constructor
by Simon Marlow 31 Jul '01

31 Jul '01

> Consider: > > -- > data T a = T > -- > > Is there anything in the Prelude or a standard library that > looks like > this? Should there be? What should it be called? 'Singleton'? > 'Reified'? > 'T'? > > I looked but couldn't find anything. Such a simple type > constructor is in > fact very useful when you need to pass types around to > disambiguate class > instances. For instance: > > -- > class HasTypeName t where > getTypeName :: T t -> String > > instance HasTypeName Int where > getTypeName T = "Int" > > instance HasTypeName () where > getTypeName T = "()" > > intName = getTypeName (T :: T Int) The type T is undoubtedly useful, but I think the example you give isn't a good one. It works perfectly well without the T data type: class HasTypeName t where getTypeName :: t -> String instance HasTypeName Int where getTypeName _ = "Int" instance HasTypeName () where getTypeName _ = "()" intName = getTypeName (undefined :: Int) (this is just like the Typeable class in the Dynamic library, BTW) Cheers, Simon

1 0

Interactive shell
by Mark Carroll 30 Jul '01

30 Jul '01

People may recall that I was looking for an interactive Haskell shell at which I could type things and experiment, as you'd expect to get with any Lisp environment. At people's suggestion I installed GHCi and got it working, but I seem quite limited in what I can type at it. For instance, it balks at my various attempts to define a new algebraic type along the lines of "data Foo = Bar | Baz", for use in future intercourse. Is there some magical incantation I'm missing, or does it really not let me do that, and if not then does anything else? Thanks. -- Mark

1 0

RE: computer language shootout
by Dejan Jelovic 30 Jul '01

30 Jul '01

Josef Svenningsson wrote: > Having said that I must also say that I think that ghc's I/O is fast > *enough*. It's just that it doesn't compare very well with other > languages. I've never had problems caused by slow I/O in Haskell. This is the favorite argument of proponents of slow languages ;). But as long as people wait for their computers (to boot up, to run a program, to compile a program, to do a computation, to...) speed is going to be a virtue. Dejan http://www.jelovic.com

1 0

RE: computer language shootout
by Simon Marlow 30 Jul '01

30 Jul '01

> So am I. Have any haskell-performance gurus looked at any of > the code? Many of > the slowest entries are written in a very elegant, high-level > style that is > probably also relatively slow. I've looked at a few. The most common factor in the worst performers seems to be the performance of String-related operations. I tried converting a few to use PackedStrings but that didn't help much. I suspect our PackedString implementation could do with some tuning, and we could gain considerable benefit from having an hGetLinePS function (like hGetLine but gets a PackedString). Cheers, Simon

3 2

RE: computer language shootout
by Simon Marlow 30 Jul '01

30 Jul '01

> On Mon, 30 Jul 2001, Simon Marlow wrote: > > > I've looked at a few. The most common factor in the worst > performers > > seems to be the performance of String-related operations. I tried > > converting a few to use PackedStrings but that didn't help much. I > > suspect our PackedString implementation could do with some > tuning, and > > we could gain considerable benefit from having an > hGetLinePS function > > (like hGetLine but gets a PackedString). > > > Well, I think the common factor is I/O. The lazy I/O seems to > be a real > bottleneck here. Trying to improve that would gain even more, I think. > I'm saying this because I did quite a bit of fiddling with some of the > examples (including trying PackedStrings). The conclusion I drew from > doing this was that the I/O performance was the problem. Agreed - I/O is indeed a bottleneck, but I believe it's the strings-as-lists-of-characters aspect of I/O rather than the lazy aspect that's the killer. Enclosed is a version of the spell-checker program that is about a factor of 3 faster than the one that Doug currently has; it uses PackedStrings and a home-grown hash table. The only down side is that it reads the entire input into a big PackedString before producing anything, and profiling suggests that it spends about half its time splitting the big string into lines. I think if I hack up an hGetLinePS I might be able to get another factor of 2 out of it. Cheers, Simon

1 0