July 2009 - Libraries

PROPOSAL: Remove Control.OldException
by Ian Lynagh 04 Aug '09

04 Aug '09

Hi all, Proposal: Remove Control.OldException http://hackage.haskell.org/trac/ghc/ticket/3381 We included Control.OldException in base to help people trying to remain compatible with both GHC 6.8 and GHC 6.10. However, my impression is that most (all?) people who wanted compatibility used the extensible-exceptions package instead. I propose that we remove Control.OldException for GHC 6.12. If anyone does want Control.OldException, then it could be provided by a separate package. Deadline: 2nd August (2 weeks). Thanks Ian

9 13

PROPOSAL: Add openFileTemplate, openBinaryFileTemplate to System.IO
by Ian Lynagh 04 Aug '09

04 Aug '09

Hi all, This is Add openFileTemplate, openBinaryFileTemplate to System.IO http://hackage.haskell.org/trac/ghc/ticket/3393 (originally part of http://hackage.haskell.org/trac/ghc/ticket/2610) In System.IO, openTempFile and openBinaryTempFile mask the file permissions of the file they create with 0o600. However, we would like to use it for implementing things like writeFileAtomic, in which case we want the default file permissions to be used. I propose that we add openFileTemplate and openBinaryFileTemplate functions, which use the default permissions. Deadline: 8th August (2 weeks). Thanks Ian

5 7

Data.Fixed.Fixed constructor
by Ashley Yakeley 28 Jul '09

28 Jul '09

I'm currently working on updating the Data.Fixed module in base. I am adding Typeable and Data instances (automatically derived), and several new HasResolution types (including one for 10^-2, monetary currencies being an obvious Fixed use). The Fixed type is simply a newtype of Integer. Should I expose its MkFixed constructor? Against: * MkFixed is not used in numerical calculation, and isn't itself a conversion function from Integer (obviously). * Ratio doesn't expose its constructor. For: * It's possible to recreate it anyway. * There's a Data instance, so morally the constructor is exposed. -- Ashley Yakeley

4 15

ANN: bindings-posix 0.0.2
by Maurício 28 Jul '09

28 Jul '09

bindings-posix is a low level binding to Posix. http://hackage.haskell.org/package/bindings-posix It is part of bindings-* packages, and makes use of facilities and design from package bindings-common to map the standard Posix library as described in this page: http://www.opengroup.org/onlinepubs/9699919799/basedefs/contents.html The major drawback is that it bindings to the Posix instance that runs on my computer (and probably most computers using ghc and gcc). However, if there's interest, I can add support to various layers of Posix if someone with knowledge of Posix helps me with environment variables I should use to (de)activate specific functionality. Best, Maurício

1 0

ANN: bindings-common 0.2.1
by Maurício 28 Jul '09

28 Jul '09

bindings-* packages provide low level bindings to well known foreign libraries like sqlite3 and libusb. They are supposed to be used by high level module developers who needs special functionality already available outside Haskell. Natural examples of such modules would be higher level versions of such bindings. bindings-common offers basic code that makes writing such packages easier, and provide a common design standard. http://hackage.haskell.org/package/bindings-common The major new feature of this release is the availability of hsc2hs custom macros, and a corresponding big reduction in code size. As an example, the code below is all that is necessary to write a Haskell version of a C struct, with Storable instance: -- This is 'hostent' struct from posix <netdb.h>: #bindings_starttype struct hostent #bindings_field h_name , CString #bindings_field h_aliases , Ptr CString #bindings_field h_addrtype , CInt #bindings_field h_length , CInt #bindings_field h_addr_list , Ptr CString #bindings_stoptype _ That results in http://hackage.haskell.org/packages/archive/bindings-posix/0.0.2/doc/html/B… Those hsc2hs macros have been used to map the standard C library (see module Bindings.C), as well as posix standard library (in a separate package), and are made available to modules depending on bindings-common. Best, Maurício

1 0

Haskell Platform progress report
by Don Stewart 27 Jul '09

27 Jul '09

I've tried to summarise the last 3 months of HP activity: http://donsbot.wordpress.com/2009/07/26/haskell-platform-progress-report/ Including download statistics to inspire the packaging teams prior to this week's release :-) -- Don

1 0

PROPOSAL: export copyPermissions from System.Directory
by Ian Lynagh 25 Jul '09

25 Jul '09

Hi all, This proposal is: export copyPermissions from System.Directory http://hackage.haskell.org/trac/ghc/ticket/3392 (originally part of http://hackage.haskell.org/trac/ghc/ticket/2610) The copyPermissions :: FilePath -> FilePath -> IO () function (currently an internal function) should be exported from System.Directory. It is not the same as getPermissions s >>= setPermissions d as the Permissions type this uses is lossy. Deadline: 8th August (2 weeks). Thanks Ian

1 0

Proposal: ExplicitForall
by Niklas Broberg 25 Jul '09

25 Jul '09

Hi all, (I'm writing this to several lists since it involves GHC (implementation of extensions), cabal (registration of extensions) and some future Haskell standard (formalisation of extensions).) In my quest to implement all known syntactic extensions to Haskell in my haskell-src-exts package, I've become painfully aware of the sometimes ad-hoc nature that these extensions have been added to GHC. This should not be taken as criticism per se, GHC is awesome and I'm sure a lot of thought and research has gone into all of these extensions. I think the problem (from my point of view) is rather that most of the extensions are only really "interesting" on a type system level, whereas the syntactic level is rather trivial, and thus the latter has (rightly) gotten far less formal attention. I hope my putting the light on these issues will be a help and a kickoff towards improving the state of formalisation of the known and registered (with Cabal) extensions. One of the most blatant and (to me) problematic such issues is the matter of using 'forall'. GHC has a number of extensions relating to the use of forall-quantified types in various interesting ways. With none of these extensions on, forall is not considered a keyword, so the syntax with explicit forall quantification cannot be used at all ('forall' is considered a varid). However, with *any* extension on that relates to forall-quantified types, forall is a keyword, and can syntactically be used in types *anywhere*. This doesn't mean all such types will pass the type checker, most of them won't in fact, but syntactically there is really no (or at least very little) difference. Conceptually, all of these extensions (specifically PolymorphicComponents, Rank2Types, RankNTypes, LiberalTypeSynonyms and ScopedTypeVariables (and strangely also ExistentialQuantification)) thus have one thing in common. They all enable syntactically forall-quantified types. They allow different uses of these types as far as the type system is concerned, but syntactically there is no difference between type and type (in fact there cannot be, as I discussed in a recent blog post [1]). Funnily enough there are also some uses of forall-quantified types that are common to all of these extensions - using a forall just to make polymorphism explicit in a type doesn't change anything as far as the type system is concerned, so e.g. the types '(Eq a) => a -> Bool' and 'forall a . (Eq a) => a -> Bool' are equivalent. The latter type can be given to a function when any of the listed six extensions are given, even if most of them have nothing to do with this at all! So, what I'm getting at is an idea that Isaac Dupree gave as a comment to my blog post. He said: "I wish there was a plain old ExplicitForall extension that enabled the keyword in types (without extending the type checker -- only like (id :: forall a. a -> a) would be allowed)". I think this is a really great idea. I find it conceptually appealing, since I think it covers exactly that blind spot that is the seemingly unintended intersection between all these extensions. And it also makes the separation of concern between the syntactic level and the type system more clear. Any formalisation of any of the type system extensions would not need to bother with syntactic details, but can simply be said to imply ExplicitForall. I would thus like to propose the following formalisation of the ExplicitForall extension: ========================================= ExplicitForall enables the use of the keyword 'forall' to make a type explicitly polymorphic. Syntactically, it would mean the following change to Haskell 98: * 'forall' becomes a reserved word. * '.' (dot) becomes a special (not reserved) operator. * The following syntactic rule changes: type -> 'forall' tyvars '.' type | context '=>' type | ftype ftype -> btype '->' type | btype gendecl -> vars '::' type It does not allow the use of explicitly polymorphic types in any way not already allowed by Haskell 98 for implicitly polymorphic types. ========================================= One thing to note is that I haven't touched the matter of ExistentialQuantification in the above. Syntactically this is a different beast entirely, and could well be handled separately, though it's really an artifact of the way we (by default) write our data type declarations. Using GADT-style declarations, existential quantification goes nicely along with the others by following the same syntactic rules for types, even though from a type system it is of course still quite different from the rest. But with the ordinary Haskell 98 declaration style, we could define the syntactic part of the ExistentialQuantification extension as the following: ========================================= ExistentialQuantification allows data constructors to take existentially quantified arguments. Syntactically, it means the following changes to Haskell98: * 'forall' becomes a reserved word. * '.' (dot) becomes a special (not reserved) operator. * The following syntactic rule changes: constrs -> econstr_1 '|' ... '|' econstr_n econstr -> ['forall' tyvars '.' [context '=>']] constr ========================================= My hope is that you'll all agree with me on the need and rationale for the ExplicitForall extension, and that my proposal for formalisation is good enough for adoption. I feel much less strongly about ExistentialQuantification, and would love to hear some more input on that matter, but I do think it needs to be addressed one way or the other. Thoughts? Cheers, /Niklas [1] http://nibrofun.blogspot.com/2009/06/whats-in-forall.html

5 6

Re: Volunteers for a Haskell Platform steering committee
by Adam Wick 21 Jul '09

21 Jul '09

> We are now seeking volunteers for this steering committee. If there's still space, I'd like to join up, if just to represent the interest of Galois's fairly large existing code base as well as our future development efforts. -Adam

4 4

Re: Proposal #3271: new methods for Data.Sequence
by Louis Wasserman 21 Jul '09

21 Jul '09

As a final addition to Data.Sequence, I've added<http://hackage.haskell.org/trac/ghc/attachment/ticket/3271/new-methods-for-…>the following methods. Possibly debatable design decisions are highlighted. - mapWithIndex :: (Int -> a -> b) -> Seq a -> Seq b. (This is based on mapAccumL, which is slightly suboptimal [as the full mapping must be done before the last element can be examined], but acceptable given the tiny code investment.) - elemIndex, elemIndices, findIndex, findIndices, all as in Data.List. - elemLastIndex, findLastIndex, elemIndicesDesc, findIndicesDesc, all working from right-to-left but otherwise analogous. **Note:**findIndicesDesc and elemIndicesDesc return lists, not Sequences, so as to permit maximum laziness. Moreover, both of those methods fuse well. - takeWhileEnd, dropWhileEnd, spanEnd, breakEnd, all of which work from right-to-left but otherwise perform as their Data.List analogues. * *Note:** spanEnd p xs, in particular, returns *first* the longest *suffix * of xs of elements satisfying p, and then the remaining prefix. All but mapWithIndex take O(i) time, where i is the appropriate breakpoint -- that is, they don't necessarily search the entire sequence. (Each of the xxxEnd methods take O(n-i).) None of these methods are particularly code-intensive, save for some rewrite-rules-based code that lets most of those methods be defined in terms of findIndex, without any performance loss. (In the absence of rewrite rules, the additional overhead is small.) Louis Wasserman wasserman.louis(a)gmail.com

1 0