May 2004 - Libraries - Haskell.org

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

RE: Instances for data types
by Simon Marlow 01 May '04

01 May '04

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

4 3