- Libraries - Haskell.org

RE: DData
by Simon Marlow 17 May '04

17 May '04

On 17 May 2004 13:46, Daan Leijen wrote: > I just wondered: is Data.FiniteMap strict in its elements? No it isn't. Removing the strictness annotation on the element type for DData.Map might increase performance too. > ps. Simon: The cvs source browse link on the GHC page seems broken, > so I couldn't look it up myself... Yes I know, the cvs.haskell.org admins are working on it. Cheers, Simon

1 0

RE: DData
by Simon Marlow 17 May '04

17 May '04

On 14 May 2004 18:17, Christian Maeder wrote: > Simon Marlow wrote: >>> "FiniteMap Int a" performs better than "Map Int a", but not as good >>> as "IntMap a", but the differences are unimportant for us. >> >> How much better? I'm not keen to import something that's going to >> degrade performance of existing code noticeably. > > Ok, I'll send you numbers (later). Are you going to reimplement > FiniteMap via DData.Map (or how could existing code suffer)? Sorry, I should have been clearer. I mean that programmers who migrate code to Data.Map will see a performance loss; that's something I'd like to avoid. Furthermore, there shouldn't be any need for Map to be slower than FiniteMap. A 10% loss in performance for FiniteMap isn't going to show up in many profiles, but it'll cause a performance degradation in *lots* of applications, so fixing it is worthwhile. Indeed, we should take the opportunity to see if the code can be tuned any further and improve on the performance of FiniteMap. Cheers, Simon

1 0

RE: How lazy is DData.Seq?
by Simon Marlow 10 May '04

10 May '04

On 10 May 2004 00:02, JP Bernardy wrote: >> What do you mean with this? Do you mean: "I think >> *I* was mistaken [...]"? > > Huh, yes. > >>> The current version behaves ok for sequences mainly constructed with >>> fromList, cons or snoc; a sequence made up of 'append' is strict. >> >> Would it be possible to change this behavior? > > Sure. > I attach the modified version, for reference. Ross's point about requiring append to be strict in order to guarantee O(n) toList is a good one. In fact, the current implementation isn't quite correct: either fromList should be strict, or append should check for an empty Many constructor. Cheers, Simon

4 4

Re: How lazy is DData.Seq?
by Wolfgang Jeltsch 10 May '04

10 May '04

Am Samstag, 8. Mai 2004 18:37 schrieben Sie: > --- Wolfgang Jeltsch <wolfgang(a)jeltsch.net> wrote: > > Hello, > > > > I would suspect that in DData.Seq the result of > > head (singleton 'a' `append` undefined) > > is 'a' but instead it is _|_. Why is this the case? > > I have the invariant that sublists are not empty. > There is, for example: > > append as None = as Is this necessary/desirable? I have an application where I think that it can be important for efficiency that the above expression evaluates to 'a'. So I would like it to not result in _|_. > Cheers, > JP. Wolfgang

4 11

How lazy is DData.Seq?
by Wolfgang Jeltsch 08 May '04

08 May '04

Hello, I would suspect that in DData.Seq the result of head (singleton 'a' `append` undefined) is 'a' but instead it is _|_. Why is this the case? Wolfgang

1 0

RE: Extracting fptools subtree for standalone installation?
by Simon Marlow 07 May '04

07 May '04

On 07 May 2004 16:06, Martin Erwig wrote: > is there a simple method to extract a subtree of > the fptools/libraries hierarchy together with > a Makefile to create a working installation > script for that subtree? > > I would like to extract the current version of > the FGL together with a Makefile that allows > the independent installation of the FGL. The > Makefile in the hierarchical library tree > seems to be heavily dependent on many other > files. The answer is "not yet". But we're making progress in that direction with the Haskell Library Infrastructure. Cheers, Simon

2 1

Extracting fptools subtree for standalone installation?
by Martin Erwig 07 May '04

07 May '04

Hi, is there a simple method to extract a subtree of the fptools/libraries hierarchy together with a Makefile to create a working installation script for that subtree? I would like to extract the current version of the FGL together with a Makefile that allows the independent installation of the FGL. The Makefile in the hierarchical library tree seems to be heavily dependent on many other files. Any help would be greatly appreciated. Thanks, Martin

1 0

RE: Instances for data types
by Simon Peyton-Jones 06 May '04

06 May '04

Haskell's inability to hide instance declarations is an oft-discussed problem. The designers of the language went to some trouble to arrange that equality on (say) URIs could not mean one thing in one place and another thing in another. Lacking that, it matters exactly where in the program the type inference engine resolves the overloading, something that in principle the Haskell type system leaves open. In short, the implicit-ness of instances conflicts in both practical ways (e.g. what do you call them), and theoretical ways, with the desire to localise them. Implicit parameters were developed largely in response to this difficulty; they make instances explicit. My advice would be: use explicit function inside libraries, if you don't want to expose the functions to the library client. Your second suggestion, a more elaborate scheme for default methods, has less by way of theoretical difficulties, I think, though I have never seen the details worked out. As usual, there's the question of whether the benefit in expressiveness is worth the cost in language complexity. And it makes it harder to answer the question "what code is executed by this call to foo", because I have to look down the chain of overlapping instance declarations -- if I can find them. Nevertheless, it may be that the practical utility is so great (at least for some programs) that it'd be worth working out the details. Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of S. Alexander | Jacobson | Sent: 30 April 2004 20:09 | To: Simon Marlow | Cc: libraries | Subject: RE: Instances for data types | | Alternatively, since you can't control the export | of instance declarations, is there a way to | declare a deriving separate from the definition of | a type? | | For example, Network.URI should not have an | Eq instance because some applications may | legitimately want to define URI equivalence | differently (e.g. case sensitivity). OTOH, there | are lots of times when the default behavior is | just fine and having to define readsPrec/showsPrec | manually is just a PITA. | | If there isn't already a way to do this | how about this strawman syntax: | | instance Eq URI default | | And (going slightly OT) as long we are are | simplifying instance declarations, how about | making it easier to specialize them? For example | in my DBMS code, I had stuff like this: | | instance Property BasicProp String | where | emptyProp x = bpEmpty | deleteRecordId = bpDeleteRecordId | insertRecordId = bpInsertRecordId | | instance Property BasicProp Integer | where | emptyProp x = bpEmpty | deleteRecordId = bpDeleteRecordId | insertRecordId = bpInsertRecordId | | instance Property BasicProp Double | where | emptyProp x = bpEmpty | deleteRecordId = bpDeleteRecordId | insertRecordId = bpInsertRecordId | | The actually list of functions is actually much | longer. For some types, I may want to specialize | some of these functions, but for most of them, the | default behavior is good enough. I'd like to | declare default implementations e.g. | | instance Property BasicProp a where | | And then only if I have a more interesting type | do: | | instance Property BasicProp CoolType where | | And only define the functions that are different | from the default behavior for (Propry BasicProp a) | | -Alex- | | _________________________________________________________________ | S. Alexander Jacobson mailto:me@alexjacobson.com | tel:917-770-6565 http://alexjacobson.com | | | On Fri, 30 Apr 2004, Simon Marlow wrote: | | > On 27 April 2004 20:58, Sven Panne wrote: | > | > > Playing around with System.Posix.Terminal, I realized that there are | > > no Read, Show, Eq, Enum, ... instances for the data types defined | > > there (TerminalState, TerminalMode, ...). This is not a very | > > difficult problem to solve in one's | > > own program, but it's not very handy, either. | > | > By all means go ahead and add these instances. | > | > > This raises a general | > > question: What instances should be defined in the standard libraries | > > for types like | > > this? A general policy would be a good thing. IMHO, at least Read, | > > Show, Typeable and Eq could be expected, having Ord, Enum and | > > Bounded, too, would be nice. | > | > Good point. I've been meaning to create a separate document so we have | > somewhere to collect general library policies like this. It's on my | > whiteboard... | > | > Cheers, | > Simon | > _______________________________________________ | > Libraries mailing list | > Libraries(a)haskell.org | > http://www.haskell.org/mailman/listinfo/libraries | > | | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

3 2

Re: UTF-8 encode/decode libraries.
by George Russell 04 May '04

04 May '04

Sven Panne wrote: > Hmmm, "String -> [Word8]" would be nicer... My UTF8 encoder is toUTF8 :: String -> String but an obvious alternative would be toUTF8 :: Enum codedChar => String -> [codedChar] and I could implement this quite easily, by globally-exchanging chr with toEnum. It would then be appropriate to SPECIALIZE to types String -> String and String -> [Word8], satisfying both the purists and those who actually want to write the output to a file. > ... and here: "[Word8] -> String" or "[Word8] -> Maybe String and my UTF8 decoder has type fromUTF8WE :: Monad m => String -> m String Errors are reported by "fail". If for example you import Control.Monad.Error that means you have a function returning either an error message or the converted string fromUTF8WE :: String -> Either String String Of course for Word8, you would change the type of the decoder to fromUTF8WE :: (Monad m,Enum codedChar) => [codedChar] -> m String Incidentally I am *hoping* I shall be able to say that my UTF8 code is LGPL but you know what University administrators are like ...

2 2

Re: Instances for data types
by George Russell 04 May '04

04 May '04

Sven Panne wrote: > Playing around with System.Posix.Terminal, I realized that there are no Read, > Show, Eq, Enum, ... instances for the data types defined there (TerminalState, > TerminalMode, ...). This is not a very difficult problem to solve in one's > own program, but it's not very handy, either. Two other cases where I have to roll my own Typeable instance are Data.FiniteMap.FiniteMap and HaXml's Element type (and friends) This is all very well but will cause problems if someone else imports one of my packages and another one which defines conflicting instances of Typeable. Or if later the standard libraries or some library I use change to implement their own Typeable instance.

1 0