- Haskell-Cafe - Haskell.org

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

ST Questions
by Ashley Yakeley 28 Jul '01

28 Jul '01

Two questions on module ST: <http://www.haskell.org/ghc/docs/latest/set/sec-st.html> 1. What's the 's' parameter for? 2. Do STRefs get garbage-collected once they're forgotten? For instance, if I have an action that calls newSTRef, uses the ref, and then forgets it, and I run the action repeatedly, am I at risk of running out of memory? -- Ashley Yakeley, Seattle WA

2 1

getCh
by Michael Ackerman 28 Jul '01

28 Jul '01

Hello, In Bird's book, p 332, he writes of a "Haskell primitive function, getCh, which is similar to getChar except that the character is not echoed". I can find no reference to getCh in the Report or the docs for the libraries. How can this be defined? Thanks. - Michael Ackerman

1 0

Re: Simple compiler question
by Wolfgang Lux 26 Jul '01

26 Jul '01

Mark Carroll wrote > Do any of the decent Haskell compilers allow you to just type function > definitions at an interpreter prompt and use them in subsequent > interactions, as you'd expect from a Lisp environment? I don't know whether you consider hbi (the interactive version of hbc) a decent compiler, but it supports entering definitions as well: > let { f x = x + x }; f :: (Prelude.Num a) => a -> a > f 3; 6 Wolfgang -- Wolfgang Lux Phone: +49-251-83-38263 Institut fuer Wirtschaftinformatik FAX: +49-251-83-38259 Universitaet Muenster Email: wlux(a)uni-muenster.de

1 0

Simple compiler question
by Mark Carroll 25 Jul '01

25 Jul '01

Do any of the decent Haskell compilers allow you to just type function definitions at an interpreter prompt and use them in subsequent interactions, as you'd expect from a Lisp environment? I'm fed up of editing a tiny file separately and typing :reload each time, etc. Surely I'm missing something obvious? -- Mark

3 3