April 2004 - Libraries

Subprocesses (was: [ANNOUNCE] shell-haskell 1.0.0)
by Simon Marlow 08 Jul '04

08 Jul '04

Libraries people, There are currently two ways to create and communicate with external processes: - System.Cmd.system (very basic, doesn't give you access to the process's output but you can use shell primitives to redirect its input/output). - Posix.runProcess (can specify Handles for the process's input/output, but it doesn't create pipes so you can't actually communicate with the subprocess using these Handles.). - POpen.popen (can specify an input String, and gives you lazy output Strings. No interactive communication is possible.) Ok, *three* ways. System.Cmd.system, Posix.runProcess, POpen.popen, and shell-haskell. Er. *Four* ways. David Sankel's shell-haskell creates pipes for stdin/stdout/stderr, and lets you communicate interactively with the sub-process via Handles. It could do with a way to specify the environment and working directory of the sub-process (ala POpen and runProcess), but apart from that it seems to be the most flexible of the four. It could be simplified slightly by using one Handle rather than two for stdin/stdout. We should think about what functionality we want to provide in the core libraries. My preference would be to go for a full version with three pipes (like shell-haskell) and perhaps one or two more specialised versions covering common cases (I don't know what these should be, though). What do people think? Cheers, Simon -----Original Message----- From: haskell-admin(a)haskell.org [mailto:haskell-admin@haskell.org] On Behalf Of David Sankel Sent: 06 May 2003 03:06 To: haskell(a)haskell.org Subject: [ANNOUNCE] shell-haskell 1.0.0 =================== shell-haskell 1.0.0 =================== shell-haskell provides utilities to communicate with other process's via Haskell code. This library can be used for something as simple as getting the output of another program or as complex as interacting with an interpreter. see http://www.electronconsulting.com/shell-haskell for details. David J. Sankel _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

5 10

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

Instances for data types
by Sven Panne 27 Apr '04

27 Apr '04

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. 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. Any opinions? Cheers, S.

1 0

request: MultiMap
by haskell＠alias.spaceandtime.org 26 Apr '04

26 Apr '04

Hello, I would like to request that multimap be added to the data library. As a C++ programmer (and a complete Haskell newbie), I find myself frequently using std::multimap from the STL. However, as I'm moving my programs to Haskell, I'm having to do hacks such as a maps of keys to sets of values. I noticed that DData is under consideration, which has a multiset, so why not a multimap? I would implement it myself, but as I said, I am just learning FP. Thanks, James

2 2

Re: UTF-8 encode/decode libraries.
by Sven Panne 26 Apr '04

26 Apr '04

Duncan Coutts wrote: > On Mon, 2004-04-26 at 18:49, David Brown wrote: [...] > toUTF :: String -> String Hmmm, "String -> [Word8]" would be nicer... > fromUTF :: String -> String ... and here: "[Word8] -> String" or "[Word8] -> Maybe String". Furthermore, UTF-8 is not restricted to a maximum of 3 bytes per character, here an excerpt from "man utf8" on my SuSE Linux: * UTF-8 encoded UCS characters may be up to six bytes long, however the Unicode standard specifies no characters above 0x10ffff, so Unicode characters can only be up to four bytes long in UTF-8. IIRC we discussed encoders/decoders quite some time ago on the libraries mailing list, but nothing really happened, which is a pity. We should strive for something more general than UTF-8 <-> UCS/Unicode, there are quite a few more widely used encodings, e.g. GSM 03.38, etc. Any takers? Cheers, S.

2 1

Network.URI - RFC2396bis nearing last call
by Graham Klyne 23 Apr '04

23 Apr '04

The revision of RFC2396 is nearing last call (for IETF "draft standard" status), and after some discussion of details I've made some changes to my (re)implementation of Network.URI (these affect some abnormal cases when calculating a URI from base + relative URIs, where the relative URI uses more '..' components than the base URI has path components). I've also prepared a revised version of the test module that is driven by an external RDF/N3 description of the, constructing the HUnit test cases "on the fly", then executing them. (It's a bit slow, but that's because my RDF graph API is still worse than unoptimized.) More info about the test case descriptions can be found via: http://www.ninebynine.org/Software/HaskellUtils/Network/URITestDescriptions… A copy of the the software itself is here: http://www.ninebynine.org/Software/HaskellUtils/Network/ http://www.ninebynine.org/Software/HaskellUtils/Network/URI.hs (currently: $Id: URI.hs,v 1.11 2004/04/21 16:58:34 graham Exp $) I am proposing to replace the existing network.URI module in the library CVS, but I've been holding off until the revised URI spec is stabilized, and also to get some sense of how much disruption would be caused by the change of representation of the URI type. I have found that some Network.HTTP modules did need to be changed to accommodate the new structure (my modified sources are in the same directory as URI.hs, see above). Unless I hear any squeals, I'll plan to actually update the URI module once the RFC2396 revision goes to last call, and it seems clear that there are no major objections to the changes. #g -- ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

RE: #ifdef considered harmful (was: DData)
by Simon Marlow 20 Apr '04

20 Apr '04

On 20 April 2004 11:54, Alastair Reid wrote: >> If FastInt is Int# in GHC, and we want it to be portable, then we >> have to introduce unlifted types & kinds in Hugs and nhc98 too. > > Yes, I was proposing that Hugs and NHC be extended with unlifted > types of some form. I think this is only worth doing if someone can work out whether polymorphic kinds can be supported, perhaps in a restricted way, so that we can define instances of classes for unlifted types. There's a good open research question! Cheers, Simon

1 0

RE: #ifdef considered harmful (was: DData)
by Simon Marlow 20 Apr '04

20 Apr '04

Robert Will writes: > I think what Haskellers (and others) can do in most cases is > to factor out > platform dependent parts to mini-modules which have different > implementations but the same interface. The version of such > a module is > choosen by the path it resides in during the build process. (Simplest > case: the -i option of the compiler.) I have to say, I dislike this approach to conditional compilation. - it puts the conditional in the build system rather than the source code, which means you have to look in the build system to find out what the code means. - it means if I want to ask questions like "hmm, how does this differ from the Windows version?" I have to go find the windows version of the file. - the interface to the module is duplicated, and nothing is checking that all your implementations have the same interface. OTOH, if you want to see a good example of #ifdefs gone wrong, take a look at GHC's native code generator. #ifdef can indeed be misused; that's not a reason to throw it out altogether. Cheers, Simon

8 8

Re: sequences
by Robert Will 20 Apr '04

20 Apr '04

Apologies, I sent this to the wrong list. It should go to Libraries... Robert ---------- Forwarded message ---------- hi Ross and others, On Wed, 7 Apr 2004, Robert Will wrote: > > On Mon, 5 Apr 2004 ross(a)soi.city.ac.uk wrote: > > > To have something concrete to discuss, I've placed a structure based on > > Edison at > > docs: http://www.soi.city.ac.uk/~ross/seq/ > > code: http://www.soi.city.ac.uk/~ross/seq.tar.gz Really, since you have read the comparison of my Abstract Collections with Edison, you should have said one word, why you choose Edison as a basis and not mine. Well, I gues the reason is just that you don't want MPTC and that you're perhaps afraid of all my new terminology while Edisons names sound so familiar. So here is a short argument in favour of my choices: 1. The class "OperationalSequence" in the Abstract Collections is an MPTC that makes no restrictions on the element type. I dubbed it "Operational", because without an equality over Sequences we can't give executable algebraic specifications. It uses MPTC for a debatable reason: to be part of the framework of Abstract Collections. (The source file explains why we can't mix SPTC and MPTC code.) But is that really so bad? MPTC work on all major compilers and no-one doubts they will be in a future standard. Furthermore, since it uses Constructor Classes (just like Edison) there are no ambiguity problems that would involve FunDeps! 2. Also the names are choosen not to be compatible with the past, but to be combatible with the future: the names of the Sequence operations fit well with those of all other Collections. Many names are shared and have the same semantics on all Collections. > PS: Dessy also started with (list-compatible) Sequences and than added the > rest. We should certainly not make that detour on the large scale. with "list-compatible" I mean starting with class members (cons head tail foldr foldl...) and then add many more. Really one should be looking for the common base of all sequence implementations and what's more all sequence applications. The absurdness of the "list-compatible" approach shows in the ridiculous default running times for 'cons' O(1) and 'snoc' O(n), really what's the big difference between those operations? The names alone are a nightmare: (cons snoc init tail head last left right) (as in lview, rview) and many functions that only work from the front. How many different names should we have for the front (with the first element) and the back (with the last element)? My proposal shows that those four terms (first last front back) suffice to name all useful functions on lists. Surely the naming approach taken for my Abstract Collections is no fundamental breaking with conventions: all the names and operators are either tradition in Haskell or tradition in Scheme or some consistent extension of this (e.g. (<:) and (>:) for 'add_first' and 'add_last'). Clearly my new names are easier to learn for novices, but I also claim that learning the whole library (i.e. the "compatible" functions and the new ones) is easier for the Abstract Collections than for Edison. Just because the names are more consistent, and still many names are like in standard Haskell. So I'd suggest, that a standard Sequence class should be based on the Abstract Collections. (And by the way, why not also think about Sets and Maps, you can use them now: "import Prelude (); import Collections" is not so hard to write!) By the way I think that the documentation for the Sequence instances in Ross' proposal is too redundant. The only thing we should need is a specification of the performance and of additional operations. I would propose the following time bounds: Defaults for Sequences: O(logN) for all operations, except O(1) for "atomic queries" (is_empty, first, last, size (or length)) This is the simplest to remember and a "democratic" implementation will just have those bounds. (And balanced tree does, Dessy has five of them.) Next thing needed are Deques: O(1) for (empty single <: >: first last but_first but_last is_empty) O(N) for the rest (JoinLists are like that with additional O(1) (++), so they're perhaps better called 'AppendableDeques'. Likewise CatenableLists are really AppendableStacks.) Write-only Sequences: (OrdList) O(1) for (empty single <: >: ++) O(N) for the rest One-side flexible Arrays or Random Access lists: are another very "algorithmic" structure, which support efficient 'update', a function that my Sequences don't even specify. This reminds me, that I haven't really seen any applications of Sequence data structures and that I decided anyway to get some examples before fixing the details of the class. By the way, there are already some examples of Maps and Sets at work: http://www.stud.tu-ilmenau.de/~robertw/dessy/fun/examples/ The only examples for Sequences is Okasakis Tree Enumeration using Deques and that doesn't look nice without views :-( Robert _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

3 6

RE: #ifdef considered harmful (was: DData)
by Simon Marlow 20 Apr '04

20 Apr '04

On 19 April 2004 15:06, Jan-Willem Maessen - Sun Labs East wrote: > The real problem, of course, isn't the data structures at all---GHC > does an excellent job with these (though the "UNPACK" pragma is a > revelation). The actual problem is function arguments. GHC can't do > worker-wrapper unless a function is strict. Often we end up with > something like this: I'm not sure I'd characterise that as "the real problem" - in a lot of the cases I've come across, the UNPACK pragma has been exactly what I needed. In a few critical functions where I found that arguments weren't strict enough, I've had to add seqs to help the compiler. > data Tree a = Branch !Int a (Tree a) (Tree a) > > lookfor :: Int -> Tree a -> Maybe a > lookfor Leaf key = Nothing > lookfor (Branch k v l r) key > | key==k = Just v > | key < k = lookfor l key > | otherwise = lookfor r key > > Here we don't use "key" in the first clause, so GHC isn't allowed to > unbox. Most of the uses of Int# that I've seen in library code have > been workarounds to this problem. In this case, being able to write > > lookfor :: FastInt -> Tree a -> Maybe a > > might give us some hope of getting the compiler to generate the > unboxed code we might want, yet still afford us the opportunity to > use boxed types if that's not possible. > > We could do this today without changing the language or the compilers. > The library would have to be carefully coded... I'm not clear on exactly what the FastInt type means. I think I asked Alastair the same question recently - is FastInt an unlifted type? Can I store it in a polymorphic data structure or pass it to a polymorphic function? If FastInt is Int# in GHC, and we want it to be portable, then we have to introduce unlifted types & kinds in Hugs and nhc98 too. Declaring instances of classes for unlifted types isn't possible, so you can't have instane Num Int#, for example. I think you need polymorphic kinds for that. Cheers, Simon

2 1

Re: #ifdef considered harmful (was: DData)
by Jan-Willem Maessen - Sun Labs East 20 Apr '04

20 Apr '04

Jan-Willem Maessen - Sun Labs East wrote: Simon Marlow wrote: >> Hmm, wouldn't it be nice to have a "FastInt" library which re-bound >> the appropriate types and functions? Haskell libraries are >> chock-a-block with instances of "#ifdef __GHC__" which define things >> in terms of Int# instead of Int. We could simplify all those >> libraries if we did it just once, in one place. >> >> The problem, of course, is that the naive non-GHC user could write a >> library which used "FastInt" polymorphically, and write code that >> wasn't portable to GHC. I don't think there's an easy, magic >> solution there. Perhaps such a library would be named >> FastIntWhichIPromiseToTestWithGHC. > > > > Most of the time it's unnecessary to use an explicit Int#. If your Int > is in a data structure, you can use > {-# UNPACK #-} !Int > > which is portable, and compiles to an unboxed Int in GHC >= 6.2. The real problem, of course, isn't the data structures at all---GHC does an excellent job with these (though the "UNPACK" pragma is a revelation). The actual problem is function arguments. GHC can't do worker-wrapper unless a function is strict. Often we end up with something like this: data Tree a = Branch !Int a (Tree a) (Tree a) lookfor :: Int -> Tree a -> Maybe a lookfor Leaf key = Nothing lookfor (Branch k v l r) key | key==k = Just v | key < k = lookfor l key | otherwise = lookfor r key Here we don't use "key" in the first clause, so GHC isn't allowed to unbox. Most of the uses of Int# that I've seen in library code have been workarounds to this problem. In this case, being able to write lookfor :: FastInt -> Tree a -> Maybe a might give us some hope of getting the compiler to generate the unboxed code we might want, yet still afford us the opportunity to use boxed types if that's not possible. We could do this today without changing the language or the compilers. The library would have to be carefully coded... -Jan-Willem Maessen

3 3

RE: aha! file descriptor leak in 'readFile'
by Simon Marlow 20 Apr '04

20 Apr '04

On 19 April 2004 08:32, John Meacham wrote: > I have finally tracked down a test case which results in the file > descriptor leak which has plauged one of my programs since its birth. > > this code: > sequence (replicate 100 $ handle (\_ -> return "") ( readFile ".")) > > will leak 100 file descriptors, apparently, after a > Fail: .: openFile: inappropriate type (is a directory) > exception from readFile, the file descriptor will not be closed, and > instead be left open til the end o' time. > > it took me a long time to find because I thought the bug was in > the listing of my directories, not the readFile's of its contents > (including "." and ".."). Yes, that's a bug. Now fixed. Cheers, Simon

1 0

aha! file descriptor leak in 'readFile'
by John Meacham 19 Apr '04

19 Apr '04

I have finally tracked down a test case which results in the file descriptor leak which has plauged one of my programs since its birth. this code: sequence (replicate 100 $ handle (\_ -> return "") ( readFile ".")) will leak 100 file descriptors, apparently, after a Fail: .: openFile: inappropriate type (is a directory) exception from readFile, the file descriptor will not be closed, and instead be left open til the end o' time. it took me a long time to find because I thought the bug was in the listing of my directories, not the readFile's of its contents (including "." and ".."). John -- John Meacham - ⑆repetae.net⑆john⑈

1 0

RE: #ifdef considered harmful (was: DData)
by Simon Marlow 16 Apr '04

16 Apr '04

On 16 April 2004 12:26, Alastair Reid wrote: > What I'd like to see is a general facility for defining strict types. > That is, types whose values will never be thunks so let binding > causes evaluation (as in ML) and use as a subexpression (which is not > under a lambda) causes evaluation (as in ML). The GHC syntax seems > too restrictive for this. Maybe something like this: > > strict_data Int# = Int# Int -- declare a strict Int type > > The typechecking issues would be the same as for GHC's unboxed types: > there are two kinds of typevar * and # and never the twain shall > meet. (I think GHC plays some neat tricks to ease the pain of this > restriction?) Yes, GHC has a separate kind for unlifted types. Unlifted types have kind #, so you can't pass something of unlifted type to a polymorphic function or store it in a polymorphic data structure, because ordinary type variables have kind *. I think there's a small superkind relationship, so kind *# is a superkind of both * and #, which is useful for things like the return type of 'error'. Do you want your strict types to be truly unlifted? GHC could usefully take advantage of that knowledge. > A semantically correct (but maybe a bit slow) implementation would be > easy enough: > > 1) let-bind all strict non-atomic subexpressions. > 2) float strict variable bindings out to nearest enclosing lambda > (float out any lazy variable bindings if required) > 3) Use 'seq' to force all the strict var thunks. > > For example: > > insert :: a -> (Int#,[a]) -> (Int#,[a]) > > insert x (cnt,xs) = (cnt+1,x:xs) > ===> > insert x (cnt,xs) = let cnt'=cnt+1 in seq cnt' $ > (cnt',x:xs) You have some kind of implicit coercion between Int and Int#. How does the type system work here? In GHC you can't put Int# in a pair, of course. Cheers, Simon

1 0

DData
by JP Bernardy 16 Apr '04

16 Apr '04

Hello everyone, After a month or so spent on stabilizing DData, I think I've reached a point where it is hopefully acceptable for everyone. In any case, I don't feel like I can make it much better (within the self-imposed restrictions). Therefore, I hereby submit it to the people in charge of the hierarchical libraries, for integration. Of course, if any specific detail deserves work, I remain available. The code/doc is at the usual url: http://users.skynet.be/jyp/DData/doc/ http://users.skynet.be/jyp/DData/ddata.tar.gz Thank you all for your feedback, Cheers, JP. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

18 40

RE: #ifdef considered harmful (was: DData)
by Simon Marlow 16 Apr '04

16 Apr '04

> "Simon Marlow" <simonmar(a)microsoft.com> writes: > > > Most of the time it's unnecessary to use an explicit Int#. > If your Int > > is in a data structure, you can use > > > > {-# UNPACK #-} !Int > > > > which is portable, and compiles to an unboxed Int in GHC >= 6.2. > > Is this different from > !Int > and > -funbox-strict > ? > > (I.e., should I change from this to UNPACK pragmas?) They both have the same effect, but I prefer to put these hints in the source code which is why I prefer to use {-# UNPACK #-} rather than the command-line flag. Also, sometimes it is necessary to have fine-grained control over which fields are unpacked. Cheers, Simon

1 0

RE: #ifdef considered harmful (was: DData)
by Simon Marlow 16 Apr '04

16 Apr '04

> Hmm, wouldn't it be nice to have a "FastInt" library which re-bound > the appropriate types and functions? Haskell libraries are > chock-a-block with instances of "#ifdef __GHC__" which define things > in terms of Int# instead of Int. We could simplify all those > libraries if we did it just once, in one place. > > The problem, of course, is that the naive non-GHC user could write a > library which used "FastInt" polymorphically, and write code that > wasn't portable to GHC. I don't think there's an easy, magic > solution > there. Perhaps such a library would be named > FastIntWhichIPromiseToTestWithGHC. Most of the time it's unnecessary to use an explicit Int#. If your Int is in a data structure, you can use {-# UNPACK #-} !Int which is portable, and compiles to an unboxed Int in GHC >= 6.2. However, depending on how you use the Int, GHC might need to insert reboxing code; e.g. if you store the Int in a list. The only reason to use an explicit Int# would be if you really wanted to be sure that no boxing was ever happening. The above trick is used in several places in the libraries currently: GHC's IO libraries and Data.HashTable are two good examples. Cheers, Simon

2 1

Re: [Haskell] ANNOUNCE: Haskell XML Toolbox Version 4.00
by Graham Klyne 15 Apr '04

15 Apr '04

Further to my previous message: http://www.haskell.org//pipermail/libraries/2004-April/002039.html I realize that my previous testing didn't check that HTTP retrieval actually works (as opposed to compiles). I find that the HTTP module shipped with HXml Toolbox does NOT work with Hugs under MS-Windows. I don't know why, but I do find that HXml Toolbox works fine with a version of HTTP that Bjorn Bringert has been working on, in my case by editing file 'hparser/ProtocolHandlerHttpNative.hs': [[ -- [GK] use version of HTTP prepared for hierarchical libraries, -- that works on Windows. import Network.HTTP -- http modules import Network.Browser ]] I had to make a couple of modifications to the HTTP module relative to Bjorn's: [[ -- ** Changes by Graham Klyne: -- - export httpVersion -- - use new URI module (similar to old, but uses revised URI datatype) ]] I also found a bug in the compatibility interface function "authority" in my URI module. The working HTTP and URI code can be found here: http://www.ninebynine.org/Software/HaskellUtils/Network/ I also noticed, in passing, that HXml Toolbox does require a version of Hugs that supports Char values greater than 255. I have versions of the 20040109 Hugs distribution recompiled for Windows with this support (and enlarged code space), which can be found at: http://www.ninebynine.org/Software/FatHugs.html #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

RE: sequences
by Simon Marlow 15 Apr '04

15 Apr '04

> Sven Panne writes: > > Grand Unified Collection Framework whenever it arrives. > Robert Will writes: > Since we already have a concrete proposal with prototype > implementation, that "whenever" may not be so far away. There are (at least) two concrete proposals with prototype implementations, and a large number of half-baked proposals for unified collection frameworks. None of them are obviously the right thing. It takes a large investment in order to fully evaluate any of the solutions, and I don't believe any of the proposals have received nearly enough scrutiny. That's not a problem as such: it just means that we won't arrive at a situation where there is agreement on what should be *the* Haskell collection framework. But what we should do is move in a direction where it is easier for people to install libraries on their machines and play around with them. Perhaps then there will be no need to determine a "standard" - a widely-used implementation may emerge on its own. At any rate, we're a long way off. Cheers, Simon

1 0

Proposal for a Standard of Abstract Collections (with Reference Implementation)
by Robert Will 15 Apr '04

15 Apr '04

hi all, Curiously I have finished the promised draft standard for the Abstract Collections just by a time, where many are busily working on DData. It's there: http://www.stud.tu-ilmenau.de/~robertw/dessy/fun/ I'm making this discussion hot now, since my Dessy library implements the proposed collection standard and features all of the concrete structures that are also in DData, and some more, especially Deques and Democratic Sequences (explanation: http://www.stud.tu-ilmenau.de/~robertw/dessy/fun/democratic/ ). But I also want to have your attention for another aspect of the problem: the introduction of abstract data structures makes the programming language much more useful and suggests some generalisations of the manifest syntax. Thus my proposal does not only contain - a formal specification for a collection hierarchy (based on Abstract Algebraic Data Structures (TM)), but also - generalisations of all the standard functions from Prelude and Data.List, and - a formal specification of Haskell extensions, that make abstract structures as easy to use as lists -- but with much more flexibility. Incidentally the current discussion around DData already shows signs of what I predict in the standard's rationale: when concrete data structures are extended to become more general, the number of functions increases so fast, that a general standard isn't more complicated any more, but simpler actually. For example, you discussed whether Sets and Maps should be converted from and to Sequences or the built-in "lists". Well, the best answer is to convert from and two an type classes of which "lists" (if one uses them at all) are an instance. Exactly this is done by the function "convert" proposed in the standard: > convert :: (Collection coll a, Collection coll' a) => > coll a -> coll' a > convert = fold empty single (<+>) (The function can be specialised in the same way as 'fromIntegral' on the numeric types, so we don't loose efficiency.) Abstraction is more: the proposed standard helps to use a lot of different data structure implementations together, using one interface that has been designed with the user first in mind, not the implementation. But this abstraction also allows an entirely new programming style, that is especially useful when TEACHING programming. Data Structures are deeply intertwined with programming as such, that the proposed standard gives Haskell something that NO other language does have today. (Perhaps Eiffel comes closest, but EiffelBase is not standardised.) (Remind me to write "A Gentle Introduction into Haskell with Abstract Collections".) It has been mentioned that an advantage is of functional programming is the ability to easily _compose_ programs. But for this composition data structures are neccessary, without a standard for data structures functional languages loose one of their biggest advantages. In specifications Sets are the most important data structure, but in Haskell today, the so-called "lists" are the linguaga franca and that reminds me too much of the stacks in Forth (remember "lists" are actually functional stacks) or dynamic arrays in imperative languages: it's universal, but unflexible. (I'll have to write a paper on "Liberating programming from the McCarthy-style".) Since "a standard of Abstract Collections" has already been mentioned by some, I expect that there are high expectations regarding my proposal, and perhaps its many disadvantages (all the big ones mentioned in the documentation) will discourage the reader. On the other hand, there are so many advantages that one can hardly neglect that something big is going on. So the least thing that someone interested in the future of (functional) programming should is to download and try out the Collections, or to read a little bit in the design documents. Things to do: - Build examples for the use of the new Collections. (From now on anyone can port his code to get rid of "lists".) - Develop the Haskell Documentation Standard and apply it to Collections. (Specifications are exported and used for Tests.) - Using those specifications make a complete test framework. (Complete meaning every function is tested with the complete specification, so no Bugs can persist.) Given all that, it is trivial to add more implementations of the Abstract Collections. (Just added two concrete structures Yesterday, although Dessy has already much more functionality than DData, but only half its code size. (Or one third if you don't count the type classes and specifications.) I also think that Dessy has more readable code, but I don't know how important that is for anyone.) Have a good time, Bob

9 21

RE: Heirarchical name space allocation
by Simon Marlow 15 Apr '04

15 Apr '04

> On Tuesday 30 Mar 2004 10:19 am, Simon Marlow wrote: > > The idea is that community self-organisation replaces strict > > central registration of library names. I think this is an > improvement, > > but perhaps it's a cop out. What do others think? > > I think there should be some concensus about the overall > structure of the > hierarchy, and that should be documented somewhere (so > developers don't go > and reinvent their own slightly different names for concepts which are > already covered). Perhaps it would suffice to just do this for the top > level classifications. > > In my case I have a pretty complete binding to SDL which I > was thinking > of tidying up and releasing for other Haskellers. I call it HSDL :-) > > But should it go in the Graphics Heirarchy, if so where? > Graphics.HSDL? > SDL also covers other functionality (like audio) so I was > thinking of calling > it Multimedia.HSDL, but at present there's no Multimedia top > level AFAIK (but > then how would I know anyway?). Perhaps someone's already > using Multi_Media > instead? Or maybe my binding isn't necessarily unique, so perhaps > Multimedia.SDL.HSDL? SDL also has quite few bolt on extras too which > other people might write bindings for. There's a kind of "design document" for the hierarchy, which is currently in CVS: fptools/libraries/doc/lib-hierarchy.html. It's also here: http://www.haskell.org/~simonmar/lib-hierarchy.html As we agree on locations for libraries on this list, I've been putting them in the document. Not all the libraries exist yet - this is just a place to put the design of the hierarchy. Multimedia.SDL sounds ok to me. Cheers, Simon

10 31

RE: System.Locale is broken?
by Simon Marlow 13 Apr '04

13 Apr '04

> System.Locale.defaultTimeLocale, which appears to be taken > directly from > the Haskell report, is hard-coded to american english > settings... which > seems to defeat the purpose of the module. Are there plans > to provide the actual locale? > > I have users who would like to have their times formatted according to > their own locale. I'd rather not have to do this using the > FFI to access the C library. :( We can't change Locale.defaultTimeLocale, because the Haskell 98 report specifies it. OTOH, I agree that it should do something reasonable. We can change System.Locale.defaultTimeLocale to be locale-specific: if you have some code, I'll incorporate it (assuming there are no objections). Cheers, Simon

2 1

RE: Compiler Versions
by Simon Marlow 13 Apr '04

13 Apr '04

> Simon Marlow wrote (snipped): > > I agree it's not worth arguing, it's more important to > decide whether we can implement Read Version. > > Why is the Read instance for Version so important? I don't really see > one using it much. The only occasion I can imagine when you > would actually > want to create a Version value for GHC is when you send a new > release out the door. > > I don't really the instance of Ord being that important > either. What one > wants to know is whether > (1) version X was released later than some given date; > (2) version X is lexicographically subsequent to [sequence of > integers] > (so GHC 6.02.1 comes after GHC 4.08.1); > (3) version X is a subversion of [sequence of integers], as > 6.2.1 is a subversion of 6.2; > (4) version X has a tag attached meaning "DANGER. Do not use > unless your > name is Simon". I see - I assumed you were planning to have Ord and Read instances for Version and compare versions by doing if ghc_version => read "6.2" then ... but you'd do it like this: if branch ghc_version >= [6,2] then ... which is fine. In fact, I think I like yours better :-) I'm not convinced of the need to have a date attached to all versions, though. Under what circumstances do you imagine needing (1) above, where (2) won't do? Cheers, Simon

2 1

RE: Compiler Versions
by Simon Marlow 13 Apr '04

13 Apr '04

> > type Branch = [Int] > > data Version = Release Branch | Snapshot Branch ClockTime > > This seems to me far too dependent on GHC. I see it more as a CVS-like versioning scheme than a GHC-like scheme. It follows a pattern that many projects are using these days. > I suggest that abstract or > not, each Version value contains the following information: > The format of "tags" should > be entirely up to the vendor > branch :: [Int] > date :: ClockTime > tags :: [String] > > Other information should be included as well of course, but is not > relevant to this discussion. > > Information about whether something is (in GHC-speak) a "release" or > a "snapshot" should properly be in (tags). But other people > should not > be obliged to use the GHC distinction between "release" and > "snapshot". The difficulty with this is how to construct a value of type Version. In your scheme, I need to know the release date for each version, or the library needs to have an appropriate mapping so that it can implement the Read instance for Version. This is why I left out the date from released versions in my scheme - but the disadvantage is that some versions become imcomparable. eg. I can't prove that a snapshot along the 6.2 branch is later or earlier than a particular release along that branch, but it is definitely later than 6.1.x and earlier than 6.3.x. I think this is reasonable. > There are two natural orderings, namely by branch and by > clocktime, but > there's not really a lot you can do about that. It is > entirely plausible > version 6.2.2 of something should have a release date after 6.4. > (If, for example, a number of Luddites have still to convert > to 6.4, but > need a bug fixed.) My vote would be for making Ord compare date first > (since that is a linear value), then branch, and then tags, but I can > see that other people may have different equally valid > opinions. In any > case there's not a whole lot of point arguing about it. Since versions are tree-shaped, it's going to be impossible to find an appropriate Ord instance that does the right thing all the time. Arguably it should be a partial ordering where only versions along the same branch of the tree are comparable, but in practice I need to compare versions like 4.08.2 and 6.2.1 and come up with the result LT, but knowing that I can do this depends on GHC's development strategy. I agree it's not worth arguing, it's more important to decide whether we can implement Read Version. > The fact that GHC refers to a snapshot of 6.2 on 13th April 2004 as > "6.2.20040413" is a vile hack which this discussion should certainly > ignore! Well, I didn't actually specify a concrete syntax for my Version type. Cheers, Simon

2 1

RE: Compiler versions
by Simon Marlow 13 Apr '04

13 Apr '04

> > > I prefer George's idea of an abstract version type which is > > > an instance of Show, Read and Ord. I'd probably also add > majorVersion and > > > minorVersion functions, which could return perhaps the > same abstract type. > > Sounds good to me. > > > Using an abstract version type seems to be the best choice for the > > reasons you give. However, there's a compromise here: > > > > - If you have an abstract version type for the version of > > entity X, then you need one version type for each X, because > > they have different versioning policies. (e.g. we can't > > use the same version type for the version of the > Haskell language > > and the version of the compiler, or versions of libraries). > > Can't we solve that problem with classes? > > class (Show a, Read a, Ord a) => Version a where > version :: a > majorVersion :: a -> a > minorVersion :: a -> a > > Each entity (language, compiler, library) can indeed define its own > versioning type and policy, with this abstract interface. It just > needs to publish the name of the concrete type that implements it. There isn't really a "problem" here, just that having lots of different version types might be unnecessary. I'm not sure that having a unified majorVersion/minorVersion interface buys very much - it implies a kind of binary tree structure to versions, but then I have to say how that is overlaid on the actual structure of each version type, and what it means to compose majorVersion/minorVersion. What would you use 'version' for, BTW? For packages at least, we have to pick a single versioning policy for all packages so that the library infrastructure can manage dependencies without having to know a separate versioning policy for each individual package. Ok, well it's not that big a deal. I guess we could have module System.Info -- or something data ImplementationVersion -- instacne Eq, Ord, Read, Show implementationVersion :: ImplementationVersion data HaskellVersion -- instance Eq, Ord, Read, Show haskellVersion :: HaskellVersion haskellExtensions :: [Extension] and then have a separate PackageVersion type for packages. I'll probably re-use the PackageVersion type for GHC's version. Cheers, Simon

1 0

Re: Compiler Versions
by George Russell 13 Apr '04

13 Apr '04

Simon Marlow wrote (snipped): > I like the idea of representing a version as [Int], using > lexicographic ordering; like CVS versions, this lets you branch the tree > as much as you like by adding an extra component. > > However, this presents a small problem for GHC versions, where eg. > 6.2.2004025 is supposed to be earlier than 6.2.1. So perhaps we should > elaborate the type: > > type Branch = [Int] > data Version = Release Branch | Snapshot Branch ClockTime This seems to me far too dependent on GHC. I suggest that abstract or not, each Version value contains the following information: The format of "tags" should be entirely up to the vendor branch :: [Int] date :: ClockTime tags :: [String] Other information should be included as well of course, but is not relevant to this discussion. Information about whether something is (in GHC-speak) a "release" or a "snapshot" should properly be in (tags). But other people should not be obliged to use the GHC distinction between "release" and "snapshot". There are two natural orderings, namely by branch and by clocktime, but there's not really a lot you can do about that. It is entirely plausible version 6.2.2 of something should have a release date after 6.4. (If, for example, a number of Luddites have still to convert to 6.4, but need a bug fixed.) My vote would be for making Ord compare date first (since that is a linear value), then branch, and then tags, but I can see that other people may have different equally valid opinions. In any case there's not a whole lot of point arguing about it. The fact that GHC refers to a snapshot of 6.2 on 13th April 2004 as "6.2.20040413" is a vile hack which this discussion should certainly ignore!

1 0

Seq instances
by Wolfgang Jeltsch 13 Apr '04

13 Apr '04

Hi, why are the following instances missing? instance Ord a => Ord (DData.Seq.Seq a) instance Monad DData.Seq.Seq Wolfgang

2 1

RE: Compiler versions
by Simon Marlow 13 Apr '04

13 Apr '04

David Roundy writes: > With the scheme of a triple of Ints, you could have problems > with versions > like 6.2.1pre1 or 6.2.1rc1 which can't easily be mapped to a triple of > Ints. > > I prefer George's idea of an abstract version type which is > an instance of > Show, Read and Ord. I'd probably also add majorVersion and > minorVersion > functions, which could return perhaps the same abstract type. > This could > also be extended to allow the versions of CVS checkouts to be dealt > with--they could have version numbers like 6.2.1cvs20040402 > or something. > Most importantly, though, you wouldn't be defining a version numbering > policy in the interface. Using an abstract version type seems to be the best choice for the reasons you give. However, there's a compromise here: - If you have an abstract version type for the version of entity X, then you need one version type for each X, because they have different versioning policies. (e.g. we can't use the same version type for the version of the Haskell language and the version of the compiler, or versions of libraries). - The alternative is to impose a policy. Perhaps the best choice is to pick a policy that is as unrestrictive as possible. I like the idea of representing a version as [Int], using lexicographic ordering; like CVS versions, this lets you branch the tree as much as you like by adding an extra component. However, this presents a small problem for GHC versions, where eg. 6.2.2004025 is supposed to be earlier than 6.2.1. So perhaps we should elaborate the type: type Branch = [Int] data Version = Release Branch | Snapshot Branch ClockTime I'm aware that Hugs versions don't fit well with this type, but there has been some discussion recently about changing the Hugs versioning scheme. The Haskell language versions just about fit into this type (98 > 1.3). One possible extension is to allow branches to be named, as long as there was an appropriate way to determine ordering (e.g. an Int associated with each branch name behind the scenes). Cheers, Simon

2 1

RE: Text.PrettyPrint mixes tabs and spaces??
by Simon Marlow 13 Apr '04

13 Apr '04

> >From Text.PrettyPrint.HughesPJ: > > indent n | n >= 8 = '\t' : indent (n - 8) > | otherwise = spaces n > > I consider it seriously evil to mix tabs and spaces for indentation. > *Seriously* evil. Kill-on-sight evil. > > Not to mention that LaTeX's \verbatiminput does not handle tabs, which > makes the result look like, well, crap. > > If there are people who want to mix tabs and spaces, fine, > but at least give me a flag that turns it off. Please? He's right; tabs aren't necessarily every 8 columns everywhere, so the generic pretty printing library shouldn't make this assumption. I'll remove it, unless there are any objections. Cheers, Simon

1 0

RE: Heirarchical name space allocation
by Simon Marlow 13 Apr '04

13 Apr '04

> That's no contradiction to my rule, e.g. > Graphics.Rendering.OpenGL is about > *all* OpenGL stuff, while Graphics.Rendering.OpenGL.GL is about GL and > Graphics.Rendering.OpenGL.GLU is about GLU. > > Perhaps I should explain a little bit more what IMHO is a > "good use" of the > hierarchical structure: > > * "collector" modules: These are a necessity for larger > APIs, otherwise you > can easily have dozens of closely related imports. Nobody > argued against > this use, IIRC, and we already have a lot of examples of it. > > * "selector" modules: There are different implementations > Foo.A and Foo.B of > basically the same API, but it's not clear (yet) which > one is better. So > Foo simply re-exports one of Foo.A and Foo.B as the > default for people who > don't care, but there is still the possibility of using a > specific one. > Text.PrettyPrint is an example of this use, although > there's currently only > one specific implementation. Another example is > Data.STRef, Data.STRef.Lazy, > and Data.STRef.Strict, but the imports are a bit > "upside-down" here, something > we should probably change. > > * A collection of only loosely related modules Foo.A, > Foo.B, ...: Having a > module Foo wouldn't make much sense in this case. A good > example for this > is the Data hierarchy. There is a rough policy, which pretty much repeats what Sven says above, here: http://www.haskell.org/hierarchical-modules/libraries/layout.html This is part of the document in fptools/libraries/doc/libraries.sgml, BTW. Some bits of it are out of date. Perhaps I should separate out the design guidelines into a separate document. Cheers, Simon

1 0

RE: DData
by Simon Marlow 13 Apr '04

13 Apr '04

> hello, > irrespective of if DData is "the" data structure library > (whatever that > means), > or simply another library, could we avoid adding it to the > base package? > it would be much nicer, if the base package was split into > more components. > > and it would also be nice if i can go and download DData on its own, > whenever there are bugfixes, > or improvements, without needing to download GHC with it. > i don't see any reason why DData should be part of "base". A rough criteria for what should be in 'base' is: everything required by Prelude. I say only a rough criteria, because there are currently plenty of libraries in base that aren't required by the Prelude, but are there because splitting them off into a separate package would be overkill. (Also at one stage I was using a different criteria: everything required to bootstrap GHC). Cheers, Simon

1 0

Re: Compiler versions
by Jon Cast 07 Apr '04

07 Apr '04

Malcolm Wallace <Malcolm.Wallace(a)cs.york.ac.uk> wrote: <snip> > I remember Mark Jones suggesting more-or-less exactly this idea back > in about 1998/1999. It has been implemented in nhc98 ever since, but > I finally deleted it from CVS recently because no other systems > supported it. And (probably the more major reason) because I > frequently forgot to keep it up to date. Here was the signature: > > module Haskell where > > import Time > import Locale > > systemName :: String -- "Hugs", "GHC", "hbc", "nhc", "qhc", .. > . > haskellVersion :: Int -- 13, 14, 98, 2000, ... ^^^^^^^^^^^^^^^^^^^^^ I wholeheartedly endorse this, but these days I think (Version, [String]) would be a better type, i.e., (haskell98, ["Standard FFI", "Multi-parameter type classes", "Functional Dependencies", ...]. Knowing the Haskell version number by itself won't be much good until the Haskell 2.0 standard, but knowing which extensions are present (independent of the compiler version) would be a very good thing (listing syntactic extensions isn't an entirely useless thing; I'm sure it would make Autoconf's job easier). > releaseDate :: CalendarTime -- ... > version :: String -- some combination of the above <snip> Jon Cast

2 1

RE: Ord instance for TypeRep?
by Simon Peyton-Jones 07 Apr '04

07 Apr '04

It's not as simple as it sounds. The difficulty is this: Is typeOf (x::Int) > type (y::Bool) If the semantics of the language is well defined, there should be an answer, otherwise you could write programs in which different Haskell implementations give different answers. We could legislate lexicographic comparison based on the type constructor names, but that's not very efficient and I'd rather not tie the hands of the implementation. This is an old chestnut that I really don't know a good solution too. A not very good solution is this: if the reason for comparison is for maps, provide maps data TypeRepMap a empty :: TypeRepMap a insert :: TypeRepMap a -> TypeRep -> a -> TypeRepMap a etc But it's not very satisfactory because it adds a big new interface to TypeRep. Better ideas would be welcome. Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Dylan | Thurston | Sent: 06 April 2004 21:12 | To: libraries(a)haskell.org | Subject: Ord instance for TypeRep? | | I'm not sure this is the right place to make this request, but could | an instance of 'Ord TypeRep' please be added? I'd like to store | dynamically typed elements in a FiniteMap. | | Peace, | Dylan

2 1

Re: [Haskell] ANNOUNCE: Haskell XML Toolbox Version 4.00
by Graham Klyne 07 Apr '04

07 Apr '04

At 11:37 06/04/04 +0200, Uwe Schmidt wrote: >Haskell XML Toolbox 4.00 > >I would like to announce a new version of the Haskell XML Toolbox for >processing XML including a validating parser and a new XPath module. Testing the new kit using Hugs under Windows, with test program Examples/HUnit/HUnitExample.hs. Because I'm starting from a clean distribution, I'm hoping that this will show up all of the Windows/Hugs incompatibilities that I may have missed reporting previously. This message is constructed in a stream-of-consciousness style, as I wanted to capture every step I took to get the code running. (I *did* get the code running with Hugs under Windows, with just a little butchery ;-) My first step was to unpack the distribution kit into a directory: D:\Cvs\DEV\HaskellUtils\HXmlToolbox-4.00 I then created a batch file to run Hugs from the Examples directory: [[ rem Use Hugs version compiled with Unicode support set HUGS=C:\DEV\Hugs98\hugs-20040109.exe set LIBS=..\hdom;..\hparser;..\hvalidator;..\hxpath;..\http;..\popen %HUGS% -P"%LIBS%;" PAUSE ]] (I should check if the HXML Toolbox requires Haskell support for 'char's with codepoints >255. Later.) ... [[ Reading file "..\http\HTTP.hs": Parsing ERROR "..\http\HTTP.hs":132 - Syntax error in import declaration (unexpected symbol "partition") Network.Socket> ]] import Data.List ({- isPrefixOf -},partition,elemIndex) -- uwe changed to: import Data.List ({- isPrefixOf, -} partition,elemIndex) -- uwe ... I experienced a problem with http.hs, because my version of Network.URI has a different internal structure. It's not clear to me why there's a need to force a '/' at the front of the path (i.e. if a relative path is supplied here, isn't it an error in any case?): [[ alt_uri = show $ if null (path u) || head (path u) /= '/' then u { uriPath = '/' : path u } else u ]] (this is modified to use uriPath, so it works with my Network.URI) In the longer run, I'm hoping that the HTTP module will become part of the Network library module, based on work by Bjorn Bringert. ... [[ Reading file "..\http\Browser.hs": Parsing ERROR "..\http\Browser.hs":70 - Syntax error in import declaration (unexpected comma) HTTP> ]] import Control.Monad (foldM,filterM, {- liftMf -},when) changed to: import Control.Monad (foldM,filterM, {- liftMf, -} when) ... I also had a problem with functions trimHost and formToRequest in Browser.hs and my URI module, similar to that noted above. Again, I hope this problem can be avoided when http is part of the common library. ... [[ Reading file "..\hparser\ProtocolHandlerHttpCurl.hs": Parsing ERROR "..\hparser\ProtocolHandlerHttpCurl.hs" - Can't find imported module "Posix" ProtocolHandlerHttpNative> ]] This is the old well-known POpen problem. I've copied my version of POpen into the HXMLtoolbox code tree (it compiles, but still doesn't work), and changed the import Posix(popen) to import POPen(popen). ... With the above changes, the code runs but reports 8 failures: [[ Cases: 110 Tried: 110 Errors: 0 Failures: 8 Counts{cases=110,tried=110,errors=0,failures=8} ]] Failures are: [[ fatal error: illegal URI for input: "mini1.xml" : ### Failure in: 3:input tests:3 expected: "<x/>" but got: "" Cases: 110 Tried: 36 Errors: 0 Failures: 1 fatal error: illegal URI for input: "mini1.xml" ### Failure in: 3:input tests:4 expected: "0" but got: "3" Cases: 110 Tried: 37 Errors: 0 Failures: 2 fatal error: illegal URI for input: "mini1.xml" : ### Failure in: 3:input tests:5 expected: "4" but got: "0" Cases: 110 Tried: 38 Errors: 0 Failures: 3 fatal error: illegal URI for input: "mini2.xml" ### Failure in: 3:input tests:6 expected: "0" but got: "3" Cases: 110 Tried: 39 Errors: 0 Failures: 4 fatal error: illegal URI for input: "notThere.xml" : fatal error: illegal URI for input: "mini2.xml" : ### Failure in: 4:document transformation tests:0 expected: " ignore unknown important important " but got: "" Cases: 110 Tried: 42 Errors: 0 Failures: 5 fatal error: illegal URI for input: "mini2.xml" : ### Failure in: 4:document transformation tests:1 expected: "ignoreunknownimportantimportant" but got: "" Cases: 110 Tried: 43 Errors: 0 Failures: 6 fatal error: illegal URI for input: "mini2.xml" : ### Failure in: 4:document transformation tests:2 expected: " important important " but got: "" Cases: 110 Tried: 44 Errors: 0 Failures: 7 fatal error: illegal URI for input: "mini2.xml" : ### Failure in: 4:document transformation tests:3 expected: " ignore important " but got: "" Cases: 110 Tried: 110 Errors: 0 Failures: 8 Counts{cases=110,tried=110,errors=0,failures=8} Main> ]] Thus it looks as if all of the failures are due to an invalid URI for a local file. This is a re-run of an old problem, traced back to: [[ setDefaultURI :: XState state () setDefaultURI = do wd <- io getCurrentDirectory setSysParam transferDefaultURI ("file://localhost" ++ wd ++ "/") ]] -- XmlInput.hs The value returned by getCurrentDirectory on Windows is not valid as part of a URI. I previously fixed this by replacing the above with the following: [[ {- original: setDefaultURI :: XState state () setDefaultURI = do wd <- io getCurrentDirectory setSysParam transferDefaultURI ("file://localhost" ++ wd ++ "/") -} -- Revised version to allow Windows directory strings. [[[GK]]] -- -- If the current directory starts with 'd:', it is assumed to be a Windows -- directory, and all '\' characters are mapped to '/'. -- -- In any case, any non-URI or reserved character is escaped. setDefaultURI :: XState state () setDefaultURI = do wd <- io getCurrentDirectory let wd1 = case wd of d:':':_ | driveLetter d -> '/':concatMap win32ToUriChar wd otherwise -> concatMap escapeNonUriChar wd setSysParam transferDefaultURI ("file://localhost" ++ wd1 ++ "/") -- [[[I'd prefer to leave 'localhost' as null, but this raises -- awkward questions about whether it's OK to remove a -- null authority from a URI]]] where win32ToUriChar '\\' = "/" win32ToUriChar c = escapeNonUriChar c escapeNonUriChar c = escapeChar isUnescapedInURI c -- from Network.URI driveLetter d = d `elem` ['A'..'Z'] -- to test: -- run () $ do { uri <- getDefaultURI ; io (putStrLn uri) } {- Excerpt from: http://www.ietf.org/internet-drafts/draft-hoffman-rfc1738bis-01.txt 2.7 FILES The file URL scheme is used to designate files accessible on a particular host computer. This scheme, unlike most other URL schemes, does not designate a resource that is universally accessible over the Internet. A file URL takes the form: file://<host>/<path> where <host> is the fully qualified domain name of the system on which the <path> is accessible, and <path> is a hierarchical directory path of the form <directory>/<directory>/.../<name>. As a special case, <host> can be the string "localhost" or the empty string; this is interpreted as "the machine from which the URL is being interpreted". However, this part of the syntax has been ignored on many systems. That is, for some systems, the following are considered equal, while on others they are not: file://localhost/path/to/file.txt file:///path/to/file.txt Some systems allow URLs to point to directories. In this case, there is usually (but not always) a terminating "/" character, such as in: file://usr/local/bin/ On systems running some versions of Microsoft Windows, the local drive specification is preceded by a "/" character. Thus, for a file called "example.ini" in the "windows" directory on the "c:" drive, the URL would be: file:///c:/windows/example.ini For Windows shares, there is an additional "/" prepended to the name. Thus, the file "example.doc" on the shared directory "department" would have the URL: file:////department/example.doc The file URL scheme is unusual in that it does not specify an Internet protocol or access method for such files; as such, its utility in network protocols between hosts is limited. -} ]] I also needed to add an import to XmlInput.hs: [[ import Network.URI ( isUnescapedInURI, escapeChar ) ]] ... I also find I must modify ProtocolHandlerFile.hs to strip off the leading '/' from the path to work on Windows. The following change is made to function getFileContents: [[ {- Original: source = path uri readErr msg = addFatal msg n -} -- [[[GK]]] strip off leading '/' from Windows drive name source = fileuripath (path uri) fileuripath ('/':file@(d:':':more)) | driveLetter d = file fileuripath file = file driveLetter d = d `elem` ['A'..'Z'] readErr msg = addFatal msg n ]] ... Finally, I must copy mini1.xml and mini2.xml into the directory from which I'm running Hugs (i.e. HXmlToolbox-4.00/examples), and the test program runs with no errors: [[ Cases: 110 Tried: 110 Errors: 0 Failures: 0 Counts{cases=110,tried=110,errors=0,failures=0} ]] ... Well, that wasn't too hard, second time around. Maybe we should abstract out the URI<->filename mapping logic into another module that is specifically to handle the file: URI scheme. Dopes it make sense to add such a module to the network branch of the library hierarchy, to sit alongside the HTTP modules? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

RE: DData
by Simon Marlow 07 Apr '04

07 Apr '04

> JP Bernardy wrote: > > [...] Therefore, I hereby submit it to the people in charge > > of the hierarchical libraries, for integration. Of > > course, if any specific detail deserves work, I remain > > available. [...] > > I could add DData to the hierarchical libraries in the > fptools repository, > but first a few points should be clarified: Can we hold off on this a while longer please. Partly because I am not here :-) but also I think it needs at least one more round of reviewing, and there is still Ross's overloaded sequences suggestion to decide on. The intention was for the DData libraries to be placed directly under Data (i.e. Data.Set etc.). I had imagined that we would leave the old interfaces available too, deprecated, as long as the names didn't clash. None of this precludes adding overloaded collections later; all we're doing here is adding some concrete data structures. Cheers, Simon

3 2

Compiler versions
by Simon Peyton-Jones 07 Apr '04

07 Apr '04

Library folk Below is a suggestion from George that initially appears to be about Template Haskell: access to the GHC version identity. But of course it's not strictly a TH thing: we could simply provide a module module GHC.Version where ghcVersion :: Int and then you could import that module anywhere, including in your TH program: import GHC.Version $( if ghcVersion > ... then ... ) And indeed such a thing might be more generally useful, across all Haskell implementations not just GHC. Perhaps it should be module System.Compiler where compilerName :: String releaseDate :: CalendarTime -- or (Day,Month,Year)? version :: (Int,Int) patchLevel :: Int So then a program could ask whether it was being run by Hugs or GHC or whatever. Questions: * Would this be a good thing to agree across compilers? * What should the interface be? I gave one possibility above; George gives another. * I imagine this'd be useful for the library infrastructure project, somehow. Would anyone like to run with this to get an interface agreed? From the GHC end we'd be happy to implement any agreed interface. Simon -----Original Message----- From: George Russell [mailto:ger@informatik.uni-bremen.de] Sent: 07 April 2004 10:46 To: Simon Peyton-Jones Subject: Re: mkName and qualified names George Russell wrote: > incidentally you asked for priorities. Mine are (still) Oh, and another one, (3) access to the current GHC version. For example data GhcVersion instance Read GhcVersion instance Ord GhcVersion thisVersion :: GhcVersion then you can do $( if thisVersion >= read "6.4.1" then [dd| -- use whizzo new features ... |] else [dd| -- sigh. painful workaround for Luddites ... |] ) This isn't nearly as important to me as the other two suggestions I made, however I presume it would be easier to implement. best wishes and thanks, George

5 5

Re: Compiler versions
by Graham Klyne 07 Apr '04

07 Apr '04

I started (and stalled, though not permanently I hope) on a similar idea, to offer as part of the library infrastructure. Mine was somewhat more complex, maybe too much so, dealing with a combination of static and dynamic information, and also hoping to circumvent or minimize the CPP problem. Copies of the initial code and test module are at: http://www.ninebynine.org/Software/HaskellUtils/LibraryInfrastructure/Distr… http://www.ninebynine.org/Software/HaskellUtils/LibraryInfrastructure/Distr… #g -- At 10:59 07/04/04 +0100, Simon Peyton-Jones wrote: >Library folk > >Below is a suggestion from George that initially appears to be about >Template Haskell: access to the GHC version identity. But of course >it's not strictly a TH thing: we could simply provide a module > > module GHC.Version where > ghcVersion :: Int > >and then you could import that module anywhere, including in your TH >program: > > import GHC.Version > $( if ghcVersion > ... then ... ) > >And indeed such a thing might be more generally useful, across all >Haskell implementations not just GHC. Perhaps it should be > > module System.Compiler where > compilerName :: String > releaseDate :: CalendarTime -- or (Day,Month,Year)? > version :: (Int,Int) > patchLevel :: Int > >So then a program could ask whether it was being run by Hugs or GHC or >whatever. > >Questions: > >* Would this be a good thing to agree across compilers? > >* What should the interface be? I gave one possibility above; George >gives another. > >* I imagine this'd be useful for the library infrastructure project, >somehow. > >Would anyone like to run with this to get an interface agreed? From the >GHC end we'd be happy to implement any agreed interface. > >Simon > >-----Original Message----- >From: George Russell [mailto:ger@informatik.uni-bremen.de] >Sent: 07 April 2004 10:46 >To: Simon Peyton-Jones >Subject: Re: mkName and qualified names > >George Russell wrote: > > incidentally you asked for priorities. Mine are (still) > >Oh, and another one, >(3) access to the current GHC version. For example > > data GhcVersion > > instance Read GhcVersion > instance Ord GhcVersion > > thisVersion :: GhcVersion > >then you can do > $( if thisVersion >= read "6.4.1" > then > [dd| -- use whizzo new features > ... > |] > else > [dd| -- sigh. painful workaround for Luddites > ... > |] > ) > > >This isn't nearly as important to me as the other two suggestions >I made, however I presume it would be easier to implement. > >best wishes and thanks, > >George >_______________________________________________ >Libraries mailing list >Libraries(a)haskell.org >http://www.haskell.org/mailman/listinfo/libraries ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

RE: #ifdef considered harmful
by Simon Marlow 07 Apr '04

07 Apr '04

> At 08:57 07/04/04 +0100, Simon Peyton-Jones wrote: > >cpp is readily available everywhere, whereas some new > >tool would not be. > > Hmmm... it was my perception of the falsity of this that led > me to raise > the issue in the first place. See also [1]. > > Otherwise, I broadly agree with the points you make. One good reason for implementing our own preprocessor that nobody has raised yet is that the implementation of cpp we all use (gcc) is not under our control and recently has been changing its semantics in ways that affect us. CPP in gcc 3.4 interprets '\' followed by whitespace at the end of a line as a line continuation; previous versions of cpp didn't do that, and it makes it impossible to use Haskell string gaps in CPP'd Haskell source. I don't trust the GCC guys to keep the -traditional flag around for ever either. I'd settle for just finding a good standalone open source cpp, removing any undesirable features, and shipping it with the compilers. BTW, Hugs copes with CPP directives in the standard libraries by running CPP over the source code before packaging up the distribution: that way CPP isn't required on the target system. Cheers, Simon

1 0

Text.PrettyPrint mixes tabs and spaces??
by Martin Sjögren 07 Apr '04

07 Apr '04

>From Text.PrettyPrint.HughesPJ: indent n | n >= 8 = '\t' : indent (n - 8) | otherwise = spaces n I consider it seriously evil to mix tabs and spaces for indentation. *Seriously* evil. Kill-on-sight evil. Not to mention that LaTeX's \verbatiminput does not handle tabs, which makes the result look like, well, crap. If there are people who want to mix tabs and spaces, fine, but at least give me a flag that turns it off. Please? Regards, Martin

1 0

RE: #ifdef considered harmful
by Graham Klyne 07 Apr '04

07 Apr '04

At 08:57 07/04/04 +0100, Simon Peyton-Jones wrote: >cpp is readily available everywhere, whereas some new >tool would not be. Hmmm... it was my perception of the falsity of this that led me to raise the issue in the first place. See also [1]. Otherwise, I broadly agree with the points you make. #g -- [1] http://www.haskell.org//pipermail/libraries/2004-April/002009.html ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

System.Locale is broken?
by David Roundy 07 Apr '04

07 Apr '04

System.Locale.defaultTimeLocale, which appears to be taken directly from the Haskell report, is hard-coded to american english settings... which seems to defeat the purpose of the module. Are there plans to provide the actual locale? I have users who would like to have their times formatted according to their own locale. I'd rather not have to do this using the FFI to access the C library. :( -- David Roundy http://www.abridgegame.org

1 0

RE: #ifdef considered harmful
by Simon Peyton-Jones 07 Apr '04

07 Apr '04

I have not been following the details of this thread, but let me urge caution. Cpp is used in mostly-trivial ways to deal with the fact that a single blob of source code is being fed into several different compilers. The fact that cpp is not perfect for this use is not a reason to design something new. cpp is readily available everywhere, whereas some new tool would not be. It certainly seems overkill to design a whole new pre-processor system! (Mind you, doing so might be an interesting exercise in its own right -- Template Haskell is such an experiment -- but the need here is for a solution, not a research programme.) I agree with Johannes: (a) keep it simple, (b) integrate with compilers. (a) argues for cpp. As to (b) is there some reason that Hugs cannot simply run cpp? Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Johannes | Waldmann | Sent: 07 April 2004 07:43 | To: Alastair Reid | Cc: libraries(a)haskell.org | Subject: Re: #ifdef considered harmful | | Alastair Reid wrote: | | > So, I'd like to float the idea that the Haskell preprocessor should _only_ | > support conditional compilation, that macro expansion should only occur in | > lines that begin with '#' not in "normal" lines and that macros should always | > evaluate to expressions with simple scalar types (ints, strings, etc.) | | > [It's probably simple enough that the preprocessor could | > easily be built into Hugs if we wanted. This isn't the primary | > motivation for this suggestion but it would be nice.] | | I'd vote for that (as a user). If we absolutely need preprocessing, | then the above looks like a very reasonable way to go: | 1. keep it simple, 2. integrate it with compilers. | | best regards, | -- | -- Johannes Waldmann, Tel/Fax: (0341) 3076 6479 / 6480 -- | ------ http://www.imn.htwk-leipzig.de/~waldmann/ --------- | | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

2 1

sequences
by ross＠soi.city.ac.uk 07 Apr '04

07 Apr '04

I've been arguing that sequences should be treated differently from other data structures, since they can be handled by a Haskell 98 class, and they exhibit greater variety, so the class is more useful. One way to get there is to take Edison, remove the module-based overloading and add default definitions to the class. I don't think default definitions are quite as useless as Chris suggests: often there is a most common default; in some other cases there is a choice, but you have a family of methods that will all decide the same way, so you can delegate to one member of the family. And defaults make it easier to get started with a new instance. To have something concrete to discuss, I've placed a structure based on Edison at docs: http://www.soi.city.ac.uk/~ross/seq/ code: http://www.soi.city.ac.uk/~ross/seq.tar.gz

3 3

Ord instance for TypeRep?
by dpt＠lotus.bostoncoop.net 06 Apr '04

06 Apr '04

I'm not sure this is the right place to make this request, but could an instance of 'Ord TypeRep' please be added? I'd like to store dynamically typed elements in a FiniteMap. Peace, Dylan

1 0

Re: DData
by Johannes Waldmann FbIMN 05 Apr '04

05 Apr '04

BTW, what does the first "D" in DData stand for? Perhaps "Daan"? I don't like concatenated module names ("D" ++ "Data"). We have hierarchical names to avoid exactly that. It should then perhaps be Data.Daan, similar to module Text.PrettyPrint.HughesPJ -- -- Johannes Waldmann, Tel/Fax: (0341) 3076 6479 / 6480 -- ------ http://www.imn.htwk-leipzig.de/~waldmann/ ---------

1 0

Re: Heirarchical name space allocation /Trees
by Okasaki, C. DR EECS 02 Apr '04

02 Apr '04

> Who doesn't get at least a bit uneasy when looking at all the redundancy, > in e.g. Edison's code? Okasaki has written some generic functions, but > they have to be renamed manually in each module. All for the sake of > efficiency! Bertrand Meyer did not propose to handle this via inheritance > without ensuring that the compiler would eliminate all the indirections. > And that was in 1985! I may be misunderstanding what you are saying here, but I think you are complaining that Edison has a lot of redundancy because it doesn't use default definitions. And I think you are attributing that avoidance of default definitions to a concern about avoiding indirections. But indirections and "efficiency" (in the sense I think you mean) have nothing to do with it! The redundancy you are referring to comes from two sources. First is the desire for Edison to support *both* the class-based style and the module-based style of accessing the data structures. As other posts in this thread have shown, both styles have their strong supporters, and I didn't see any reason that the library should dictate one style over the other. Because the module-based style doesn't support inheritance, you have to put in explicit definitions for every operation, even if many of those definitions are one-liners that refer to generic functions. The second source of redundancy is that default definitions are largely useless for this kind of library. The problem is that there is rarely *one* generic function that makes sense as the default. Instead, there are often two or three or more functions that are all equally good candidates to be the default. So which one do you choose? If there is one that is appropriate, say, 80% of the time, then sure go ahead and make that one the default. But if there are three, and each is appropriate about 33% of the time, then I think it is more clear not to have a default, and have every implementation state explicitly which of the "defaults" it is using. -- Chris

1 0

RE: State of DData
by Simon Marlow 02 Apr '04

02 Apr '04

> > Arguably then, anything which is an instance of Monad > should be a monad. > > I would certainly argue strongly for that. > > If it ain't true, then small, irrelevant changes in a piece > of code could > break. For example, is it safe to make this change: > > do > f y > ==> > do > x <- f y > return x > > I'd hope it would be. (And the change might be useful if I > want to insert a check or a debugging printf in the code.) I'm afraid it isn't true that all instances of Monad respect the monad laws, due to our old friend seq. See: http://www.haskell.org/pipermail/haskell/2002-May/009622.html I don't want this discussion to get out of hand. The only point I'm making here is that the Haskell definition doesn't *require* that every instance of (==) be equality, in the same way that it doesn't *require* that all Monad instances are monads, and all '+'s are additions etc. Libraries might rely on properties of these methods, but as far as is practical those assumptions should be documented. Cheers, Simon

4 3

RE: Heirarchical name space allocation
by Graham Klyne 02 Apr '04

02 Apr '04

At 10:19 30/03/04 +0100, Simon Marlow wrote: > > > Who's in charge of allocating names in the hierarchical > > modules for publicly released libraries these days? > > > > This page lists (some) allocated names.. > > http://www.haskell.org/~simonmar/libraries/layout.html > > > > But I can think of a few that aren't listed there. > > What's the policy? > > Is there a master reference or register somewhere? > >At one stage we thought that having a single global registry for names >was the way to go. Now I think that a free-for-all, with good package >management tools, is probably better. > >Names and hierarchy locations will still be discussed on this list, but >anyone is free to publish a library using any names in the hierarchy >they please. If there is overlap, then the compiler should prevent you >from using two overlapping packages at the same time. In fact, there's >one good reason for allowing overlap: versioning of libraries. > >Of course, if your library uses names that are consistent with the >general policy, then there's a greater chance that your library will be >included in future "collections" of libraries, bundled with compilers, >and so on. The idea is that community self-organisation replaces strict >central registration of library names. I think this is an improvement, >but perhaps it's a cop out. What do others think? I like it. It might be appropriate for designers to document module names they use in the wiki? #g -- PS: the "provisional registry" of "Registration procedures for message header fields" [1] is almost a similar free-for-all. The general idea is to give developers a pretty free hand in choosing names, but provide a common listing for the purposes of coordinating activities. [1] http://www.ietf.org/internet-drafts/draft-klyne-msghdr-registry-07.txt ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

RE: Heirarchical name space allocation /Trees
by Simon Peyton-Jones 02 Apr '04

02 Apr '04

| specific optimisations). Of course anyone may disagree. (Btw, | documenting all the really innovative stuff in official publications will | take some time, so if you want to wait...). Robert, let me encourage you to do this writing. Debates on the Haskell libraries list have a narrow audience; a paper has a far wider audience. Furthermore, the process of writing a paper often has an incredibly beneficial effect on the ideas being described. And the paper will still be read long after the implementations it describes have turned to dust -- papers infect people's brains which is the most powerful form of software propagation of all. The Haskell workshop might be a good venue. Simon

1 0