- Haskell-Cafe - Haskell.org

Re: newbie conceptual question [from haskell list]
by Steinitz, Dominic J 01 Aug '01

01 Aug '01

I don't know about functional dependencies but using an existential type turned out to be very useful in writing an LDAP protocol handler. The protocol is specified at an abstract level using ASN.1 and could, in theory, be encoded using any set of encoding rules. It happens to use the Basic Encoding Rules. We used an existential type to "encode" the protocol at an abstract level and the encoding rules take this type and produce a concrete representation ready to send over a transport mechanism. Thus we get a good separation between the abstract protocol and the concrete encoding. So the next time we implement a protocol handler we can re-use the encoding code or we could encode LDAP with a different set of encoding rules without having to touch the LDAP code itself. We are presenting a paper which includes this at the Scottish Functional Programming workshop. Dominic. hdaume(a)ISI.EDU on 31/07/2001 22:29:00 To: franka cc: haskell-cafe bcc: Dominic Steinitz Subject: Re: newbie conceptual question [from haskell list] Hi, Frank Atanassow wrote: > D. Tweed wrote: > > I've never written a Haskell program using functional dependencies, or > > existential classes, ... > > I find them indispensible, and I know for a fact that I am not the only one > around our office who feels that way. Though, the people around here > (Utrecht's software technology group) are not exactly typical programmers... > :) I've been recently experimenting quite a bit with existential classes and somewhat less with functional dependencies, primarily to help my understanding of the concepts. However, I've yet to be able to think of an appropriate place to use them in the "real world". That is, in something more than a toy thought-experiment. Could you give some examples of what you are using them for? -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0

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

01 Aug '01

At 2001-07-30 19:08, I wrote: >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'? In the end I called it 'Type'. Perhaps something like it should be in the Prelude... See <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jvm-bridge/source/Haskell/T ype.hs?rev=HEAD&content-type=text/vnd.viewcvs-markup>. -- Ashley Yakeley, Seattle WA

1 0

Novice Haskell query
by Mark Carroll 01 Aug '01

01 Aug '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 01 Aug '01

01 Aug '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 31 Jul '01

31 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 31 Jul '01

31 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 31 Jul '01

31 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 31 Jul '01

31 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