- Libraries - Haskell.org

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